CSS to Tailwind Converter

The complete guide to converting CSS to Tailwind

What is Tailwind CSS?

Tailwind CSS is a utility-first CSS framework: instead of writing custom class names and CSS rules for every component, you compose a look by combining small, single-purpose utility classes directly in your HTML — flex, items-center, gap-4, rounded-lg, bg-blue-500. Each utility maps to exactly one CSS declaration (or a very small, predictable set of them), drawn from a consistent design scale for spacing, color, typography and more. Rather than inventing a new class name every time you need a new look, you assemble one from existing building blocks — which is also exactly what this converter automates for CSS you already have.

Utility-first CSS explained

“Utility-first” means the smallest reusable unit of styling is a utility class, not a component class. Traditional CSS encourages naming things — .card-header, .btn-primary — and then writing the rules that make them look right. Utility-first flips that: the rules already exist as pre-named utilities, and you reach for the ones you need. The tradeoff is more classes in your markup in exchange for never having to invent a name, hunt through a separate stylesheet, or worry that changing one class will unexpectedly affect other elements that happen to share it.

Why convert CSS to Tailwind?

Teams usually convert existing CSS to Tailwind for one of three reasons: migrating a legacy codebase onto a modern utility-first workflow, prototyping faster by pasting styles from a design tool export and turning them into utilities immediately, or simply learning Tailwind by seeing familiar CSS translated side-by-side into its utility equivalents. Manually translating even a modest stylesheet is tedious and error-prone — you have to memorize (or constantly look up) Tailwind's spacing scale, color palette, and naming conventions for dozens of properties. An automated converter removes that friction and gives you a first-pass result to refine, rather than a blank page.

Traditional CSS vs. Tailwind CSS

The core difference is where the styling decisions live. In traditional CSS, a rule like .card { padding: 16px; border-radius: 8px; box-shadow: 0 1px 3px rgba(0,0,0,.1); } lives in a stylesheet, separate from the markup that uses it. In Tailwind, the same result is expressed directly on the element as class="p-4 rounded-lg shadow". Neither approach is “correct” in isolation — Tailwind trades a longer class attribute for the elimination of an entire category of problems: unused CSS, specificity wars, and the mental overhead of naming things. This converter exists precisely to bridge the two: keep writing or receiving CSS the way you always have, and get the Tailwind equivalent without manual lookup.

Tailwind v3 vs. v4

