Tailwind CSS v4 – Was ist neu? Alle Features im Überblick

1. Tailwind CSS v4: Was hat sich wirklich verändert?

Tailwind CSS v4 markiert den bisher größten Versionssprung in der Geschichte des Frameworks. Anders als die Übergang von v1 zu v2, der hauptsächlich neue Utility-Klassen brachte, oder v2 zu v3, der den JIT-Compiler einführte, ist Tailwind CSS v4 eine komplette Neuarchitektur von Grund auf. Der Build-Stack wurde von JavaScript nach Rust migriert, das Konfigurationsformat von JavaScript nach CSS gewechselt und die interne Verarbeitungslogik vollständig neu geschrieben. Das Ergebnis ist ein Framework, das dieselbe vertraute Utility-Klassen-API bietet, aber mit fundamentalen Verbesserungen bei Performance, Flexibilität und der Nähe zur CSS-Plattform.

Die wichtigste konzeptionelle Änderung in Tailwind CSS v4 ist der Wechsel zum CSS-First-Ansatz. Bisher war Tailwind ein Tool, das über JavaScript konfiguriert wurde und CSS ausgab. In v4 ist Tailwind ein Tool, das CSS als Eingabe und Konfiguration nimmt und optimiertes CSS ausgibt. Diese Verschiebung hat weitreichende Konsequenzen: Das Tooling wird einfacher, die Lernkurve für CSS-Entwickler flacher, und die Integration in bestehende CSS-Workflows nahtloser. Für Teams, die bereits mit CSS Custom Properties arbeiten, fühlt sich Tailwind CSS v4 wie eine natürliche Erweiterung an statt wie ein separates Framework mit eigener Konfigurationssprache.

Wichtig für die Einschätzung: Tailwind CSS v4 ist nicht abwärtskompatibel zu v3. Es gibt Breaking Changes bei einigen Klassen, bei der Konfigurationsmethode und beim Plugin-System. Für neue Projekte ist v4 klar die richtige Wahl. Für bestehende Projekte ist eine Migration erforderlich, die je nach Komplexität des Projekts zwischen einigen Stunden und mehreren Tagen dauern kann.

2. Die Oxide-Engine: Rust statt Node.js

Der Kern der Änderungen in Tailwind CSS v4 ist die neue Oxide-Engine, eine in Rust geschriebene Neuimplementierung des gesamten Build-Prozesses. In Tailwind v3 war der Build-Prozess eine Node.js-Anwendung, die PostCSS-Plugins, JavaScript-Evaluation der Konfigurationsdatei und String-Matching für das Klassen-Scanning kombinierte. In v4 übernimmt Oxide diese gesamte Pipeline als nativer Binärcode: CSS-Parsing, Klassen-Scanning, Utility-Generierung und CSS-Ausgabe – alles in Rust.

Die Performance-Auswirkungen sind erheblich. In den offiziellen Benchmarks der Tailwind CSS v4-Entwickler wurden volle Rebuilds bis zu 3,5x schneller gemessen, inkrementelle Rebuilds bis zu 8x schneller und initiale Builds bis zu 100x schneller als Tailwind v3 mit aktiviertem JIT-Compiler. In der Praxis bedeutet das, dass selbst große Projekte mit tausenden von Klassen und hunderten von CSS-Dateien binnen Millisekunden neu gebaut werden. Der Watch-Modus reagiert nahezu in Echtzeit auf Dateiänderungen – ein spürbarer Unterschied im täglichen Entwicklungsworkflow.

/* main.css — Tailwind CSS v4 entry point (no tailwind.config.js needed) */
@import "tailwindcss";

/* Automatic source detection — Tailwind v4 scans linked files automatically */
/* For explicit paths use @source */
@source "../templates/**/*.{html,php,phtml}";
@source "../src/**/*.{js,ts,vue,jsx,tsx}";

/* @theme replaces the entire "theme" section of tailwind.config.js */
@theme {
  --color-brand-50:  #eff6ff;
  --color-brand-500: #3b82f6;
  --color-brand-900: #1e3a8a;

  --font-sans: "Inter", ui-sans-serif, system-ui, sans-serif;
  --spacing-18: 4.5rem;
}

