2026-09-10 · 6 min read · Rahul Chitturi
- css
- oklch
- color
An oklch() color can be syntactically valid while lying outside the gamut of an sRGB display. Browsers must map or clip the requested color for rendering, so an exported hex value, screenshot, design token preview, and wide-gamut monitor may not agree.
Increasing chroma does not guarantee a more vivid visible result. Near a gamut boundary it can shift the rendered hue or collapse several tokens into nearly the same device color.
Identify parsing, gamut, and display separately
Inspect the specified CSS, computed style, actual browser and version, display color capability, screenshot pipeline, and any build-time color conversion. Compare a known in-gamut sample before changing the design token.
- Check whether the browser supports oklch() syntax.
- Test the target lightness and hue across increasing chroma.
- Separate CSS fallback selection from gamut mapping.
- Measure the rendered foreground and background pair together.
Provide deliberate fallbacks
Place a broadly supported fallback before the OKLCH declaration so a parser that understands the later value can override it. Use feature queries when a whole component treatment depends on support, and generate fallback colors through one documented conversion pipeline.
Do not assume equal OKLCH lightness guarantees WCAG contrast after gamut mapping, alpha compositing, or display conversion. Test actual rendered combinations and interaction states.
Compare safe tokens in Flashman
Use the color converter for exploratory public tokens, CSS formatter to inspect declaration order, diff for generated fallback changes, and number-base converter when reviewing channel encodings. Treat previews as diagnostics, not color-managed proof across every display.
Test sRGB and wide-gamut devices, dark and light themes, alpha, gradients, disabled and focus states, forced colors, screenshots, PDF export, browser upgrades, and the complete contrast matrix after final mapping.