Dynamic utility classes excluded from Tailwind CSS v3 JIT output

Tailwind CSS v3 JIT emits only utilities that appear as literal strings in the configured content paths. Runtime assembled names like text-${color}-500 are invisible to the static scan, so they are missing from production CSS.

Confirmed facts for v3.x

JIT scanning is literal-string based. The safelist option can preserve utilities the scanner cannot find. A safelist entry can be a literal class string or a pattern object with a regex. Patterns can be scoped with variants and separator to cover responsive and state variants.

A pattern that is too broad inflates bundle size and can include unintended utilities. A pattern that is too narrow misses dynamically generated classes. Production builds must be inspected, because dev builds can mask missing utilities.

Recommended boundary

Refactor to complete literal class strings when the set is small, predictable, and statically knowable. Use a safelist when the set is dynamic or large.

• Literally safelist or refactor: <~5 predictable variants, e.g., a fixed palette of 3 colors. Listing each literal keeps output predictable and avoids regex risk.
• Regex safelist pattern: >~5 variants, user-defined values, or theme-driven names where enumerating is impractical. Keep the pattern as specific as possible.

Safe configuration options for generated names

In tailwind.config.js:

module.exports = {
  content: ['./src/**/*.{html,js,jsx,ts,tsx}'],
  safelist: [
    // literal fallback for known values
    'text-red-500',
    'text-blue-500',
    // pattern for dynamic color utilities
    {
      pattern: /^text-(red|blue|green|amber)-500$/,
      variants: ['sm','md','hover','focus'],
      separator: '-'
    }
  ]
}

Use variants to explicitly cover responsive and state forms you need. Use a tight regex with an allowlist of values instead of text-.*-500.

Criteria to choose safelist vs rewrite

• Predictability: can you enumerate all values at build time? Yes → literals or refactor.
• Count: few variants → literals; many variants → pattern.
• Variant coverage: need sm:, hover: etc.? Patterns must include those variants or you must refactor.
• Bundle budget: regex adds all matches. If size matters, prefer refactoring to known literals.
• Maintainability: dynamic theming from CMS or user input favors a scoped pattern; component-internal toggles favor refactoring.

Verification steps for this case

1. Confirm content globs include all template files where classes could appear.
2. Add a minimal safelist pattern for the dynamic family and build production CSS.
3. Inspect the output for the expected utilities and check for unintended matches.
4. Iterate the regex to be as specific as possible.

One diagnostic detail that changes the recommendation: do you need responsive and state variants for the dynamic utilities, e.g., sm:text-${color}-500 or hover:text-${color}-500? If yes, the safelist pattern must include those variants or refactoring to literals is safer.