/* No postcss.config.js required with the Vite plugin or standalone CLI */
/* Installation: npm install tailwindcss@next @tailwindcss/vite */

Die Oxide-Engine bringt auch eine automatische Quellen-Erkennung mit. In Tailwind v3 musste das content-Array in tailwind.config.js alle zu scannenden Dateipfade aufführen. Tailwind CSS v4 erkennt die meisten Projektstrukturen automatisch: Es folgt @import-Ketten, liest verknüpfte JavaScript-Dateien und scannt Standard-Verzeichnisse. Für Projekte mit nicht-standardmäßigen Strukturen – wie Magento-Themes oder PHP-Templating-Systeme – gibt es die explizite @source-Direktive als Ersatz für das content-Array.

3. CSS-First-Ansatz: @theme statt tailwind.config.js

Der CSS-First-Ansatz ist die sichtbarste Änderung für Entwickler, die mit Tailwind CSS v4 arbeiten. Die @theme-Direktive nimmt CSS Custom Properties mit standardisierten Präfixen entgegen und generiert daraus sowohl Tailwind-Utility-Klassen als auch native CSS-Variablen im :root. Das bedeutet: Konfiguration und Ausgabe befinden sich in derselben Sprache, und Design-Tokens sind zur Laufzeit als CSS-Variablen verfügbar – nicht nur zur Build-Zeit.

Die Präfix-Konvention in Tailwind CSS v4 @theme ist klar strukturiert: --color-* für alle Farb-Utilities (bg, text, border, ring, outline…), --font-* für Schriftfamilien, --text-* für Schriftgrößen, --leading-* für Zeilenhöhen, --spacing-* für das komplette Spacing-System, --radius-* für Border-Radien, --shadow-* für Box-Shadows und --blur-* für Blur-Werte. Ein Token wie --color-brand-600: #2563eb erzeugt automatisch bg-brand-600, text-brand-600, border-brand-600, ring-brand-600 und alle weiteren Farb-Utilities.

4. Native @import-Unterstützung und Dateistruktur

Tailwind CSS v4 verarbeitet native CSS @import-Anweisungen selbst, ohne auf PostCSS-Plugins wie postcss-import angewiesen zu sein. Das bedeutet, dass eine Hauptdatei alle Teil-CSS-Dateien per @import einbinden kann, und Tailwind den gesamten Baum verarbeitet – einschließlich der @theme-Blöcke in importierten Dateien. Die Reihenfolge der Imports ist bedeutsam: Spätere Deklarationen überschreiben frühere, was die Implementierung von Theme-Overrides für Multisite-Projekte ermöglicht.

Empfohlene Dateistruktur für ein Tailwind CSS v4-Projekt: Eine app.css als Einstiegsdatei mit @import "tailwindcss", gefolgt von projektspezifischen @import-Direktiven für Tokens, Base-Layer-Erweiterungen und Komponenten. Große Projekte profitieren von einer klaren Aufteilung: tokens/colors.css, tokens/typography.css, tokens/spacing.css, components/buttons.css, components/cards.css. Diese Struktur ist wartbarer als eine monolithische CSS-Datei und macht die Aufteilung von Verantwortlichkeiten im Team einfacher.

/* Tailwind CSS v4 — custom @variant and @utility directives */

/* @variant: defines a new variant modifier (like hover:, focus:, dark:) */
@variant hocus {
  /* Applied when hovered OR focused — combines hover and focus */
  &:hover, &:focus-visible {
    @slot;
  }
}

/* @variant for custom breakpoint modifiers */
@variant tablet {
  @media (min-width: 640px) and (max-width: 1023px) {
    @slot;
  }
}

/* @utility: adds new utility classes to Tailwind's utility layer */
@utility content-auto {
  content-visibility: auto;
}

@utility snap-proximity {
  scroll-snap-type: both proximity;
}

/* Usage in HTML: class="hocus:bg-brand-500 tablet:text-center content-auto" */
/* These are now first-class Tailwind utilities with all variant support */

