OKLCH-Farben in modernem CSS: Warum sie gewinnen und wie du sie auslieferst
Ein praxisnaher Leitfaden zu OKLCH-Farben in CSS. Warum Hex im großen Maßstab versagt hat, wie OKLCH den Helligkeitsdrift behebt, der Migrationsweg in vier Schritten und die wahrnehmungsgleichmäßige Palettenskala, die jedes Designsystem 2026 ausliefern sollte.

OKLCH-Farben in modernem CSS: Warum sie gewinnen und wie du sie auslieferst
OKLCH ist der erste Farbraum, den CSS ausgeliefert hat und über den Designer tatsächlich vernünftig nachdenken können. Teams, die ihre Paletten noch in Hex bauen, verlieren leise jede Kontrast- und Dark-Mode-Diskussion, von der sie gar nicht wussten, dass sie sie führen.
Hex war nie ein Farbraum, sondern eine Serialisierung
Hex ist die Kurzschreibweise für sRGB. #4A90E2 ist keine Farbspezifikation, sondern ein Tripel aus Rot-, Grün- und Blauwerten, gepresst in sechs Zeichen. sRGB wurde Anfang der 1990er für CRT-Monitore entworfen, nicht für die menschliche Wahrnehmung.
Die Folge: Zwei Hex-Werte können in deiner Palette an derselben numerischen „Helligkeitsposition" sitzen und für deine Augen trotzdem völlig verschieden aussehen. Blue-500 wirkt in den meisten Designsystemen dunkler als Yellow-500, obwohl beide dieselbe relative Position in der Skala haben. Das ist kein Geschmacksproblem. Es ist ein Mathematikproblem, das im Koordinatensystem eingebacken ist.
„Hex war nie ein Farbraum, sondern eine Serialisierung, und wir streiten seitdem über Helligkeit."
HSL tat so, als würde es das lösen, und tat es nicht
HSL kam und gab Designern eine Sprache: Farbton, Sättigung, Helligkeit. Es fühlte sich wie ein System an. Das war es nicht. Der Helligkeitskanal in HSL bildet unter der Haube weiterhin auf sRGB-Werte ab, was bedeutet, dass HSL dieselben Wahrnehmungsprobleme erbt wie Hex.
hsl(220, 70%, 50%) und hsl(45, 70%, 50%) haben nominell dieselbe Helligkeit. Leg sie nebeneinander. Das Gelb wirkt deutlich heller. HSL hat dir bessere Worte für dieselbe kaputte Mathematik gegeben.
OKLCH ist wahrnehmungsgleichmäßig
OKLCH basiert auf dem Farbraum OKLab, den Björn Ottosson 2020 speziell entwickelt hat, um die wahrnehmungsbezogene Ungleichmäßigkeit früherer Farbräume zu beheben. Das L in OKLCH steht für wahrgenommene Helligkeit, kalibriert darauf, wie das menschliche visuelle System tatsächlich auf Licht reagiert.
Gleiche L-Werte in OKLCH bedeuten gleiche wahrgenommene Helligkeit. Nicht ungefähr gleich. Nicht „meistens gleich, wenn die Chroma ähnlich ist". Gleich. Diese Eigenschaft konnte kein früherer CSS-Farbraum liefern, und sie verändert alles daran, wie du über Palettengenerierung nachdenkst.
Die drei Gründe, warum OKLCH gewinnt
Wahrnehmungsgleichmäßige Helligkeit, vorhersehbare Farbton-Interpolation und Wide-Gamut-Unterstützung. Jeder davon behebt einen konkreten Bug in deiner aktuellen Palette, und zusammen ergeben sie einen Farb-Workflow, der über Themes, Komponenten und Displaytypen hinweg skaliert.

