Tailwind to CSS Converter

Reverse-Engineering Tailwind: Why and How to Convert Back to CSS

Tailwind is a one-way street for most teams: once you adopt it, the design system, the build pipeline, and the muscle memory are all built around utility classes. But sometimes you need plain CSS, for an email template, a third-party CMS, a quick override, a migration off Tailwind, or simply to learn what each class actually does. This converter unwinds Tailwind's vocabulary back into the property/value language CSS started with.

What Tailwind Classes Actually Generate

Tailwind isn't magic. Each class corresponds to one or a small set of CSS declarations from a known theme. p-4 is padding: 1rem;. bg-blue-500 is background-color: #3b82f6;. flex is display: flex;. The framework gives you a compact vocabulary; the converter exposes the verbose CSS underneath.

For a single utility, the conversion is one-to-one. For a complete class string like flex items-center justify-between px-4 py-2 bg-white rounded-lg shadow-md, the converter expands to:

This is exactly what Tailwind would emit in its compiled CSS output. Useful for debugging, useful for understanding, useful for porting to non-Tailwind targets.

Responsive and State Variants

Tailwind's variant prefixes (md:, hover:, dark:) compile to media queries or pseudo-class selectors. By default the converter strips these and shows only the base utility because that's usually what people want to inspect. With "Preserve variants" enabled, the output expands into a CSS-correct form:

You need to wrap the result in a selector (.myclass in the example) because Tailwind utilities are applied via class, not arbitrary selectors. The converter outputs the declarations bare; you add the selector.

Arbitrary Values

Tailwind v3+ supports arbitrary values: p-[7px] for padding 7px, text-[#abcdef] for an exact color, grid-cols-[200px_1fr_minmax(0,_1fr)] for complex grids. The converter parses the bracketed value and emits it verbatim in the resulting CSS. Underscores in arbitrary values are converted to spaces (per Tailwind's rule for grid-template values etc.).

When Conversion Falls Short

A few Tailwind features don't translate cleanly to standalone CSS:

• Group variants. group-hover:opacity-100 requires a .group parent class to be matched via JavaScript-aware CSS selectors. The converter emits a note rather than a partial rule.
• Peer variants. Same story, they depend on sibling state established by another class.
• Dark mode. dark:bg-gray-900 depends on either the .dark class strategy or prefers-color-scheme. The converter can emit either form; pick the strategy that matches your config.
• Container queries (Tailwind 3.2+). @container utilities require the container query parent class; emitted as a comment when not in context.
• Custom utilities. If you've extended your tailwind.config.js with custom classes, those aren't in the converter's mapping table. Add a "custom CSS" passthrough or remap manually.

Migration Scenarios

1. Tailwind → plain CSS. A team that wants to drop Tailwind. Run components through the converter, collect the CSS into stylesheets, replace classes with selectors. Tedious but mechanical.
2. Tailwind → CSS Modules / styled-components. Convert classes per component, then wrap in your CSS-in-JS solution of choice. Each component becomes a named style block.
3. Tailwind → email template. Email clients don't run JavaScript and have spotty CSS support. Converting utilities to inline styles (and dropping anything email-incompatible) is a common pre-flight step.
4. Generating one-off CSS overrides. When you can't use a Tailwind class in some context but want the same look, generate the CSS once and inline it.

Privacy

The converter runs entirely client-side. Your Tailwind class strings and the resulting CSS stay in your browser. No telemetry. Useful if you're working with internal class lists you don't want to leak to a third-party server.

A Note on Round-Tripping

You can pass output through this converter into our CSS → Tailwind converter to see how the same intent would re-express in Tailwind. The round trip won't always be byte-identical (Tailwind has multiple ways to express the same CSS), but the semantics match. It's a useful sanity check when designing your own utility vocabularies.