5. @variant: Custom Variants in CSS definieren

Variants in Tailwind sind die Präfixe wie hover:, focus:, dark:, sm:, die Utility-Klassen für spezifische Zustände oder Kontexte aktivieren. In Tailwind CSS v3 konnten Custom Variants nur über das Plugin-System in JavaScript erstellt werden. Tailwind CSS v4 macht das direkt in CSS möglich: Die @variant-Direktive definiert einen neuen Variant-Namen und den zugehörigen CSS-Kontext. Das @slot-Marker gibt an, wo die generierten Stile eingefügt werden.

Custom Variants in Tailwind CSS v4 mit @variant sind vollwertige First-Class-Variants. Sie können mit anderen Variants kombiniert werden (dark:hocus:bg-brand-500), responsive Prefixes nutzen (sm:hocus:text-lg) und funktionieren in allen Kontexten, in denen eingebaute Variants funktionieren. Häufige Anwendungsfälle: ein hocus-Variant für kombinierte Hover- und Focus-Zustände (für bessere Accessibility), ein print-Variant für Druckstile, oder ein rtl-Variant für arabische und hebräische Texte in Bilingualseiten.

6. @utility: Eigene Utility-Klassen ohne JavaScript

Die @utility-Direktive in Tailwind CSS v4 erlaubt es, neue Utility-Klassen direkt in CSS zu definieren, die sich wie eingebaute Tailwind-Utilities verhalten. Das bedeutet: Variant-Unterstützung, Responsive-Unterstützung und korrekte CSS-Layer-Zuordnung werden automatisch übernommen. In v3 erforderte das equivalente Ergebnis ein Plugin in JavaScript. Die @utility-Direktive macht den Übergang von Utilities von Plugins zu CSS nahtlos.

Ein wichtiger Unterschied zu @layer utilities: Klassen in @utility werden von Tailwind CSS v4 als vollwertige Utilities registriert. Sie erscheinen im richtigen Cascade-Layer, können mit beliebigen Variants kombiniert werden und profitieren von zukünftigen Framework-Features. Klassen in @layer utilities hingegen werden zwar im gleichen Layer platziert, aber nicht als Framework-Utilities registriert – ein subtiler, aber bedeutsamer Unterschied bei komplexen Projekten mit vielen Custom Utilities.

7. Breaking Changes und wichtige Verhaltensänderungen

Tailwind CSS v4 hat einige Breaking Changes, die bei der Migration aus v3 beachtet werden müssen. Die wichtigsten: Der Separator für Variants wurde von : beibehalten, aber einige veraltete Variant-Kombinationen funktionieren nicht mehr. Die Klasse text-opacity-* wurde durch text-[color]/[opacity] ersetzt – zum Beispiel text-brand-500/80 statt der alten Kombination aus text-brand-500 und text-opacity-80. Diese neue Syntax ist eleganter und schon in v3 verfügbar gewesen, aber in v4 ist das alte Muster entfallen.

Das darkMode-Konfigurationsformat aus tailwind.config.js entfällt in Tailwind CSS v4 komplett. Dark Mode wird jetzt entweder über das eingebaute dark:-Variant gesteuert (das standardmäßig auf prefers-color-scheme reagiert) oder durch eine Custom @variant dark-Deklaration, die einen eigenen Selektor verwendet. Das klingt nach mehr Aufwand, bietet aber mehr Flexibilität: Man kann Dark Mode per CSS-Variable steuern, per Klasse oder per Media Query – alles ohne JavaScript-Konfiguration. Außerdem entfällt das prefix-Konfigurationsfeld; in Tailwind CSS v4 wird ein globaler Prefix über @import "tailwindcss" prefix(tw) gesetzt.

8. Tailwind CSS v3 vs. v4 im direkten Vergleich

Der direkte Vergleich der wichtigsten Aspekte zeigt, was Tailwind CSS v4 gegenüber v3 konkret verbessert.