Grund eins: Helligkeitsdrift ist tot
In Hex- und HSL-Systemen ist Helligkeitsdrift die unsichtbare Steuer, die du auf jede Palette zahlst. Du stellst Blue-50 und Amber-50 nach Augenmaß auf „sieht richtig aus", sie laufen auf verschiedenen Bildschirmen auseinander, sie bekämpfen sich im Dark Mode, und die Kontrastrechnung geht nie ganz auf.
In OKLCH haben Blue-50 und Amber-50 dieselbe Helligkeitszahl, und diese Zahl steht für dieselbe wahrgenommene Helligkeit. Tailwind v4 hat genau deshalb seine gesamte Palette auf OKLCH umgestellt. Wenn du die Farbskalen von Radix UI nutzt, profitierst du bereits von Wahrnehmungsgleichmäßigkeit, selbst wenn du das Wort OKLCH nie in der Dokumentation gesehen hast.
Grund zwei: Farbton-Interpolation ist vernünftig
Verläufe in CSS mit sRGB-Interpolation wandern durch den RGB-Farbwürfel, nicht durch den Wahrnehmungsraum. Ein Blau-zu-Gelb-Verlauf in sRGB führt durch eine matschige graue Mitte, weil die RGB-Diagonale nahe an der unbunten Achse vorbeiläuft. Das ist nicht künstlerisch. Es ist ein Geometrieunfall.
Die OKLCH-Verlaufsinterpolation läuft den Farbwinkel entlang des Wahrnehmungsrings. Blau zu Gelb in OKLCH führt über Cyan und Grün, genau wie dein Auge es erwartet. Der graue Matsch ist weg. Das zählt für UI-Verläufe, animierte Farbübergänge und jedes Palettengenerierungs-Tool, das Zwischenstufen erzeugt.
Grund drei: P3 und Rec2020 sind erreichbar
Hex kann keine Farben außerhalb von sRGB beschreiben. Jedes iPhone seit 2016, jeder moderne Laptop mit Wide-Gamut-Panel und die meisten neuen Consumer-Monitore können Farben darstellen, die im P3-Gamut existieren, aber keine Hex-Adresse haben. Du hast gesättigte, leuchtende Farbe liegen lassen, weil dein Koordinatensystem sie nicht benennen konnte.
OKLCH kann P3- und Rec2020-Farben nativ beschreiben. oklch(0.60 0.28 260) ist ein leuchtendes Blau, das in P3 existiert, aber außerhalb des sRGB-Gamuts liegt. Moderne Browser wissen damit umzugehen, und Apples Display-P3-Farbrichtlinien zeigen seit Jahren in diese Richtung. Das Designsystem, das jetzt auf OKLCH wechselt, ist auch das Designsystem, das bereit ist, wenn P3 zur Standarderwartung wird.
Die Migration von Hex zu OKLCH in vier Schritten
Auditieren, konvertieren, neu generieren, erneut auditieren. Die Migration ist für Primitive Tokens mechanisch und erfordert für Semantic Tokens Urteilsvermögen. Eine komplette Migration eines mittelgroßen Designsystems dauert Tage, nicht Wochen. Am meisten Zeit sparst du, wenn du die neuen Tokens vorher in einer sauberen Figma-Variablen-Architektur verankerst.
Schritt eins: Die bestehende Palette auditieren
Exportiere jeden Farb-Token in deinem System. Konvertiere jeden Hex-Wert mit einem Tool wie oklch.com oder dem PostCSS-OKLCH-Plugin nach OKLCH. Sortiere nach L-Wert und sieh dir die Helligkeitsspalte über alle Farbtöne hinweg an.
Die Bugs zeigen sich sofort. Blue-300 sitzt bei L=0.72, während Yellow-300 bei L=0.87 sitzt. Tokens, die dasselbe visuelle Gewicht haben sollten, liegen meilenweit auseinander. Dieses Audit ist der Beleg, der die Migrationsentscheidung gegenüber jedem leicht begründbar macht, der sich querstellt.
Schritt zwei: Primitive nach OKLCH konvertieren
Nimm die primitive Skala, die rohe nummerierte Stufenfolge statt der Semantic Tokens, und konvertiere sie nach OKLCH. Runde die Helligkeitswerte auf einheitliche Schritte über alle elf Stufen: 0.97, 0.93, 0.86, 0.75, 0.65, 0.54, 0.45, 0.37, 0.27, 0.19, 0.13.
Versuch nicht, die ursprünglichen Hex-Werte exakt zu erhalten. Der Punkt ist, die Inkonsistenz zu beheben. Ein konvertiertes Blue-500 und ein konvertiertes Red-500 werden nicht pixelgenau den alten Werten entsprechen, und genau das ist das Ziel. Das System wird besser, nicht nur anders.
Schritt drei: Die Skalen neu generieren
Mit sauberen, einheitlichen Helligkeitsschritten wird das Neugenerieren der Skalen über alle Farbtöne zu einer Tabellenoperation. Lege die L-Spalte fest, wähle die Chroma für jeden Farbton (Blautöne tragen typischerweise mehr Chroma als Braun und Gelb, bevor sie abgeschnitten werden), passe die H-Spalte an und generiere.
Das Ergebnis: Blue-500 und Red-500 fühlen sich in deinem System zum ersten Mal wie dasselbe visuelle Gewicht an. Die Entscheidungen zur Markenfarbpalette, die bisher willkürliche Ermessensurteile waren, werden zu begründeten Entscheidungen mit einer Koordinate, auf die man zeigen kann.
Schritt vier: Barrierefreiheit erneut auditieren
Neue Palette, neuer Kontrastdurchlauf. OKLCH macht Kontrastvorhersagen leichter, weil Helligkeit jetzt bedeutet, was sie sagt. Zwei Tokens mit bekannten L-Werten zu paaren gibt dir eine starke Vorannahme über ihr Kontrastverhältnis, noch bevor du den Checker öffnest.
Führe WCAG- und APCA-Kontrastprüfungen für alle Semantic-Token-Paarungen durch. Markiere Paare, die die Anforderungen nicht mehr erfüllen, und passe Chroma oder Helligkeit des durchfallenden Tokens an. Ein ordentlicher Durchlauf für barrierefreie Farbkontraste auf einer OKLCH-Palette fördert typischerweise weniger Überraschungen zutage als der gleiche Durchlauf auf einer Hex-Palette, weil die Helligkeitsschritte vorher falsch waren und es jetzt nicht mehr sind.
Du willst ein Farbsystem, das über Modi, Farbtöne und moderne Displays hinweg ohne Helligkeitsdrift trägt? Brainy gestaltet OKLCH-native Palettensysteme, die als Figma-Variablen, CSS Custom Properties und Tailwind-Tokens ausgeliefert werden, mit bereits erledigtem Kontrastdurchlauf.
Die vier OKLCH-Fallstricke
Gamut-Clamping außerhalb des Farbraums, Chroma-Clipping, Alpha-Handling und Tooling-Lücken. Jeder davon beißt Teams, die neu bei OKLCH sind, und jeder hat einen konkreten Fix, der Minuten dauert, sobald du weißt, wonach du suchst.
| Fallstrick | Was passiert | Fix |
|---|---|---|
| Clamping außerhalb des Gamuts | Werte mit hoher Chroma fallen außerhalb von sRGB und werden vom Browser geclampt, wobei sich manchmal der Farbton verschiebt | P3-only-Farben hinter @media (color-gamut: p3) kapseln |
| Chroma-Clipping | Clamping verändert den Farbton leicht, nicht nur die Sättigung | sRGB-sichere Chroma für breite Kompatibilität unter ca. 0.20 halten |
| Alpha-Handling | oklch(0.55 0.20 260 / 0.5) funktioniert bei statischen Füllungen; manche Interpolationspfade in älteren Browsern brechen | Alpha in Verläufen und Übergängen testen, nicht nur bei statischen Farben |
| Tooling-Lücken | Figmas nativer Farbwähler zeigt OKLCH nicht direkt an | Tokens Studio nutzen oder Tokens in CSS definieren und über Figmas Code-Panel referenzieren |
Das Gamut-Problem beißt am härtesten. Wenn du oklch(0.60 0.32 260) schreibst, liegt dieser Chroma-Wert außerhalb von sRGB. Desktop-Browser lösen das, indem sie auf die nächste sRGB-Farbe clampen, was den wahrgenommenen Farbton verschieben kann. Der Fix: Entweder bleibst du für Basis-Tokens bei sRGB-sicherer Chroma, oder du kapselst die Wide-Gamut-Werte hinter einer Media Query und behältst darüber eine Fallback-Deklaration.
Die funktionierende OKLCH-Palettenskala
Eine praxistaugliche Skala mit 11 Stufen bei einheitlichen Helligkeitsschritten, mit Blau bei Farbton 260 als Referenz. Die Helligkeitsschritte sind über jeden Farbton in deinem System identisch. Nur Chroma und Farbton ändern sich pro Farbfamilie.
:root {
--blue-50: oklch(0.97 0.02 260);
--blue-100: oklch(0.93 0.05 260);
--blue-200: oklch(0.86 0.09 260);
--blue-300: oklch(0.75 0.14 260);
--blue-400: oklch(0.65 0.18 260);
--blue-500: oklch(0.54 0.22 260);
--blue-600: oklch(0.45 0.20 260);
--blue-700: oklch(0.37 0.17 260);
--blue-800: oklch(0.27 0.13 260);
--blue-900: oklch(0.19 0.09 260);
--blue-950: oklch(0.13 0.06 260);
}
Um Rot (Farbton 25), Bernstein (Farbton 75) oder Grün (Farbton 145) zu generieren, halte die L-Spalte über alle elf Stufen identisch. Passe C an die natürliche Chroma-Kapazität des Farbtons an: Gelb und Grün tragen weniger Chroma als Blau, bevor sie aus sRGB herausclippen. Passe H auf deinen Zielfarbton an. Das ist das gesamte Palettensystem.
Das Dark-Mode-Farbsystem, das auf dieser Skala aufbaut, nutzt Semantic Tokens, die nach L-Stufe und Farbton zwischen Primitiven wechseln, nicht durch manuelles Überschreiben von Hex-Werten, eins nach dem anderen.

