Configuration
A guide to configuring and customizing your Tailwind installation.
Because Tailwind is a framework for building bespoke user interfaces, it has been designed from the ground up with customization in mind.
By default, Tailwind will look for an optional file at the root of your project where you can define any customizations.
tailwind.config.js
Every section of the config file is optional, so you only have to specify what you’d like to change. Any missing sections will fall back to Tailwind’s default configuration.
Generate a Tailwind config file for your project using the Tailwind CLI utility included when you install the tailwindcss
npm package:
npx tailwindcss init
This will create a minimal tailwind.config.js
file at the root of your project:
tailwind.config.js
module.exports = {
content: [],
theme: {
extend: {},
},
plugins: [],
}
To use a name other than tailwind.config.js
, pass it as an argument on the command-line:
npx tailwindcss init tailwindcss-config.js
When you use a custom file name, you will need to specify it as a command-line argument when compiling your CSS with the Tailwind CLI tool:
npx tailwindcss -c ./tailwindcss-config.js -i input.css -o output.css
If you’re using Tailwind as a PostCSS plugin, you will need to specify your custom configuration path in your PostCSS configuration:
postcss.config.js
module.exports = {
plugins: {
tailwindcss: { config: './tailwindcss-config.js' },
},
}
Alternatively, you can specify your custom configuration path using the @config
directive:
@config "./tailwindcss-config.js";
@tailwind base;
@tailwind components;
@tailwind utilities;
Learn more about the @config
directive in the documentation.
Generating a PostCSS configuration file
Use the -p
flag if you’d like to also generate a basic postcss.config.js
file alongside your tailwind.config.js
file:
npx tailwindcss init -p
This will generate a postcss.config.js
file in your project that looks like this:
postcss.config.js
module.exports = {
plugins: {
tailwindcss: {},
autoprefixer: {},
},
}
Scaffolding the entire default configuration
For most users we encourage you to keep your config file as minimal as possible, and only specify the things you want to customize.
If you’d rather scaffold a complete configuration file that includes all of Tailwind’s default configuration, use the --full
option:
npx tailwindcss init --full
You’ll get a file that matches the default configuration file Tailwind uses internally.
The content
section is where you configure the paths to all of your HTML templates, JS components, and any other files that contain Tailwind class names.
tailwind.config.js
module.exports = {
content: [
'./pages/**/*.{html,js}',
'./components/**/*.{html,js}',
],
// ...
}
Learn more about configuring your content sources in the documentation.
Theme
The theme
section is where you define your color palette, fonts, type scale, border sizes, breakpoints — anything related to the visual design of your site.
tailwind.config.js
Plugins
The plugins
section allows you to register plugins with Tailwind that can be used to generate extra utilities, components, base styles, or custom variants.
tailwind.config.js
module.exports = {
// ...
plugins: [
require('@tailwindcss/forms'),
require('@tailwindcss/aspect-ratio'),
require('tailwindcss-children'),
],
}
Learn more about writing your own plugins in the plugin authoring guide.
The presets
section allows you to specify your own custom base configuration instead of using Tailwind’s default base configuration.
tailwind.config.js
module.exports = {
// ...
presets: [
require('@acmecorp/base-tailwind-config')
],
// Project-specific customizations
theme: {
//...
},
}
Learn more about presets in the presets documentation.
Prefix
The prefix
option allows you to add a custom prefix to all of Tailwind’s generated utility classes. This can be really useful when layering Tailwind on top of existing CSS where there might be naming conflicts.
For example, you could add a tw-
prefix by setting the prefix
option like so:
tailwind.config.js
module.exports = {
prefix: 'tw-',
}
Now every class will be generated with the configured prefix:
.tw-text-left {
text-align: left;
}
.tw-text-center {
text-align: center;
}
.tw-text-right {
text-align: right;
}
/* etc. */
It’s important to understand that this prefix is added after any variant modifiers. That means that classes with responsive or state modifiers like sm:
or hover:
will still have the responsive or state modifier first, with your custom prefix appearing after the colon:
<div class="tw-text-lg md:tw-text-xl tw-bg-red-500 hover:tw-bg-blue-500">
<!-- -->
</div>
The dash modifier for negative values should be added before your prefix, so -mt-8
would become -tw-mt-8
if you’ve configured tw-
as your prefix:
<div class="-tw-mt-8">
<!-- -->
</div>
Prefixes are only added to classes generated by Tailwind; no prefix will be added to your own custom classes.
That means if you add your own custom utility like this:
@layer utilities {
.bg-brand-gradient { /* ... */ }
}
…the generated variants will not have your configured prefix:
.bg-brand-gradient { /* ... */ }
.hover\:bg-brand-gradient:hover { /* ... */ }
If you’d like to prefix your own utilities as well, just add the prefix to the class definition:
@layer utilities {
.tw-bg-brand-gradient { /* ... */ }
}
Important
The important
option lets you control whether or not Tailwind’s utilities should be marked with !important
. This can be really useful when using Tailwind with existing CSS that has high specificity selectors.
To generate utilities as !important
, set the important
key in your configuration options to true
:
tailwind.config.js
module.exports = {
important: true,
}
Now all of Tailwind’s utility classes will be generated as !important
:
This also applies to any custom utilities you define in your CSS using the @layer utilities
directive:
/* Input */
@layer utilities {
.bg-brand-gradient {
background-image: linear-gradient(#3490dc, #6574cd);
}
}
/* Output */
.bg-brand-gradient {
background-image: linear-gradient(#3490dc, #6574cd) !important;
}
Selector strategy
Setting important
to true
can introduce some issues when incorporating third-party JS libraries that add inline styles to your elements. In those cases, Tailwind’s !important
utilities defeat the inline styles, which can break your intended design.
To get around this, you can set important
to an ID selector like #app
instead:
tailwind.config.js
module.exports = {
// ...
important: '#app',
This configuration will prefix all of your utilities with the given selector, effectively increasing their specificity without actually making them !important
.
After your configuration is all set up and your root element matches the selector in your Tailwind config, all of Tailwind’s utilities will have a high enough specificity to defeat other classes used in your project, without interfering with inline styles:
<html>
<!-- ... -->
<style>
.high-specificity .nested .selector {
color: blue;
}
</style>
<body id="app">
<div class="high-specificity">
<div class="nested">
<!-- Will be red-500 -->
<div class="selector text-red-500"><!-- ... --></div>
</div>
</div>
<!-- Will be #bada55 -->
<div class="text-red-500" style="color: #bada55;"><!-- ... --></div>
</body>
</html>
When using the selector strategy, be sure that the template file that includes your root selector is included in your content configuration, otherwise all of your CSS will be removed when building for production.
Important modifier
Alternatively, you can make any utility important by adding a !
character to the beginning:
<p class="font-bold !font-medium">
This will be medium even though bold comes later in the CSS.
</p>
The !
always goes at the beginning of the utility name, after any variants, but before any prefix:
<div class="sm:hover:!tw-font-bold">
This can be useful in rare situations where you need to increase specificity because you’re at war with some styles you don’t control.
The separator
option lets you customize which character should be used to separate modifiers (screen sizes, hover
, focus
, etc.) from utility names (text-center
, items-end
, etc.).
We use a colon by default (:
), but it can be useful to change this if you’re using a templating language like that doesn’t support special characters in class names.
tailwind.config.js
module.exports = {
separator: '_',
}
Core Plugins
The corePlugins
section lets you completely disable classes that Tailwind would normally generate by default if you don’t need them for your project.
To disable specific core plugins, provide an object for corePlugins
that sets those plugins to false
:
tailwind.config.js
module.exports = {
corePlugins: {
float: false,
objectFit: false,
objectPosition: false,
}
}
If you’d like to safelist which core plugins should be enabled, provide an array that includes a list of the core plugins you’d like to use:
tailwind.config.js
module.exports = {
corePlugins: [
'margin',
'padding',
'backgroundColor',
// ...
]
}
If you’d like to disable all of Tailwind’s core plugins and simply use Tailwind as a tool for processing your own custom plugins, provide an empty array:
tailwind.config.js
module.exports = {
corePlugins: []
}
Here’s a list of every core plugin for reference:
For projects that need to generate multiple CSS files using different Tailwind configurations, use the @config
directive to specify which config file should be used for each CSS entry point:
site.css
admin.css
@config "./tailwind.site.config.js";
@tailwind base;
@tailwind components;
@tailwind utilities;
Learn more about the @config
directive in the Functions & Directives documentation.
It can often be useful to reference your configuration values in your own client-side JavaScript — for example to access some of your theme values when dynamically applying inline styles in a React or Vue component.
To make this easy, Tailwind provides a resolveConfig
helper you can use to generate a fully merged version of your configuration object:
Note that this will transitively pull in a lot of our build-time dependencies, resulting in bigger client-side bundle size. To avoid this, we recommend using a tool like babel-plugin-preval to generate a static version of your configuration at build-time.
We ship first-party TypeScript types for the tailwind.config.js
file which give you all sorts of useful IDE support, and makes it a lot easier to make changes to your configuration without referencing the documentation quite as much.
Configuration files generated with Tailwind CLI include the necessary type annotation by default, but to configure TypeScript types manually, just add the type annotation above your configuration object:
/** @type {import('tailwindcss').Config} */
module.exports = {
content: [
// ...
],
theme: {
extend: {},
},
plugins: [],