Tailwind v4 introduced a new, faster engine (nicknamed Oxide) and moved configuration from a JavaScript tailwind.config.js file to a CSS-first @theme block, but the vast majority of utility class names stayer identical between the two versions — flex, p-4, bg-blue-500 and md:hover:underline all work the same way in both. The handful of naming differences (for example v3's later versions already use grow/shrink rather than the old flex-grow-0 style) are handled by the version toggle above, so you can target whichever major version your project uses.

Spacing utilities

Tailwind's spacing scale is based on a 0.25rem (4px) unit: 1 = 0.25rem, 2 = 0.5rem, 4 = 1rem, and so on up through 96 = 24rem, plus a few in-between fractional steps like 0.5 and 1.5. This converter matches your CSS pixel and rem values against that exact scale for margin, padding, gap, width and height, and falls back to an arbitrary value like p-[19px] only when a number genuinely doesn't land on the scale — so you always get an accurate result, never a rounded approximation presented as exact.

Typography utilities

Font sizes map to Tailwind's named scale (text-sm, text-base, text-lg…), font weights map to font-medium/font-semibold/font-bold and so on, line-heights map to leading-tight/leading-normal/leading-relaxed, and letter-spacing maps to tracking-tight/tracking-wide. Text alignment, transform, decoration and white-space all have direct one-to-one utility equivalents as well.

Color utilities

Colors are the trickiest part of any CSS-to-Tailwind conversion, because your original CSS almost certainly wasn't written using Tailwind's exact palette. This converter first checks for an exact hex match against Tailwind's default 22-hue, 10-shade color system; if there isn't one, it looks for the closest color within a tight tolerance and uses that; and if nothing is close enough to be a fair substitute, it falls back to an arbitrary value like bg-[#2f6fed] so your exact color is preserved rather than silently shifted. RGBA and HSLA colors with an alpha channel are converted using Tailwind's opacity modifier syntax, like bg-blue-500/50.

Flexbox in Tailwind

display: flex becomes flex, flex-direction: column becomes flex-col, and alignment properties like justify-content and align-items map directly to justify-* and items-* utilities. Modern gap is supported directly (gap-4, gap-x-2, gap-y-6), and the flex shorthand's common values (1 1 0%, 1 1 auto, none) map to flex-1, flex-auto and flex-none respectively.

Grid in Tailwind

display: grid becomes grid, and the very common grid-template-columns: repeat(N, minmax(0, 1fr)) pattern converts to grid-cols-N. Column and row spans written as span N / span N convert to col-span-N / row-span-N. Anything more exotic — named grid lines, grid-template-areas, uneven track sizes — falls back to an arbitrary value so it's still captured, just not simplified to a named utility.

Responsive design with breakpoint prefixes

Tailwind's default breakpoints are sm (640px), md (768px), lg (1024px), xl (1280px) and 2xl (1536px), applied as a prefix like md:flex meaning “apply this utility from the md breakpoint upward.” This converter reads your @media (min-width: …) and @media (max-width: …) rules, matches the width against those defaults, and prefixes every utility generated from declarations inside that block accordingly — including an arbitrary min-[900px]: style prefix for non-standard breakpoints.

Dark mode

Both @media (prefers-color-scheme: dark) blocks and a .dark ancestor class selector (the two most common ways dark mode is implemented in hand-written CSS) are recognized and converted to Tailwind's dark: variant, which by default works the same way — either following the OS color scheme or toggling via a .dark class on a parent element, depending on your tailwind.config setting.

Hover, focus and other interactive states

Pseudo-class selectors like :hover, :focus, :focus-visible, :active, :disabled, :checked, :first-child and :last-child map to Tailwind's state variants (hover:, focus:, active:, disabled:, first:, last:…), and ::before/::after map to before:/after:, including converting the CSS content value into Tailwind's content-[…] arbitrary utility. More complex selectors — descendant combinators, :nth-child(), :not() — are flagged in the warnings panel rather than guessed at, since mapping them safely usually requires restructuring the markup (for example into Tailwind's group/peer pattern) rather than a mechanical translation.

Arbitrary values: the safety net

Tailwind's square-bracket arbitrary value syntax — top-[13px], bg-[#2f6fed], grid-cols-[repeat(auto-fill,minmax(120px,1fr))] — lets you express any CSS value without waiting for a named utility to exist. This converter leans on it deliberately: whenever a value doesn't cleanly match Tailwind's default scale, or a property has no dedicated utility at all, the tool emits an arbitrary value (or, for entirely unmapped properties, an arbitrary property like [mask-type:luminance]) instead of silently dropping the declaration. Every arbitrary value used is also counted in the stats panel so you can see at a glance how much of your CSS mapped cleanly versus how much needs a second look.

Tailwind configuration

A converter can only work with Tailwind's default design tokens — it has no way of knowing about custom colors, spacing, or fonts defined in your project's own tailwind.config.js (v3) or @theme block (v4). If your output contains a lot of arbitrary values that are visually close to each other, that's usually a sign worth extending your theme with a named token instead — for example turning three different bg-[#2f6fed]-ish arbitrary colors into a single brand color you can reuse as bg-brand.

CSS custom properties (variables)

CSS variables (--brand: #2f6fed;) can't become a single Tailwind utility class on their own, so this tool surfaces them separately in a “CSS variables detected” panel instead of guessing. When a variable is actually used as a value elsewhere (color: var(--brand)), the converter preserves that reference directly as an arbitrary value — text-[var(--brand)] — which is valid Tailwind syntax and keeps your design token live rather than baking in a static color.

Component design after converting

A first-pass conversion is a starting point, not a finished component. Once you have the utility classes for a repeated pattern like a button or card, the idiomatic next step in Tailwind is to either keep repeating the utility list everywhere it's used (Tailwind is designed for this — repetition is cheap once compressed by gzip and gets easier to manage with editor snippets), or extract a framework component (a React/Vue component, a Blade partial, an Astro component) that wraps the class list once. This converter's HTML/JSX/Vue/Svelte/Angular/Blade/Astro export tabs give you a ready-made starting snippet for exactly that second step.

Using the output with React

React uses className instead of class, so the JSX and TSX export tabs generate the exact same utility list wrapped in a className="…" attribute on a generic element, ready to paste into a component and adjust the tag/children as needed.

Using the output with Vue

Vue templates use the standard HTML class attribute, so the Vue export tab mirrors the HTML output — paste it directly into a <template> block in a single-file component.

Using the output with Laravel (Blade)

Laravel's Blade templates also use a plain class attribute; the Blade export tab uses Blade-style {{-- comment --}} annotations above each block so you can quickly identify which original CSS selector each utility list came from while wiring it into your .blade.php views.

Using the output with Next.js

Next.js apps are React under the hood, so the same JSX/TSX export applies — paste the generated className string into your Server or Client Components. If you're using the Next.js App Router with Tailwind already configured, no additional setup is needed beyond having Tailwind's build pipeline watching your files.

Migration best practices

• Convert one component or page at a time rather than an entire legacy stylesheet in one pass, so each result stays easy to review.
• Treat the warnings panel as a checklist — arbitrary values and skipped selectors are exactly the spots that deserve a manual look.
• Extend your Tailwind theme with brand colors, fonts and spacing before converting large batches of CSS, so more values land on named utilities instead of arbitrary ones.
• Keep the original CSS around until the visual output has been verified — automated conversion is a strong first draft, not a guaranteed pixel-perfect match.

Common conversion issues & troubleshooting

• A color looks slightly different — your original color wasn't close enough to any default Tailwind shade, so an arbitrary hex value was used deliberately instead of a misleading approximation.
• A selector's utilities aren't prefixed with hover:/md: — the selector was too complex (a descendant combinator, :nth-child(), etc.) to safely auto-map; check the warnings panel for the exact selector.
• A property produced an arbitrary property like [mask-type:luminance] — Tailwind has no dedicated utility for that CSS property; the arbitrary property syntax is the correct, valid way to express it.
• My @keyframes animation wasn't converted — only Tailwind's four built-in animations (spin, ping, pulse, bounce) are recognized by name; custom keyframes need to be added to your Tailwind config and referenced as animate-[name].

Performance benefits of switching to Tailwind

Because Tailwind's build step scans your markup and only ships the utility classes you actually use, production CSS bundles are typically smaller and grow much more slowly than a hand-maintained stylesheet, where old rules tend to accumulate rather than get deleted. Fewer, more predictable CSS rules also reduce specificity conflicts and the amount of dead code review needed over a project's lifetime — the migration effort up front tends to pay for itself in reduced long-term CSS maintenance.

Summary

Converting CSS to Tailwind is mostly mechanical — matching values against Tailwind's design scale, mapping selectors to variants, and falling back to arbitrary values when nothing fits — which is exactly the kind of repetitive, detail-sensitive work a browser-based tool can do instantly and privately. Paste your CSS above to get a working first draft, then use the warnings panel and this guide to refine anything that needs a human decision.