Configuration
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.
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 = {
purge: [],
darkMode: false, // or 'media' or 'class'
theme: {
extend: {},
},
variants: {
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
If you use a custom file name, you will need to specify it when including Tailwind as a plugin in your PostCSS configuration as well:
// postcss.config.js
module.exports = {
plugins: {
tailwindcss: { config: './tailwindcss-config.js' },
},
}
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:
module.exports = {
plugins: {
tailwindcss: {},
autoprefixer: {},
},
}
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 Tailwind uses internally.
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
module.exports = {
theme: {
colors: {
gray: colors.coolGray,
blue: colors.lightBlue,
red: colors.rose,
pink: colors.fuchsia,
},
fontFamily: {
sans: ['Graphik', 'sans-serif'],
serif: ['Merriweather', 'serif'],
},
extend: {
spacing: {
'128': '32rem',
'144': '36rem',
},
borderRadius: {
'4xl': '2rem',
}
}
}
}
Learn more about the default theme and how to customize it in the .
Variants
The variants
section lets you control which are generated for each core utility plugin.
// tailwind.config.js
module.exports = {
variants: {
extend: {
borderColor: ['focus-visible'],
opacity: ['disabled'],
}
},
}
Learn more in the variants configuration guide.
The plugins
section allows you to register plugins with Tailwind that can be used to generate extra utilities, components, base styles, or custom variants.
Presets
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 prefixes. That means that classes with responsive or state prefixes like sm:
or hover:
will still have the responsive or state prefix 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>
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 responsive utility like this:
@variants hover {
.bg-brand-gradient { /* ... */ }
}
…the generated responsive classes 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:
@variants hover {
.tw-bg-brand-gradient { /* ... */ }
}
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
:
.leading-none {
line-height: 1 !important;
}
.leading-tight {
line-height: 1.25 !important;
}
.leading-snug {
line-height: 1.375 !important;
}
/* etc. */
Note that any of your own custom utilities will not automatically be marked as !important
by enabling this option.
If you’d like to make your own utilities !important
, just add !important
to the end of each declaration yourself:
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',
}
After you specify the important
selector, you’ll need to ensure that the root element of your site matches it. Using the example above, we would need to set our root element’s id
attribute to app
in order for styles to work properly.
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">
<!-- 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 purge configuration, otherwise all of your CSS will be removed when building for production.
Separator
The separator
option lets you customize what character or string should be used to separate variant prefixes (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 Pug that doesn’t support special characters in class names.
// tailwind.config.js
module.exports = {
separator: '_',
}
Variant Order
If you are using the extend
feature to enable extra variants, those variants are automatically sorted to respect a sensible default variant order.
You can customize this if necessary under the variantOrder
key:
// tailwind.config.js
module.exports = {
// ...
variantOrder: [
'first',
'last',
'odd',
'even',
'visited',
'checked',
'group-hover',
'group-focus',
'focus-within',
'hover',
'focus',
'focus-visible',
'active',
'disabled',
]
}
The corePlugins
section lets you completely disable classes that Tailwind would normally generate by default if you don’t need them for your project.
If you don’t provide any corePlugins
configuration, all core plugins will be enabled by default:
// tailwind.config.js
module.exports = {
// ...
}
If you’d like 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:
Referencing in JavaScript
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:
import resolveConfig from 'tailwindcss/resolveConfig'
import tailwindConfig from './tailwind.config.js'
const fullConfig = resolveConfig(tailwindConfig)
fullConfig.theme.width[4]
// => '1rem'
fullConfig.theme.screens.md
// => '768px'
Note that this will transitively pull in a lot of our build-time dependencies, resulting in bigger bundle client-side size. To avoid this, we recommend using a tool like to generate a static version of your configuration at build-time.