Converting Tailwind CSS to Vanilla CSS: When and How

# Converting Tailwind CSS to Vanilla CSS: When and How

Why Convert Tailwind to Vanilla CSS

Tailwind CSS is widely used and for good reason. The utility-first approach speeds up prototyping, enforces consistency through a shared design system, and eliminates the naming problem that plagues traditional CSS architectures. But Tailwind is not the right tool for every situation, and there are valid technical reasons to convert Tailwind-based markup to vanilla CSS.

Removing the Build Dependency

Tailwind requires a build step. The CLI scans your templates, generates a stylesheet containing only the classes you use, and outputs a CSS file. This works seamlessly in modern frameworks like Next.js, Vite, or Astro. But if you are shipping a component, widget, or embeddable script that others will drop into arbitrary environments, requiring a Tailwind build step is a burden on your consumers.

A vanilla CSS component can be included with a single <link> tag. A Tailwind component requires the consumer to either run the Tailwind CLI, copy your entire utility stylesheet, or include Tailwind's CDN build (which is large and includes all utilities). For distributable code, vanilla CSS is a better citizen.

Handing Off to Non-Tailwind Teams

If you build a prototype in Tailwind and hand it to a design or development team that does not use Tailwind, they face a learning curve just to make CSS changes. Tailwind's utility classes are meaningful to developers who know the system, but opaque to those who do not.

Converting to semantically named vanilla CSS classes gives the receiving team something they can immediately understand and modify without learning Tailwind's conventions.

Extracting Components as a Framework-Agnostic Library

Component libraries published to npm need to work across React, Vue, Svelte, Angular, and plain HTML. If your library's styles depend on Tailwind classes in the markup, every consumer needs to configure Tailwind. This is a non-starter for many users.

Publishing components with scoped vanilla CSS (or CSS modules) creates zero friction. The styles work everywhere without any build tool configuration.

Understanding What Utilities Actually Do

Learning exercise: if you have been writing Tailwind for a year and want to sharpen your raw CSS skills, convert a component to vanilla CSS without looking anything up. You will quickly identify which utilities you understand deeply and which you have been using by convention without fully knowing the underlying CSS.

This is especially useful for developers transitioning from Tailwind to a codebase that uses BEM, CSS modules, or styled-components. The conversion exercise bridges the gap between utility-first and traditional CSS approaches.

Bundle Size in Edge Cases

Tailwind's build system is very good at tree-shaking. The output CSS only contains classes you actually use. But in some edge cases - content generated dynamically at runtime, CSS-in-JS patterns that construct class names programmatically, or projects where the scanner does not cover all template sources - Tailwind may include unnecessary utilities.

For very small, focused projects (a landing page, a form widget, a documentation site) where you only use 15-20 distinct utility values, the overhead of Tailwind's configuration and scanning infrastructure may exceed the benefit. Hand-writing CSS for those specific declarations can be lighter.

---

How Tailwind Classes Map to CSS: Complete Reference

Every Tailwind utility class corresponds to one or a small number of CSS declarations. The mapping is deterministic and documented, but looking it up for each class takes time. Here is a comprehensive reference for the most commonly used utilities.

Spacing (Padding and Margin)

Tailwind uses a spacing scale where 1 = 0.25rem (4px at default font size). So p-4 is padding: 1rem, and p-8 is padding: 2rem.

The space-x-* and space-y-* utilities use a CSS selector pattern:

/* space-y-4 */
.space-y-4 > * + * {
  margin-top: 1rem;
}

Layout and Display

Flexbox

CSS Grid

Typography

Sizing

Borders and Radius

Colors

Tailwind uses a named color palette with shade levels 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, and 950. Here are the exact hex values for frequently used colors:

The complete Tailwind color palette contains hundreds of values. Use the Color Converter to translate between hex, RGB, and HSL formats when working with extracted color values.

Opacity, Shadows, and Transforms

Positioning

Overflow, Cursor, and Pointer Events

---

Converting Responsive Prefixes

