OKLCH und OKLab 2026: warum moderne CSS-Farben dein RGB hinter sich lassen

Seit Anfang 2026 supporten Chrome 111+, Edge 111+, Firefox 113+ und Safari 15.4+ die Funktionen oklch(), oklab() und color-mix() — zusammen über 95 % der Browser weltweit. Was vor zwei Jahren noch ein experimentelles Feature in Browser-Flags war, ist jetzt produktiv einsetzbar. Ich habe in den letzten drei Projekten konsequent auf OKLCH umgestellt, und das Ergebnis ist verblüffend: gleichmäßigere Farb-Skalen, vorhersehbare Mix-Operationen, deutlich schönere Gradienten. Was OKLCH technisch ist, warum es RGB und HSL schlägt — und wie du dein bestehendes Design-System migrierst.

Warum RGB und HSL schon immer schlechte Farb-Modelle waren

RGB ist ein Hardware-Modell: rot, grün, blau, jeweils 0-255. Es entspricht der Funktionsweise von Bildschirmen, hat aber mit menschlicher Wahrnehmung wenig zu tun. #ff0000 (reines Rot) und #0000ff (reines Blau) sind RGB-symmetrisch, wirken auf das Auge aber komplett unterschiedlich hell. Das ist nicht nur ästhetisch unschön — es bricht jede automatische Helligkeitssortierung.

HSL kam in CSS3 mit dem Versprechen, das zu reparieren: Hue, Saturation, Lightness. Klingt menschenfreundlich. Ist aber leider auch falsch. hsl(60, 100%, 50%) ist Gelb mit »50 % Helligkeit«, hsl(240, 100%, 50%) ist Blau mit »50 % Helligkeit« — aber das Gelb wirkt um Längen heller als das Blau. HSL berechnet die »Lightness« geometrisch im RGB-Würfel, nicht perzeptuell. Wer mit HSL eine Farbpalette baut, bekommt Banding, ungleichmäßige Kontraste und überraschende Mix-Ergebnisse.

Konkretes Beispiel aus einem alten Projekt: ich habe 2022 eine Tag/Nacht-Palette mit HSL gebaut. Bei hsl(200, 80%, L) mit L von 10 % bis 90 % in 10er-Schritten habe ich erwartet, eine gleichmäßige Helligkeitstreppe zu bekommen. Was ich bekam: zwei sehr dunkle Stufen, dann ein abrupter Sprung in einen knalligen Mittelbereich, dann wieder ein paar fast identische helle Stufen am Ende. Die Folge: User-Interface-Designs, in denen »grau-50« und »grau-100« kaum unterscheidbar sind, »grau-300« und »grau-400« aber wie verschiedene Farben wirken.

Was OKLCH besser macht

OKLCH steht für »Oklab Lightness, Chroma, Hue«. Es ist eine zylindrische Variante des OKLab-Farbraums, den Björn Ottosson 2020 entworfen hat. Der entscheidende Punkt: Oklab ist perzeptuell uniform. Das heißt, eine Distanz im Farbraum entspricht ungefähr dem, was das menschliche Auge als »so weit auseinander« empfindet. Wer in OKLCH eine Palette von L=0,1 bis L=0,9 baut, bekommt eine gleichmäßige Helligkeitsskala — über alle Hue-Werte.

Drei Achsen: L (Lightness, 0 bis 1, manchmal als 0–100 % geschrieben). Steht für Helligkeit, wahrnehmungsgerecht. C (Chroma, 0 bis ~0,4). Wie »bunt« die Farbe ist; 0 = grau, je höher, desto kräftiger. H (Hue, 0 bis 360 Grad). Welcher Farbton — 0 = rot, 120 = grün, 240 = blau (ähnliche Konventionen wie HSL, aber mit perzeptuell besseren Übergängen).

Beispiel: oklch(0.7 0.15 250) ergibt ein helleres Blau mit moderater Sättigung. Ändere ich auf oklch(0.7 0.15 50), bekomme ich ein helleres Orange mit derselben perzeptuellen Helligkeit und Sättigung — ich tausche nur den Hue aus. In HSL würde derselbe Tausch ein deutlich helleres Orange als Blau ergeben. OKLCH macht Palette-Bau zur reinen Zahlenarbeit, statt zum visuellen Trial-and-Error.

color-mix() — endlich Farben sinnvoll mischen

color-mix() ist die zweite Killer-Funktion 2026: zwei Farben zu einem prozentualen Anteil mischen, im Farbraum deiner Wahl. color-mix(in oklch, var(--brand) 60%, white) ergibt eine 60 %-Brand-40 %-Weiß-Mischung, im perzeptuell uniformen Farbraum berechnet. In RGB würden derartige Mischungen verschmutzt aussehen — »braungrau« statt »helleres Brand«. In OKLCH bleibt der Hue stabil, die Mischung wirkt natürlich.

