Tailwind vs Plain CSS — When Each Approach Actually Wins

Plain CSS follows a separation of concerns model: HTML describes content and structure, CSS describes appearance. Semantic class names like .card, .button-primary, and .navigation-item describe what an element is, not how it looks. Developers write stylesheets that can theoretically be swapped out while the HTML stays the same. This model dominated web development for 15 years and is still taught as best practice in most introductory courses.

Tailwind CSS inverts this model. It is utility-first, meaning styles are expressed directly in HTML as small, composable class names. There are no custom class names and no separate stylesheet to maintain for most elements. The design system is expressed through the utility class names themselves: p-4 is always 1rem of padding, bg-blue-500 is always a specific shade of blue from your config. This consistency is enforced by the framework itself rather than by naming conventions.

The key insight behind Tailwind's design is that the separation of concerns argument breaks down in component-based frameworks like React, Vue, and Svelte. In these frameworks, a Button component already encapsulates both the structure (JSX/template) and the behavior (event handlers). Adding a separate CSS file for each component does not meaningfully separate concerns — it just splits the component's implementation across two files. Tailwind argues that co-locating styles with markup in the component is more practical than a separate stylesheet.

Bundle size is also different in each approach. Plain CSS grows proportionally with the number of rules you write. Tailwind's JIT mode generates only the utilities you actually use, typically resulting in 5–20 KB of gzipped CSS for a full application. A hand-written CSS approach for the same application might be smaller if very few utilities are used, or much larger if many component-specific styles accumulate over time. There is no universal winner on bundle size — it depends on how each approach is used.

Evaluate your project's size and growth trajectory. For a small marketing site with three pages and minimal interactivity, plain CSS is probably simpler — you might write 200 lines of CSS and be done. A build step adds complexity without much payoff. For a product with dozens of components that will grow to hundreds, Tailwind's consistent utility system pays dividends in maintaining visual consistency without a strict naming convention.

Consider your team's composition and experience. A team of developers who have never used Tailwind will face a learning curve — not in understanding the CSS properties, but in memorizing the class name conventions. bg-blue-500 is not self-evident to someone who has only written plain CSS. However, the learning curve flattens quickly, typically within a week of active use. A team already experienced with Tailwind has zero ramp-up cost.

Think about runtime theming requirements. Tailwind classes are resolved at compile time; the resulting CSS cannot be changed at runtime without regenerating the stylesheet. If your application needs user-controlled themes, dynamic color palettes, or white-label branding, you need CSS custom properties at the foundation. CSS custom properties can be used with Tailwind — you define them in your tailwind.config.js theme, and they become the values behind the utility classes — but the integration requires additional setup.

Assess your HTML's public visibility. Tailwind's utility classes produce class attributes like class="flex items-center justify-between px-4 py-3 rounded-lg border border-slate-200 bg-white shadow-sm". For server-rendered pages where the HTML source is public and the quality of the markup matters for SEO or accessibility perception, the class attribute verbosity can be a concern. Semantic class names are cleaner in the rendered source, though search engines do not penalize utility class patterns.

Most mature production projects use a hybrid approach rather than choosing one absolutely. Tailwind handles layout, spacing, color, and typography utilities — the 80% of CSS that is repetitive and benefits from a consistent system. Custom CSS handles the 20% that Tailwind cannot express cleanly: complex animations, multi-step keyframes, intricate pseudo-element layouts, third-party library overrides, and component styles that require semantic class names for external selection.

For complex animations, write standard CSS keyframes in your global stylesheet alongside the Tailwind entry. Use Tailwind's animate- utilities for the common patterns (animate-spin, animate-pulse, animate-bounce, animate-ping) and extend the keyframes config for custom animations: theme.extend.keyframes.slide-in = { from: { opacity: 0, transform: 'translateY(-10px)' }, to: { opacity: 1, transform: 'translateY(0)' } }. Then add the animation class to the extend.animation config and use it as a standard Tailwind class.

CSS Modules work well alongside Tailwind. A component can use Tailwind utility classes for its layout and typography, then use a .module.css file for the one or two component-specific styles that are complex enough to warrant custom CSS. The module file is imported and applied as a class via styles.uniqueRule alongside the Tailwind classes. This avoids the choice between all-Tailwind and all-custom-CSS.

For design token management, Tailwind's config file is essentially a design token system. Define your brand colors, spacing scale, typography scale, and shadow values in the theme section. Every utility class derived from those values will be consistent. If your organization has a separate token file (style-dictionary, theo, design tokens format), there are tools that can generate a Tailwind config from it, keeping the source of truth in one place.