Was sich in Tailwind CSS v4 nicht ändert: die gesamte Utility-Klassen-API. Alle bekannten Klassen wie flex, grid, p-4, text-lg, bg-blue-500, hover:opacity-80, sm:grid-cols-2 funktionieren exakt wie bisher. Das HTML muss nicht angepasst werden – nur die Konfiguration und der Build-Prozess ändern sich. Das minimiert das Migrationsrisiko erheblich: Man kann die Migration auf die Konfigurationsdatei und den Build-Prozess beschränken und das HTML unberührt lassen, bis auf die wenigen Breaking Changes bei veralteten Klassen.

9. Migration von v3 zu Tailwind CSS v4

Die Migration eines bestehenden Projekts zu Tailwind CSS v4 beginnt mit der Installation der neuen Pakete. Das Einstiegspunkt-Paket ist jetzt tailwindcss (für die CLI) oder @tailwindcss/vite für Vite-Projekte, @tailwindcss/postcss für PostCSS-Setups. Die offiziellen Tailwind-Entwickler stellen ein automatisiertes Upgrade-Tool bereit: npx @tailwindcss/upgrade analysiert das Projekt, konvertiert tailwind.config.js in @theme-CSS und aktualisiert die CSS-Eingabedatei. Für die meisten Standard-Projekte übernimmt dieses Tool den Großteil der Migration automatisch.

Manuell prüfen muss man bei der Migration zu Tailwind CSS v4 vor allem: Plugins, die die addUtilities- oder addComponents-API aus v3 nutzen; eigene Varianten, die über das Plugin-System erstellt wurden; Farbopazitäts-Klassen (text-opacity-*, bg-opacity-*), die durch die neue Slash-Syntax ersetzt wurden; und den darkMode-Konfigurationsschlüssel. Für Projekte, die PostCSS-Plugins wie postcss-import oder autoprefixer verwendet haben: In v4 sind diese oft nicht mehr nötig, da Tailwind @import nativ verarbeitet und moderne Browser-Autoprefixing meist nicht mehr benötigen.

/* Migration example: v3 tailwind.config.js → v4 @theme CSS */

/* === v3: tailwind.config.js ===
module.exports = {
  darkMode: 'class',
  content: ['./src/**/*.{html,js,ts,vue}'],
  theme: {
    extend: {
      colors: {
        brand: { 500: '#3b82f6', 700: '#1d4ed8' },
        accent: '#0ea5e9',
      },
      fontFamily: {
        sans: ['Inter', 'ui-sans-serif', 'system-ui'],
      },
      borderRadius: {
        card: '1rem',
      },
    },
  },
}
*/

/* === v4: app.css (CSS-First) === */
@import "tailwindcss";
@source "../src/**/*.{html,js,ts,vue}";

@theme {
  /* Colors — generates bg-brand-500, text-brand-700, etc. */
  --color-brand-500: #3b82f6;
  --color-brand-700: #1d4ed8;
  --color-accent:    #0ea5e9;

  /* Font family */
  --font-sans: "Inter", ui-sans-serif, system-ui;

  /* Border radius */
  --radius-card: 1rem;
}

/* Dark mode: @variant replaces darkMode: 'class' */
@variant dark (&:where(.dark, .dark *));

10. Zusammenfassung: Lohnt sich das Update?

Für neue Projekte ist die Antwort eindeutig: Tailwind CSS v4 ist die richtige Wahl. Der CSS-First-Ansatz ist konzeptionell sauberer, die Oxide-Engine ist erheblich schneller, und die neuen Direktiven @variant und @utility machen das Framework flexibler ohne die Komplexität von JavaScript-Plugins. Die Lernkurve für Entwickler, die CSS kennen, ist geringer als bei v3 mit seiner tailwind.config.js.

Für bestehende Projekte hängt die Entscheidung von der Komplexität ab. Das offizielle Upgrade-Tool übernimmt die meisten Standard-Migrationen automatisch. Projekte mit vielen Custom-Plugins oder komplexen Konfigurationen brauchen mehr manuelle Arbeit. In beiden Fällen gilt: Tailwind CSS v4 ist das Framework, auf das sich zukünftige Entwicklung konzentriert. Längerfristig ist die Migration unvermeidlich – früh migrieren ist einfacher als spät.