Praktischer Einsatz im Design-System: Statt jede Variante einer Brand-Farbe manuell als HSL-Konstante zu pflegen, definiert man die Brand-Farbe einmal und leitet Hover- und Active-States über color-mix() ab. --brand: oklch(0.6 0.2 250); --brand-hover: color-mix(in oklch, var(--brand), white 15%); --brand-active: color-mix(in oklch, var(--brand), black 10%);. Das ist DRY, robust gegen Brand-Refactorings, und es funktioniert in jedem modernen Browser.

Ein zusätzlicher Vorteil: dunkle Modi werden einfacher. Statt für jeden Schatten eine separate Dark-Mode-Variable zu definieren, kann man im Dark Mode den Hintergrund auf dunkleres OKLCH setzen und alle Komponentenfarben mit color-mix() relativ dazu berechnen. Der gesamte Theme-Wechsel kommt mit 3–5 statt 30–50 CSS-Variablen aus. Das war 2024 noch ein Traum, 2026 ist es Standard.

Migration von einer bestehenden Tailwind-Palette

Tailwind CSS hat 2024 begonnen, seine Default-Farben intern auf OKLCH-Basis zu rekonstruieren. Wer Tailwind 4.x nutzt, hat schon eine OKLCH-Palette unter der Haube — auch wenn er weiterhin bg-blue-500 schreibt. Wer aber eine eigene Palette pflegt (etwa für Brand-Farben), profitiert davon, sie auf OKLCH umzustellen.

Migrations-Schritt: bestehende Hex-Codes der Brand-Farben in einen OKLCH-Konverter geben (es gibt Online-Tools, oder unser eigener Color Converter). Den Lightness-Wert in einer Skala von 0,1 bis 0,9 platzieren, Chroma so anpassen, dass die Brand-Farbe noch erkennbar ist. Aus 9 Tonstufen entsteht eine perzeptuell gleichmäßige Skala: --brand-50: oklch(0.95 0.05 H); bis --brand-900: oklch(0.2 0.18 H);, mit konstantem Hue H.

Was du dabei wahrscheinlich entdeckst: deine alte HSL-Skala hat irgendwo zwei Stufen, die fast identisch sind, und eine andere Stufe, die wie ein Sprung wirkt. Das ist nicht dein Fehler — es ist HSL. Nach der OKLCH-Migration sind die Abstände gleichmäßig, das Auge erkennt die Skala intuitiv. Bei mir dauerte die Migration für eine 9-Stufen-Brand-Skala etwa 45 Minuten, das Ergebnis war messbar besser in WCAG-Kontrast-Tests.

Gradient-Renaissance: schönere Verläufe ohne den »Grau-Bauch«

Ein klassisches CSS-Problem: ein linear-gradient(to right, blue, yellow) sieht im Browser nicht aus wie ein Blau-zu-Gelb-Übergang, sondern wie Blau → Schmutziggrün/Schmutziggrau → Gelb. Der Grund ist wieder das RGB-Modell: in der Mitte zwischen Blau und Gelb liegt ein Grau-Wert, durch den der Gradient interpoliert wird.

Mit dem 2024er CSS-Color-4-Update kann man explizit den Interpolations-Farbraum angeben: linear-gradient(in oklch to right, blue, yellow) erzeugt einen Verlauf, der den vollen Farbkreis sauber durchläuft — die Mitte wirkt jetzt wie ein helles Türkis/Grün, nicht wie Grau. Wer ein Logo, ein Hero-Banner oder einen UI-Akzent mit Gradient gestaltet, hat damit ein massiv besseres Werkzeug. Unser CSS-Gradient-Generator unterstützt diesen Modus seit der letzten Version.

Wer es noch raffinierter haben will: color-mix() lässt sich auch in Gradients schachteln. Drei-Stop-Gradienten mit definierten Zwischen-Mix-Punkten geben sehr feines visuelles Tuning. Ein Mesh-Gradient (mehrere überlappende radial-gradients) sieht in OKLCH-Interpolation natürlich seidig aus — die alte RGB-Methode wirkt im Vergleich kantig und verschmutzt. Für UI-Design ist das ein deutlicher Sprung.

Praktische Schritte für deinen nächsten Branch

Eine konkrete Liste, die ich in meinen Projekten 2026 abarbeite:

• Browser-Support prüfen. caniuse.com/oklch und caniuse.com/color-mix — beide grün ab 2026 für > 95 % der User. Wer noch Safari 14 unterstützen muss, fallback mit @supports.
• Eine Brand-Skala migrieren. Beste Ergebnisse: 9-Stufen-Skala mit konstantem Hue und linear interpoliertem L von 0,1 bis 0,9. Chroma mittel halten (0,1 bis 0,15) für gedeckte UI-Farben.
• color-mix() als Hover/Active-Mechanismus etablieren. Spart 50 % der Custom-Properties im Theme.
• Gradients neu evaluieren. Jeder linear- oder radial-gradient sollte den Interpolations-Modus explizit setzen, mindestens in oklch.
• WCAG-Kontrast prüfen. OKLCH liefert vorhersagbarer korrekte Kontraste — aber prüfen muss man trotzdem. Tools wie unser Kontrast-Checker machen das in 10 Sekunden.