Tailwind struggles with elements that need to be styled from outside their component tree. If you render a third-party library component and need to override its internal styles, Tailwind's utility classes apply only to elements in your control. You end up writing custom CSS with a descendant selector anyway. In these cases, a well-named CSS Module class or a global stylesheet override is cleaner than forcing a Tailwind approach.

Plain CSS struggles at scale without enforced conventions. Without BEM, CSS Modules, or another scoping strategy, class names across a large team diverge in naming style, specificity, and organization. What starts as .button and .button-primary proliferates into .btn, .btn-lg, .button-lg, .cta-button, and .submit-btn across different developers' contributions. Tailwind's constraint — you can only use utility classes — prevents this drift entirely.

Data visualization and complex SVG styling are cases where neither Tailwind nor plain CSS has a clear advantage. SVG attributes like fill, stroke, stroke-width, and cx are not CSS properties and cannot be set with Tailwind utilities (though Tailwind 3.x added fill- and stroke- utilities). Complex interactive charts almost always require custom CSS or inline styles regardless of which framework you use.

Accessibility-related styles sometimes require patterns that Tailwind supports poorly. The focus-visible pseudo-class, high-contrast mode media queries (forced-colors), and custom focus rings with specific color stops often need custom CSS. Tailwind provides focus-visible: and forced-colors: prefixes, but the combinations required for robust accessibility work are sometimes easier to express in plain CSS.

Print stylesheets are another area where plain CSS has a clear ergonomic advantage over Tailwind. A single @media print block in plain CSS can hide navigation, reset colors to black on white, and adjust font sizes for the entire page in a few concise rules. With Tailwind, every element that should change for print must receive individual print: variant prefix classes, meaning print formatting is scattered across the entire component tree rather than consolidated in one readable block.

The biggest Tailwind mistake is not extracting repeated class combinations into components. A button that appears 40 times in the codebase with the same 10 Tailwind classes is not using Tailwind correctly — it should be a Button component where the class string lives once. Tailwind's documentation explicitly states this: extract components for repeated patterns, use utilities for one-off styles.

Another Tailwind mistake is fighting the design system. When a developer adds arbitrary values like w-[372px] or text-[#b47ae3] throughout the codebase, they undermine the consistency that Tailwind provides. Arbitrary values are occasionally necessary, but frequent use is a sign that the design tokens in tailwind.config.js need to be extended rather than bypassed with inline values.

For plain CSS, the most common mistake is writing overly specific selectors. A rule like .main-content .article-list .article-item .article-title a has specificity high enough that it becomes nearly impossible to override without writing an even more specific rule or resorting to !important. Keep selectors flat and rely on source order for cascade control. Use a linter rule to limit selector depth.

Importing CSS files directly in components without a scoping strategy (like CSS Modules) is a mistake in any component framework. Plain .css files imported in React components are globally scoped — a .button class in ButtonComponent.css affects every element with class button in the application. Always use CSS Modules, a scoped CSS solution, or a strict naming convention when importing CSS alongside components.

A specific Tailwind anti-pattern worth calling out is Tailwind sprawl, where a single component accumulates 30 or more utility classes on one element and becomes unreadable in both the editor and pull request diffs. When a className string grows past roughly 10 classes, it is a signal to extract the element into a named component or to use the @apply directive in a CSS file to group the classes under a meaningful semantic name, restoring readability without abandoning the Tailwind design token system.

Make the decision explicit at project start and document it in the README or architecture decision record. Whether you choose Tailwind, plain CSS, CSS Modules, or a hybrid, write down the rationale. When a new team member joins or the team grows, they should be able to read one document and understand the conventions without needing to infer them from the codebase.

For Tailwind projects, extend the config rather than using arbitrary values. Add your brand colors to theme.extend.colors, your custom spacing values to theme.extend.spacing, and your typeface to theme.extend.fontFamily. A config that is well-extended means every utility class in the codebase refers to a named token, making global changes simple. Changing brand.primary in the config updates every element that uses text-brand-primary, bg-brand-primary, and border-brand-primary simultaneously.

For plain CSS projects in 2026, adopt CSS custom properties as your token system. Define all colors, spacing values, font sizes, and border radii in :root at the top of your main stylesheet. Reference them with var(--token-name) everywhere. This gives you the same benefits as Tailwind's config for consistency and global changeability, without needing a build step. Native CSS nesting handles component-scoped styles. CSS layers (@layer base, @layer components, @layer utilities) manage specificity without !important.

Regardless of which approach you choose, run a visual regression test suite before major refactors. Tools like Percy, Chromatic, or playwright-visual compare screenshots of your UI before and after CSS changes to catch unintended regressions. CSS is particularly prone to silent regressions — a change in one rule can affect elements in unexpected ways, and visual tests catch these where unit tests cannot.