Browser-Unterstützung und das sichere Migrationsfenster
OKLCH wird in jedem großen Browser unterstützt, der seit 2023 erschienen ist. Chrome 111, Safari 15.4, Firefox 113 und Edge 111 liefern allesamt vollständige OKLCH-Unterstützung. Die globale Abdeckung liegt Mitte 2025 über 93 %. Das Migrationsfenster ist offen.
| Browser | OKLCH-Unterstützung | Seit |
|---|---|---|
| Chrome | Vollständig | 111 (Mär. 2023) |
| Safari | Vollständig | 15.4 (Mär. 2022) |
| Firefox | Vollständig | 113 (Mai 2023) |
| Edge | Vollständig | 111 (Mär. 2023) |
| Samsung Internet | Vollständig | 21 (2023) |
Der Fallback für jeden Browser, der OKLCH nicht unterstützt, ist eine einzige Zeile. Deklariere zuerst den Hex-Fallback, dann den OKLCH-Wert. Browser, die OKLCH nicht verstehen, ignorieren ihn und nutzen das Hex. Browser, die es verstehen, nutzen den besseren Wert.
color: #4a7de8; /* sRGB fallback */
color: oklch(0.54 0.22 260); /* OKLCH for modern browsers */
Tailwind v4 generiert seine Palette nativ in OKLCH. Linear, Stripes Sail-Design-Tokens und Apples Entwickler-Farbrichtlinien haben sich alle in Richtung wahrnehmungsgleichmäßiger Systeme bewegt. Die Branche ist angekommen. Die Frage ist, wann dein Team nachzieht.
FAQ
Ist OKLCH schwer zu lernen?
Das Koordinatensystem unterscheidet sich von Hex oder HSL, ist aber nicht komplex. L ist die Helligkeit von 0 bis 1. C ist die Chroma, grob die Sättigung. H ist der Farbton in Grad. Sobald du verinnerlicht hast, dass L wahrgenommene Helligkeit und C Farbigkeit bedeutet, wird das System schneller intuitiv, als HSL es je war.
Kann ich OKLCH heute in Figma nutzen?
Figma zeigt OKLCH Stand 2025 nicht nativ im Farbwähler an. Der praxistaugliche Workflow: Tokens in OKLCH in einer Token-Datei über Tokens Studio oder einer mit Figma-Variablen synchronisierten CSS-Variablen-Datei definieren und dann Figmas Code-Export nutzen, um die Werte zu prüfen. Figmas Rendering-Engine übernimmt die Konvertierung intern.
Macht OKLCH meine bestehenden Hex-Werte kaputt?
Nein. Du kannst OKLCH schrittweise einführen, Token für Token. Deine bestehenden Hex-Werte funktionieren exakt wie zuvor weiter. Die Migration ist additiv, kein Austausch.
Was ist der Unterschied zwischen LCH und OKLCH?
LCH basiert auf dem CIELAB-Farbraum, der wahrnehmungsgleichmäßig ist, aber Probleme mit der Farbton-Linearität hat, besonders im Blau-Violett-Bereich. OKLCH basiert auf OKLab, das diese Farbtonverschiebungen korrigiert. Für die praktische Designarbeit ist OKLCH die bessere Wahl, weil seine Farbton-Interpolation weniger Überraschungen liefert.
Wie konvertiere ich Hex nach OKLCH?
Nutze oklch.com, das PostCSS-oklch-Plugin oder den Playground der CSS-Color-4-Spezifikation. Füge deinen Hex-Wert ein, lies die OKLCH-Koordinaten ab, runde L und C auf zwei Nachkommastellen und H auf den nächsten ganzen Grad. Das ist dein verwendbarer Token-Wert.
Beeinflusst OKLCH die Anforderungen an die Barrierefreiheit?
Die WCAG-Kontrastanforderungen sind gegen die relative Luminanz in sRGB definiert, nicht gegen die OKLCH-Helligkeit. APCA ist enger an Wahrnehmungsmodellen ausgerichtet und lässt sich natürlicher auf OKLCH-L-Werte abbilden. In der Praxis macht OKLCH die Kontrastvorhersage intuitiver, weil L der wahrgenommenen Helligkeit folgt, aber du musst Semantic-Token-Paare trotzdem durch einen Kontrast-Checker laufen lassen. Der Prozess ist derselbe, nur vorab leichter zu durchdenken.
Der Wandel, den OKLCH tatsächlich freischaltet
OKLCH ist kein Trend. Es ist das erste Mal, dass CSS einen Farbraum ausgeliefert hat, der darauf ausgelegt ist, wie menschliche Augen Farbe wahrnehmen, und das Tooling hat weit genug aufgeholt, dass die Migration heute für jedes Team praktikabel ist, das ein paar fokussierte Tage investieren will.
Die Teams, die jetzt wechseln, bekommen drei Dinge auf einmal: eine Palette, die im Dark Mode ohne manuelle Overrides trägt, ein Kontrastverhalten, das zum Koordinatensystem passt, und ein Fundament, das sich ohne späteren Rewrite bis in P3 erstreckt. Die Teams, die warten, werden weiter dieselbe Diskussion führen, warum Blue-300 schwerer wirkt als Orange-300, und die Antwort bleibt dieselbe. Das Koordinatensystem wurde nie für diesen Job entworfen.
Wenn du auf dieser Palette die komplette Token-Architektur aufbauen willst, behandelt das Paper zur Figma-Variablen-Architektur die semantische Ebene. Für die Dark-Mode-Anwendung dieser Arbeit setzt Dark-Mode-Farbsysteme dort an, wo dieses hier endet.
Du willst es für dich gebaut haben? Beauftrage Brainy.
Want a color system that holds up across modes, hues, and modern displays without lightness drift? Brainy designs OKLCH-native palette systems that ship as Figma variables, CSS custom properties, and Tailwind tokens with the contrast pass already done.
Get Started