Wer noch Zweifel hat, ob das alles im echten Browser ordentlich funktioniert: macht einen Tag oder Nachmittags-Spike in einem Test-Branch. Du wirst sehen, dass die Resultate auf jedem Gerät, das du gerade hast (Mac, iPhone, Android, Windows), konsistenter und schöner aussehen.

Was kommt als Nächstes in CSS Color

Auf dem Tisch der CSS-Working-Group 2026: relative color syntax (color: oklch(from var(--brand) 0.9 c h) — derselbe Brand-Farbton, aber Lightness erzwungen), HDR-Farben für High-Dynamic-Range-Bildschirme (Display-P3, Rec.2020), und schließlich Mesh-Gradients als nativer CSS-Standard (statt manuell mit mehreren radial-gradients gebaut). Erste Implementierungen kommen vermutlich Anfang 2027.

Mein Fazit für 2026: OKLCH ist kein experimentelles Feature mehr, sondern Best Practice. Wer ein neues Projekt startet, sollte direkt mit OKLCH und color-mix() arbeiten — alle modernen Frameworks (Tailwind, MUI, Mantine, Radix) sind kompatibel oder verwenden es intern. Die HSL-Ära ist vorbei; sie hat 15 Jahre lang ihren Zweck erfüllt, aber wir haben jetzt etwas Besseres.

Häufige Fragen

Muss ich alle alten Hex-Codes ersetzen?

Nein. #ff0000 und rgb(255, 0, 0) funktionieren weiterhin. OKLCH ist eine zusätzliche Schreibweise, kein Ersatz. Sinnvoll ist die Umstellung dort, wo du systematisch arbeitest (Brand-Skalen, Theme-Variablen, Gradients). Lookup-Werte wie »rotes X-Symbol« bleiben pragmatisch im Hex-Format.

Was ist der Unterschied zwischen OKLab und OKLCH?

OKLab ist der Grundfarbraum: drei Achsen L (Lightness), a (Grün-Rot), b (Blau-Gelb). OKLCH ist eine zylindrische Umrechnung: L (gleich), C (Chroma — der Abstand von der Grau-Achse), H (Hue — der Winkel im Farbkreis). Für UI-Design ist OKLCH meist praktischer, weil »Hue« intuitiver ist als »a/b«-Koordinaten. Beide sind in CSS verfügbar.

Wie gehe ich mit Gamut-Problemen um?

OKLCH kann Werte beschreiben, die sRGB (das Standard-Bildschirm-Profil) nicht darstellen kann. In so einem Fall führt der Browser ein »Gamut Mapping« durch — er klippt die Farbe auf den nächsten darstellbaren Wert. Für die meisten UI-Farben (mittlere Chroma-Werte) tritt das selten auf. Wer sehr sättigte Farben braucht (Chroma > 0,2), sollte mit dem Browser-Devtools-Color-Picker prüfen, ob die gewünschte Farbe in den Browser-Renderer kommt.

Funktioniert OKLCH auch in E-Mail-HTML?

Größtenteils nein. E-Mail-Clients (Outlook, Gmail Web, Apple Mail) supporten OKLCH bisher kaum, das Outlook auf Windows mit Word-Rendering-Engine zerstört sowieso jedes moderne CSS. Für E-Mail-Templates bleibt Hex/RGB die einzige sichere Wahl. Erst wenn man Web-Komponenten in einer Inbox einbettet, kann man von OKLCH profitieren — aber selbst da nur eingeschränkt.

Wo kann ich OKLCH-Werte besser verstehen lernen?

Drei Quellen, die mir geholfen haben: Björn Ottossons Original-Artikel zu Oklab (bottosson.github.io), Evil Martians' Chronicles-Artikel »OKLCH in CSS« und das oklch.com-Tool zum interaktiven Probieren. Plus: einmal ein eigenes Projekt umsetzen — das schlägt jede Theorie.

Lohnt sich der Wechsel auch für sehr kleine Projekte?

Für eine einzelne Landing-Page mit 3 Farben: ehrlich gesagt nein, Hex reicht. Sobald du eine Brand-Skala, Gradient-Hintergründe, Dark-Mode oder Hover-States hast, ja. Die Investition ist 30–60 Minuten Lernkurve, die danach jedes weitere Projekt schneller und sauberer macht. Mein Daumenwert: ab 5 zusammenhängenden Farben lohnt OKLCH.