"Doesn't this vibrant green in our logo look a bit muted on screen?"—when building brand websites in client projects, we often encounter concerns that colors from printed collateral or brand guides appear dull on the web. A designer's vivid key color turns noticeably more subdued on monitors. While easy to dismiss as individual display variance, the root cause is far more fundamental: the web has historically been restricted to the narrow color gamut known as sRGB. Vivid colors sat outside that boundary, with no mechanism available to display them.
This assumption is changing. As highlighted in Where to Find the Colors Your Screen Can’t Show You (moultano), many modern smartphones and laptops can render Display P3, a color space significantly wider than sRGB. CSS can now explicitly specify these wider colors. In this article, we explore from a production standpoint how to leverage wide-gamut colors in client work to keep brand colors vibrant without breaking older screens.
Why brand colors look dull on screen: The container size of color gamuts
A color gamut is, broadly speaking, the range of colors a given system can produce. sRGB is a standard established a quarter-century ago, tailored to the monitors of that era with a relatively narrow range. Vivid reds, greens, and blues—especially high-saturation colors—simply cannot fit within its boundaries.
The problem is that writing colors in CSS as hex codes like #00C853 or standard rgb() means they are interpreted as colors within the sRGB gamut. No matter how vivid a color you intend to specify, the representation is capped by the size of the sRGB container. Even if the physical screen can display a far more vivid green, the CSS rule only asks for the most vibrant green possible within sRGB, leaving true saturation untapped. This is why brand colors appear dull.
| Dimension | Legacy (sRGB) | Wide gamut (Display P3) |
|---|---|---|
| Reproducible color range | Narrow (high-saturation colors capped) | Wide (reaches more vivid tones) |
| CSS syntax | #00C853 / rgb() | color(display-p3 ...) / oklch() |
| Unsupported displays | — | Displays in sRGB via fallback |
The concept of managing colors via deliberate CSS declarations rather than leaving them to chance builds upon the philosophy of managing colors systematically, as covered in our article on automatically adjusting color schemes with CSS contrast-color. Keeping container size in mind changes how you view color definitions.
Specifying wide-gamut colors: color() and oklch()
There are two primary methods for specifying wide-gamut colors in CSS.
First is using color(display-p3 ...) to write colors directly within the Display P3 gamut.
.brand {
/* sRGBでは出せない、より鮮やかな緑を直接指定する */
color: color(display-p3 0 0.8 0.35);
}Second is oklch(), a syntax that models how humans perceive color. Because lightness, chroma, and hue are specified separately, adjustments like boosting saturation while preserving lightness are intuitive, making it an excellent fit for design system tokens. oklch() can also represent vibrant colors outside sRGB.
The critical takeaway is that both formats can request colors outside the sRGB container. This unlocks full native vibrancy on supported screens. However, this must always be paired with consideration for unsupported displays.
Why fallbacks are essential in client work
Specifying wide-gamut colors without fallbacks risks colors failing to render or appearing unpredictably on older, unsupported screens. In client projects, omitting this safeguard leads to visual breakage for specific users. The standard pattern is a two-tiered approach: declare the sRGB color first, then override it with wide-gamut values only for supported displays.
.brand {
color: #00C853; /* どの画面でも出る、sRGBの近い色 */
}
@supports (color: color(display-p3 0 0 0)) {
.brand {
color: color(display-p3 0 0.8 0.35); /* 対応画面ではより鮮やかに */
}
}@supports checks whether the browser supports a specific CSS capability, applying wide-gamut styles only where supported. On unsupported screens, the preceding sRGB color remains active. This achieves a resilient experience where supported screens display rich saturation while unsupported displays show a reasonable sRGB approximation. Progressively enhancing modern CSS features based on support mirrors the Baseline approach covered in our article on native modern CSS features.
Pitfalls When Integrating Agents in Custom Development
On a cosmetics brand site where we took over development (keeping the company name confidential), there was long-standing dissatisfaction that the brand color banner beside vibrant product photos looked dull and disconnected from the photography. The previous agency made incremental hex code tweaks, but because they worked inside the sRGB container, they could never match the photos' vibrancy.
We redefined the brand color palette using oklch() and applied vibrant Display P3 values via @supports exclusively to capable screens. Non-compatible screens continued receiving the familiar sRGB approximation. As a result, the banner on supported displays matched the photo vibrancy, resolving the complaint. All we did was lift the color out of the sRGB container and request the range the hardware was capable of displaying.
What proved most effective in this project was centralizing colors into design tokens. By managing colors centrally through oklch() variables, sRGB fallbacks and P3 values are paired together, allowing brand color adjustments to occur in a single place. The benefit of consolidating color variations into CSS declarations mirrors what we discussed in our article on crafting brand expressions with CSS corner-shape; managing colors as a system alongside shapes makes maintenance dramatically easier. Note that wide color gamuts are simply an enhancement for vibrancy; text contrast for readability must still be secured separately. Vibrancy and accessibility only deliver real value when paired together.
Where to begin
Moving away from blaming screens for dull brand colors and recognizing the container size of color gamuts allows a website's palette to regain its intended vibrancy. By requesting wide colors with color(display-p3 ...) or oklch() and safeguarding unsupported screens via @supports and sRGB fallbacks, you can safely elevate visual vibrancy without risk.
As a first step, select a single primary brand color on your site where vibrancy matters most, set an sRGB base, and test overriding it with Display P3 on supported screens. Once you confirm it degrades gracefully across both supported and unsupported environments, it is ready for production.
If vivid brand guidelines look washed out on the web, photos clash with muted brand accents, or you want to manage colors securely as design tokens, contact us through GleamHub's inquiry form. We will review your current color architecture, identify opportunities to elevate your brand with wide gamuts while maintaining fallbacks, and build a maintainable structure.
