It's where you define your color palette, font stacks, type scale, border sizes, breakpoints, opacity scale, you name it. Your config file is like an executable style guide for your project.
We provide a sensible default configuration with a very generous set of values to get you started, but you own this file; you're encouraged to change it as much as you need to fit the goals of your design.
It's important to understand that unlike other CSS frameworks you might have used, **none of the settings in this file are coupled to each other**. Nothing bad will happen even if you completely delete all of the values for a given module.
By default, `tailwind init` will generate a `tailwind.js` config file at the root of your project, but feel free to name this file differently or store it in a different location if you prefer.
The `colors` property doesn't actually affect your generated CSS on its own, but it's the perfect place to centralize your color palette so you can refer to it in your own CSS using Tailwind's [`config()`](/docs/functions-and-directives#config) function.
```js
// ...
var colors = {
'transparent': 'transparent',
// ...
'pink-lightest': '#ffebef',
}
// ...
module.exports = {
// ...
colors: colors,
// ...
}
```
By default, the `colors` property simply references a `colors` variable defined earlier in the file. Using a separate variable for your color palette like this makes it easy to re-use those colors when defining the color palette for individual utilities, like background colors, text colors, or border colors.
Learn more about defining colors in Tailwind in the [Colors](/docs/colors) documentation.
### Screens
The `screens` property is where you define your project's breakpoints, and will be used to generate responsive versions of Tailwind's utility classes.
```js
// ...
module.exports = {
// ...
screens: {
'sm': '576px',
'md': '768px',
'lg': '992px',
'xl': '1200px',
},
// ...
}
```
We provide a familiar set of breakpoints that you might recognize from [Bootstrap](http://getbootstrap.com/docs/4.0/layout/overview/#responsive-breakpoints) to get you started, but you're free to change these as needed to suit your project.
Learn more about customizing screens in the [Responsive Design](/docs/responsive-design#customizing-screens) documentation.
### Styles
The next set of properties define all of the values you'd like to use for utilities that are dynamically generated.
This includes things like:
- Background colors
- Border widths
- Font families
- Font weights
- Text sizes
- Padding, margin, and negative margin scales
- Width and height scales
...and many others.
For example, here's the section used to customize which border radius utilities will be generated:
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:
The `separator` option lets you customize what character or string should be used to separate state 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](https://pugjs.org) that doesn't support special characters in class names.