Tailwind responsive classes use breakpoint prefixes that translate directly to CSS media queries. Tailwind uses a mobile-first approach, so breakpoint prefixes activate styles at the specified width and above.

Tailwind Default Breakpoints

Converting a Responsive Element

<!-- Tailwind -->
<div class="hidden md:block lg:flex lg:items-center">

/* Vanilla CSS */
.element {
  display: none;
}

@media (min-width: 768px) {
  .element {
    display: block;
  }
}

@media (min-width: 1024px) {
  .element {
    display: flex;
    align-items: center;
  }
}

A Responsive Grid Layout

<!-- Tailwind: single column mobile, two columns tablet, three columns desktop -->
<div class="grid grid-cols-1 gap-4 sm:grid-cols-2 lg:grid-cols-3">

/* Vanilla CSS */
.card-grid {
  display: grid;
  grid-template-columns: repeat(1, minmax(0, 1fr));
  gap: 1rem;
}

@media (min-width: 640px) {
  .card-grid {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

@media (min-width: 1024px) {
  .card-grid {
    grid-template-columns: repeat(3, minmax(0, 1fr));
  }
}

---

Converting State Variants

Tailwind handles hover, focus, active, and other states through prefixed utilities. Each prefix adds a CSS pseudo-class or pseudo-element.

State Variant Examples

<!-- Tailwind -->
<button class="bg-blue-500 hover:bg-blue-600 focus:ring-2 focus:ring-blue-300 disabled:opacity-50">
  Submit
</button>

/* Vanilla CSS */
.btn-primary {
  background-color: #3b82f6;
}

.btn-primary:hover {
  background-color: #2563eb;
}

.btn-primary:focus {
  box-shadow: 0 0 0 2px #93c5fd;
  outline: none;
}

.btn-primary:disabled {
  opacity: 0.5;
}

Group Hover Pattern

<!-- Tailwind: change child element on parent hover -->
<div class="group">
  <h3>Card Title</h3>
  <span class="text-gray-400 group-hover:text-blue-500">Read more</span>
</div>

/* Vanilla CSS */
.card:hover .card-link {
  color: #3b82f6;
}

The group and peer patterns in Tailwind are sophisticated state management. When converting, you replace them with standard CSS sibling and descendant selectors.

---

Converting Dark Mode

Tailwind supports two dark mode strategies: class (toggle by adding a dark class to <html>) and media (responds to prefers-color-scheme). The conversion differs for each.

Media Strategy

<!-- Tailwind with dark: prefix -->
<div class="bg-white dark:bg-gray-900 text-gray-900 dark:text-white">

/* Vanilla CSS - media strategy */
.container {
  background-color: #ffffff;
  color: #111827;
}

@media (prefers-color-scheme: dark) {
  .container {
    background-color: #111827;
    color: #ffffff;
  }
}

Class Strategy

/* Vanilla CSS - class strategy */
.container {
  background-color: #ffffff;
  color: #111827;
}

.dark .container {
  background-color: #111827;
  color: #ffffff;
}

Using CSS Custom Properties for Dark Mode

Rather than duplicating every rule in a dark media query, use CSS custom properties:

:root {
  --color-bg: #ffffff;
  --color-text: #111827;
  --color-border: #e5e7eb;
  --color-primary: #3b82f6;
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-bg: #111827;
    --color-text: #ffffff;
    --color-border: #374151;
    --color-primary: #60a5fa;
  }
}

.container {
  background-color: var(--color-bg);
  color: var(--color-text);
  border-color: var(--color-border);
}

This approach makes the converted CSS much more maintainable than the Tailwind-class-per-element approach.

---

Automated Conversion

Manually converting hundreds of utility classes is tedious and error-prone. Tailwind to CSS handles this automatically. Paste any HTML with Tailwind classes and the tool:

1. Parses every class applied to each element
2. Resolves the CSS declarations for each utility
3. Groups related declarations into semantic class names
4. Handles responsive prefixes as media queries
5. Handles state variants as pseudo-classes
6. Outputs clean, formatted CSS you can use directly

A Realistic Conversion Example

Input HTML:

<div class="flex flex-col gap-6 p-6 max-w-md mx-auto">
  <h2 class="text-2xl font-bold text-gray-900">Account Settings</h2>
  <div class="flex flex-col gap-4">
    <label class="text-sm font-medium text-gray-700">Email</label>
    <input class="w-full px-3 py-2 border border-gray-300 rounded-md
                  text-sm placeholder:text-gray-400
                  focus:outline-none focus:ring-2 focus:ring-blue-500">
  </div>
  <button class="w-full py-2 px-4 bg-blue-600 hover:bg-blue-700
                 text-white font-semibold rounded-md
                 disabled:opacity-50 cursor-pointer">
    Save Changes
  </button>
</div>

Output CSS from the converter:

.container {
  display: flex;
  flex-direction: column;
  gap: 1.5rem;
  padding: 1.5rem;
  max-width: 28rem;
  margin-left: auto;
  margin-right: auto;
}

.heading {
  font-size: 1.5rem;
  line-height: 2rem;
  font-weight: 700;
  color: #111827;
}

.form-group {
  display: flex;
  flex-direction: column;
  gap: 1rem;
}

.form-label {
  font-size: 0.875rem;
  line-height: 1.25rem;
  font-weight: 500;
  color: #374151;
}

.form-input {
  width: 100%;
  padding-left: 0.75rem;
  padding-right: 0.75rem;
  padding-top: 0.5rem;
  padding-bottom: 0.5rem;
  border: 1px solid #d1d5db;
  border-radius: 0.375rem;
  font-size: 0.875rem;
  line-height: 1.25rem;
}

.form-input::placeholder {
  color: #9ca3af;
}

.form-input:focus {
  outline: none;
  box-shadow: 0 0 0 2px #3b82f6;
}

.btn-primary {
  width: 100%;
  padding-top: 0.5rem;
  padding-bottom: 0.5rem;
  padding-left: 1rem;
  padding-right: 1rem;
  background-color: #2563eb;
  color: #ffffff;
  font-weight: 600;
  border-radius: 0.375rem;
  cursor: pointer;
}

.btn-primary:hover {
  background-color: #1d4ed8;
}

.btn-primary:disabled {
  opacity: 0.5;
}

---

Best Practices for Writing the Converted CSS

1. Group Properties Semantically

The direct result of conversion is often verbose - one CSS declaration per Tailwind utility. Combine related properties into coherent, semantically named classes rather than leaving them in one giant rule:

/* Less readable - everything dumped into one class */
.everything {
  display: flex;
  flex-direction: column;
  gap: 1rem;
  padding: 1.5rem;
  border-radius: 0.5rem;
  border: 1px solid #e5e7eb;
  background-color: #ffffff;
  box-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1);
  max-width: 28rem;
  margin-left: auto;
  margin-right: auto;
}

