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:

    1. npx tailwindcss init

    This will create a minimal tailwind.config.js file at the root of your project:

    1. // tailwind.config.js
    2. module.exports = {
    3. future: {},
    4. purge: [],
    5. theme: {
    6. extend: {},
    7. },
    8. variants: {},
    9. plugins: [],
    10. }

    To use a name other than tailwind.config.js, pass it as an argument on the command-line:

    1. 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:

    1. // postcss.config.js
    2. module.exports = {
    3. plugins: [
    4. require('tailwindcss')('./tailwindcss-config.js'),
    5. ],
    6. }

    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:

    1. npx tailwindcss init --full

    You’ll get a file that matches the default configuration file Tailwind uses internally.

    Theme

    The theme section is where you define your color palette, font stacks, type scale, border sizes, breakpoints — anything related to the visual design of your site.

    1. // tailwind.config.js
    2. module.exports = {
    3. theme: {
    4. screens: {
    5. sm: '640px',
    6. md: '768px',
    7. lg: '1024px',
    8. xl: '1280px',
    9. },
    10. fontFamily: {
    11. display: ['Gilroy', 'sans-serif'],
    12. body: ['Graphik', 'sans-serif'],
    13. },
    14. borderWidth: {
    15. default: '1px',
    16. '0': '0',
    17. '2': '2px',
    18. '4': '4px',
    19. },
    20. extend: {
    21. colors: {
    22. cyan: '#9cdbff',
    23. },
    24. spacing: {
    25. '96': '24rem',
    26. '128': '32rem',
    27. }
    28. }
    29. }

    Learn more about the default theme and how to customize it in the theme configuration guide.

    Variants

    The variants section lets you control which variants are generated for each core utility plugin.

    1. // tailwind.config.js
    2. module.exports = {
    3. variants: {
    4. appearance: ['responsive'],
    5. backgroundColor: ['responsive', 'hover', 'focus'],
    6. fill: [],
    7. },
    8. }

    Learn more in the .

    Learn more about writing your own plugins in the plugin authoring guide.

    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:

    1. // tailwind.config.js
    2. module.exports = {
    3. prefix: 'tw-',
    4. }

    Now every utility will be generated with the configured prefix:

    1. .tw-text-left {
    2. text-align: left;
    3. }
    4. .tw-text-center {
    5. text-align: center;
    6. }
    7. .tw-text-right {
    8. text-align: right;
    9. }
    10. /* etc. */

    It’s important to understand that this prefix is added to the beginning of each utility name, not to the entire class name.

    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:

    1. <div class="tw-text-lg md:tw-text-xl tw-bg-red-500 hover:tw-bg-blue-500">
    2. <!-- -->
    3. </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:

    1. @responsive {
    2. .bg-brand-gradient { /* ... */ }
    3. }

    …the generated responsive classes will not have your configured prefix:

    1. .bg-brand-gradient { /* ... */ }
    2. @media (min-width: 640px) {
    3. .sm\:bg-brand-gradient { /* ... */ }
    4. }
    5. @media (min-width: 768px) {
    6. .md\:bg-brand-gradient { /* ... */ }
    7. }
    8. @media (min-width: 992) {
    9. .lg\:bg-brand-gradient { /* ... */ }
    10. }
    11. @media (min-width: 1280px) {
    12. .xl\:bg-brand-gradient { /* ... */ }
    13. }

    If you’d like to prefix your own utilities as well, just add the prefix to the class definition:

    1. @responsive {
    2. .tw-bg-brand-gradient { /* ... */ }
    3. }

    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:

    1. // tailwind.config.js
    2. module.exports = {
    3. important: true,
    4. }

    Now all of Tailwind’s utility classes will be generated as !important:

    Note that any of your own custom utilities will not automatically be marked as !important by enabling this option.

    1. @responsive {
    2. .bg-brand-gradient {
    3. background-image: linear-gradient(#3490dc, #6574cd) !important;
    4. }
    5. }

    Setting important to true is useful, but 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. This is really common with animation libraries, for example.

    If you’re not facing that issue, feel free to skip to the next section! But if you are facing that issue, you can make utilities “important” in a less aggressive manner by providing a CSS selector instead of a boolean to the important option:

    1. module.exports = {
    2. important: '#app',
    3. }

    This configuration will prefix all of your utilities with the given selector, effectively increasing their specificity without actually making them !important.

    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:

    1. <html>
    2. <!-- ... -->
    3. <style>
    4. .high-specificity .nested .selector {
    5. color: blue;
    6. }
    7. </style>
    8. <body id="app">
    9. <div class="high-specificity">
    10. <div class="nested">
    11. <!-- Will be red-500 -->
    12. <div class="selector text-red-500"><!-- ... --></div>
    13. </div>
    14. </div>
    15. <!-- Will be #bada55 -->
    16. <div class="text-red-500" style="color: #bada55;"><!-- ... --></div>
    17. </body>
    18. </html>

    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 that doesn’t support special characters in class names.

    1. // tailwind.config.js
    2. module.exports = {
    3. separator: '_',
    4. }

    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.

    If you don’t provide any corePlugins configuration, all core plugins will be enabled by default:

    1. // tailwind.config.js
    2. module.exports = {}

    If you’d like to disable specific core plugins, provide an object for corePlugins that sets those plugins to false:

    1. // tailwind.config.js
    2. module.exports = {
    3. corePlugins: {
    4. float: false,
    5. objectFit: false,
    6. objectPosition: false,
    7. }

    If you’d like to whitelist which core plugins should be enabled, provide an array that includes a list of the core plugins you’d like to use:

    1. // tailwind.config.js
    2. module.exports = {
    3. corePlugins: [
    4. 'margin',
    5. 'padding',
    6. 'backgroundColor',
    7. // ...
    8. ]
    9. }

    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:

    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.

    1. import resolveConfig from 'tailwindcss/resolveConfig'
    2. import tailwindConfig from './tailwind.config.js'
    3. const fullConfig = resolveConfig(tailwindConfig)
    4. fullConfig.theme.width[4]
    5. // => '1rem'
    6. fullConfig.theme.screens.md
    7. // => '768px'
    8. // => '0 25px 50px -12px rgba(0, 0, 0, 0.25)'

    ← Functions & Directives