Tailwind CSS v4: What Changed and Why It's Faster

Tailwind CSS v4 is not a coat of paint on v3 — it's a ground-up rewrite of the engine, a rethink of how you configure it, and a big bet on modern CSS. If you've been away from Tailwind for a release or two, the changes are large enough to be worth a proper tour. This site runs on v4, so the examples here are the real thing.

A new engine under the hood

The headline of v4 is speed. The team rebuilt the core compiler from scratch, and the difference is not subtle — full builds are several times faster, and incremental builds that used to take hundreds of milliseconds now finish in single-digit milliseconds.

The Oxide rewrite

The new engine, internally called Oxide, moves the hot paths to Rust and rethinks how Tailwind scans your code for class names. Instead of asking you to enumerate every file in a content array, v4 automatically detects your template files and only does the work that changed. The result is that the build step mostly disappears from your mental budget — it's fast enough to forget about.

Configuration moves to CSS

The biggest workflow change is where your design tokens live. In v3, you configured colors, spacing, and fonts in a JavaScript object inside tailwind.config.js. In v4, configuration moves into your CSS file.

The @theme directive

You define your design system with the @theme directive, declaring tokens as CSS custom properties. Tailwind turns each one into a utility class and a real CSS variable you can reference anywhere.

@import "tailwindcss";

@theme {
  --color-brand:   #DBFF70;
  --color-surface: #0d1f05;
  --font-display:  "Halant", serif;
}

That single block gives you bg-brand, text-brand, font-display, and friends — plus var(--color-brand) for the times you need to drop down to raw CSS. Keeping tokens in CSS means your design system and your stylesheet are the same artifact, with no JavaScript config to keep in sync.

What you gain

Native cascade layers and modern CSS

v4 leans into platform features that weren't widely available when v3 shipped. It emits native CSS cascade layers (@layer) so utility precedence is predictable, and it uses modern color spaces, container queries, and color-mix() out of the box. You write less configuration because the platform now does more.

• Container queries are first-class, no plugin required.
• color-mix() lets you tint and fade tokens inline without defining new shades.
• Cascade layers make overriding utilities deterministic instead of a specificity guessing game.

Migrating from v3

For most projects the path is smooth. There's an official upgrade tool that handles the bulk of it: moving your config into CSS, renaming a handful of utilities, and updating the import. The things to watch for are custom plugins and any place you relied on the old JavaScript config at runtime. Budget an afternoon for a medium app, not a week.

The bottom line

Tailwind v4 is the rare major version that's both faster and simpler. The CSS-first configuration takes a few minutes to get used to, and then it feels obviously correct — your tokens, your utilities, and your stylesheet are finally one thing. If you've been hesitating, the upgrade tool removes most of the excuse.

Frequently Asked Questions

Is Tailwind v4 backwards compatible with v3?

Mostly, but not entirely. The class names you use day to day are largely unchanged, but configuration moves to CSS and a few utilities were renamed or removed. The official upgrade tool automates most of the migration for you.

Do I still need a tailwind.config.js file?

No. v4 is configured through CSS using the @theme directive and related at-rules. A JavaScript config is still supported for advanced cases, but the default and recommended approach is CSS-first, and most projects won't need the JS file at all.

Is the JIT compiler gone?

The concept of a separate "JIT mode" is gone because it's no longer a mode — generating only the utilities you actually use is simply how the new engine works. You don't enable anything; it's the default behavior.

How much faster is v4 really?

In practice, full builds are several times faster than v3, and incremental rebuilds drop into the single-digit-millisecond range. For large projects the difference is the gap between noticing the build and not noticing it at all.