/* More maintainable - split into logical concerns */
.card {
  background-color: #ffffff;
  border: 1px solid #e5e7eb;
  border-radius: 0.5rem;
  box-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1);
  padding: 1.5rem;
}

.card-layout {
  display: flex;
  flex-direction: column;
  gap: 1rem;
}

.card-container {
  max-width: 28rem;
  margin-left: auto;
  margin-right: auto;
}

2. Replace Color Values with CSS Custom Properties

Hardcoded hex values from Tailwind make theming difficult. Replace them immediately with CSS variables:

:root {
  --color-primary: #3b82f6;
  --color-primary-dark: #2563eb;
  --color-text: #111827;
  --color-text-muted: #6b7280;
  --color-border: #e5e7eb;
  --color-surface: #ffffff;
  --color-bg: #f9fafb;
}

/* Now use the variables */
.btn {
  background-color: var(--color-primary);
  color: var(--color-surface);
}

.btn:hover {
  background-color: var(--color-primary-dark);
}

p {
  color: var(--color-text);
}

.caption {
  color: var(--color-text-muted);
}

3. Use a Consistent Naming Convention

Pick a CSS naming methodology and apply it consistently to the converted output:

BEM (Block, Element, Modifier):

.card { ... }
.card__header { ... }
.card__body { ... }
.card__footer { ... }
.card--featured { ... }
.card--compact { ... }

