Tailwind CSS Best Practices
Tailwind's utility-first approach solves real problems (no more hunting for unused CSS, no specificity wars) but introduces its own set of habits worth getting right, especially around dynamic class names and consistency.
Last updated 2026-09-08
Never construct class names dynamically through string interpolation
Tailwind's build process scans your source files for complete, literal class name strings — a name built at runtime like `text-${color}-500` is invisible to that scan, so the corresponding CSS never gets generated.
Use a config-defined design scale instead of arbitrary values everywhere
Reaching for arbitrary values (like w-[137px]) for every measurement defeats the consistency benefit of Tailwind's design-token system. Extend the config with your actual design scale, and use arbitrary values only for genuine one-off exceptions.
Extract repeated utility combinations into components, not @apply everywhere
A long, repeated utility-class string copy-pasted across many components is better extracted into a reusable component than turned into a custom CSS class via @apply, which reintroduces some of the maintenance issues Tailwind avoids.
Keep the content/purge configuration accurate
Tailwind only generates CSS for classes it can find during its content scan — a content path that doesn't cover every file using Tailwind classes silently produces missing styles in production, often not caught until after deployment.
Use consistent spacing and sizing scale values, not arbitrary numbers
Mixing p-4, p-[15px], and p-5 inconsistently across a codebase erodes the visual consistency Tailwind's constrained scale is meant to provide.
Common Mistakes to Avoid
- ⚠Building class names via string interpolation, causing Tailwind to silently miss generating that CSS
- ⚠A content/purge config that doesn't cover every directory actually using Tailwind classes
- ⚠Overusing arbitrary values ([137px], [#3f51b5]) instead of the design-token scale
- ⚠Inconsistent spacing values scattered throughout instead of sticking to the scale
- ⚠Extracting every repeated pattern into @apply classes, re-creating traditional CSS maintenance overhead
Frequently Asked Questions
Why did my Tailwind classes work in development but disappear in production?
Almost always a content-scanning issue — either dynamically constructed class names, or a file/directory using Tailwind classes that isn't covered by the content configuration, both cause CSS to be silently omitted from the production build.
Is it bad practice to use arbitrary values in Tailwind?
Not inherently — they exist for genuine one-off needs. It becomes a problem when arbitrary values replace the design-token scale as the default habit rather than the occasional exception.