Tailwind CSS has revolutionized modern front-end development by offering a utility-first approach. It’s fast, flexible, and makes styling a breeze. But if you’ve ever seen some of your classes disappear after production builds, especially when they’re dynamically generated, then you’re not alone. That’s where Tailwind’s safelist feature comes in!
In this post, we’ll break down what the Safelist is, why it’s important, and how to use it correctly with real-world examples.
Why Do My Tailwind Classes Disappear?
Tailwind CSS uses a feature called “PurgeCSS” (now called Content Scanning) to remove unused CSS during the production build. This drastically reduces your CSS file size. However, any class names not explicitly written in your code (e.g., those generated at runtime or passed from APIs) will be purged, gone from the final stylesheet.
For Example
<!-- This will stay --> <div class="text-red-500">Hello</div> <!-- This might get purged --> <div class={`text-${color}-500`}>Hi</div>
Since text-${color}-500 is dynamically created, Tailwind doesn’t “see” it during build time, so it assumes it’s unused and removes it.
What is the Tailwind Safelist?
The Safelist (formerly purge. Safelist) is a way to manually tell Tailwind CSS to always include specific classes, even if it doesn’t find them in your files.
It ensures your dynamic classes or edge cases are not purged from the final CSS output.
How to Use Safelist in tailwind.config.js
Simple Array Format
// tailwind.config.js module.exports = { content: ['./src/**/*.{html,js}'], safelist: ['text-red-500', 'bg-blue-200', 'hover:underline'] };
Tailwind will always include these classes, even if they don’t appear in your source code.
Pattern-Based Safelisting with Regex
For dynamic utilities (e.g., text-red-100 to text-red-900), use patterns:
module.exports = { safelist: [ { pattern: /text-(red|blue|green)-(100|200|300|400|500)/, }, { pattern: /bg-(gray|yellow)-(50|100|200|300)/, variants: ['hover', 'focus'], }, ] };
This tells Tailwind to include all matching combinations like text-red-100, bg-yellow-200:hover, etc.
Real-World Use Cases
Dynamic Theme Switcher
In any jsx file:
<div className={`bg-${theme}-500 text-white`}> Welcome! </div>
Classes like bg-blue-500, bg-green-500, etc., won’t be detected at build time.
In the tailwind config file, add:
safelist: [ { pattern: /bg-(blue|green|red)-(500)/, } ]
Button Variants from CMS or API
If buttons come from a CMS:
In JSON:
{ "btnColor": "yellow", "textColor": "gray" }
Your component HTML:
<button class={`bg-${btnColor}-400 text-${textColor}-900`}>Click Me</button>
Tailwind won’t see these classes. Safelist them like:
safelist: [ { pattern: /bg-(yellow|blue|green)-400/, }, { pattern: /text-(gray|black|white)-900/, } ]
Dark Mode Variants
In HTML:
<div class="dark:bg-gray-800 dark:text-white">Night Mode</div>
In config.js:
safelist: [ 'dark:bg-gray-800', 'dark:text-white' ]
Advanced Tips
- You can use variants with patterns to include states like hover, focus, sm, md, etc.
- Combine multiple patterns for color, size, and responsiveness.
In config.js:
{ pattern: /(bg|text)-(red|blue|green)-(100|200|300)/, variants: ['sm', 'md', 'hover'] }
Clean Code Strategy: When to Safelist vs Refactor
Use Safelist when
- You can’t avoid dynamic class generation (e.g., from CMS, user settings)
- Classes are predictable
Avoid Safelist if
- You can rewrite the logic to use static class names
- You can use conditional class tools like clsx, classnames, or Tailwind’s own recommended patterns
Common Mistakes
- Correct: Safelist: [‘text-red-500’]
- Wrong: Safelist: ‘text-red-500’ (must be an array)
- Expecting dynamic regex to catch invalid formats like text-${color} if color is from unknown sources
Tailwind : Final Best Practices
Tip | Why It Matters |
---|---|
Use pattern with clear boundaries | Avoid bloated final CSS |
Only safelist what’s truly needed | Reduce bundle size |
Test in production mode (NODE_ENV=production) | To simulate purge behavior |
Use utilities like clsx or classnames | Keep dynamic class logic readable |
Always document your safelist | Helps future maintainers understand why |
Useful Tools
- Tailwind Play – Test safelisting live
- PurgeCSS Analyzer – See what gets purged
- NODE_ENV=production npx tailwindcss -o build.css – Test your build locally
Conclusion
The Tailwind CSS safelist is a powerful tool that ensures your dynamic class names survive the purge process. Whether you’re building a theme engine, integrating CMS content, or just using creative component logic, Safelist saves you from frustrating styling bugs in production.
By mastering safelisting, you gain better control over your final CSS bundle while still enjoying the dynamic flexibility Tailwind offers.
Source: Read MoreÂ