Utility + Component hybrid:

/* Low-level utilities */
.flex { display: flex; }
.flex-col { flex-direction: column; }
.gap-4 { gap: 1rem; }

/* Component-level rules for unique combinations */
.product-card { ... }
.nav-item { ... }

4. Organize the Stylesheet Structure

A well-organized converted stylesheet is easier to maintain than the original Tailwind markup (which has ordering determined by element position in the HTML):

/* 1. Custom Properties */
:root { ... }

/* 2. Reset / Base */
*, *::before, *::after { box-sizing: border-box; }
body { ... }

/* 3. Typography */
h1, h2, h3 { ... }
p { ... }

/* 4. Layout */
.container { ... }
.grid { ... }

/* 5. Components */
.card { ... }
.btn { ... }
.form-input { ... }

/* 6. Utilities */
.sr-only { ... }
.visually-hidden { ... }

/* 7. Media Queries */
@media (min-width: 768px) { ... }

5. Preserve the Accessible Patterns

Tailwind has several utilities for accessibility that must be converted correctly:

/* sr-only - visually hidden but accessible to screen readers */
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

/* not-sr-only - makes an sr-only element visible again */
.not-sr-only {
  position: static;
  width: auto;
  height: auto;
  padding: 0;
  margin: 0;
  overflow: visible;
  clip: auto;
  white-space: normal;
}

/* focus-visible - shows focus ring only for keyboard navigation */
.input:focus-visible {
  outline: 2px solid #3b82f6;
  outline-offset: 2px;
}

---

When Conversion Is Not the Right Answer

Converting Tailwind to vanilla CSS is sometimes the wrong tool for the problem.

If you just want smaller bundles: Tailwind's build process already ships only the utilities you use. The output is already optimized. You will not save significant bundle size by converting.

If the receiving team will continue developing the UI: Handing off raw vanilla CSS is worse than handing off Tailwind if the team knows Tailwind. Give them the Tailwind source.

If you are maintaining both versions: Keeping Tailwind source and vanilla CSS output in sync is a maintenance burden. Any change in the Tailwind version must be manually reflected in the CSS. This creates drift over time.

If the project might add Tailwind later: Converting now means re-adding Tailwind later will require re-converting. If there is a reasonable chance the project will adopt Tailwind, wait.

The best candidates for conversion are: distributable components, code that needs to outlive any particular CSS framework trend, handoffs that are genuinely final with no further Tailwind usage, and learning exercises.

---

CSS Tools to Support the Conversion

The Tailwind to CSS converter handles the primary conversion automatically. Once you have the raw CSS output, several other tools help you refine and optimize it:

• CSS Minifier - Remove whitespace and comments from the converted CSS for production
• Color Converter - Translate Tailwind hex colors to HSL or other formats
• Box Shadow Generator - Visually create and fine-tune shadow values
• Border Radius Generator - Preview and adjust border radius values
• Gradient Generator - Create gradient backgrounds to replace Tailwind gradient utilities
• CSS Grid Generator - Build and visualize CSS Grid layouts visually
• CSS Flexbox Generator - Configure flexbox layouts with a visual editor
• Color Contrast Checker - Verify that converted color combinations meet WCAG contrast requirements

---

Convert Instantly

Paste your Tailwind HTML into the Tailwind to CSS converter and get clean CSS output in seconds. The tool handles the full range of Tailwind utilities including responsive prefixes, state variants, and dark mode. No signup required, runs entirely in your browser.

After conversion, use the CSS Minifier to optimize the output for production. For color work, the Color Converter and Color Palette tools help you build a consistent design token system from the Tailwind color values in your converted CSS.