A gradient that looked perfect in the design file can behave badly once it lands in the browser. Bands appear where the interpolation should be smooth. A midtone shifts from cool to muddy. Contrast fails accessibility checks even though the original palette passed. Most of these problems are not design mistakes; they are surprises in how the interpolation math and the rendered medium agree — or disagree.
This article is a debugging checklist. It walks through the data, the edge cases, and the rules that quietly govern how a CSS gradient is actually computed, so a developer or designer can pinpoint why a transition looks wrong and fix it without guessing.
What the browser actually interpolates
When you write linear-gradient(90deg, #3b82f6, #ef4444), the browser does not blend the two endpoints evenly across the axis. It interpolates each channel — red, green, blue, and alpha — in the working color space the engine has chosen for that property. Modern engines default to sRGB for the legacy linear-gradient() syntax, but the math depends on whether alpha is involved and whether the renderer falls back to a simpler model on a low-end GPU.
The practical takeaway: if your two stops are in sRGB but your image is exported in Display P3, the visible midpoints will not match what you see in the design tool. This is one of the first things to check when a banded appearance shows up in screenshots but not in the source file. For a deeper walkthrough of the underlying channel-by-channel arithmetic, the Lizely guide on generating gradient colors lays the steps out in sequence.
The MDN reference for the <gradient> data type is the canonical place to confirm which functions are stable across engines and which still require prefixes or feature queries.
Why banded bands appear, and how to test for them
Visible bands — sometimes called "mach bands" — show up when the eye catches a small luminance step inside what should be a continuous mix. They get worse when:
- The two stops differ in luminance more than they differ in chroma, so the eye locks onto the brightness axis.
- The gradient runs over a large physical area at low DPI, where each rendered pixel covers a meaningful step.
- The interpolation happens in a space that does not match the viewing space (sRGB mixed with a wide-gamut display).
A practical test: render the gradient at the exact size it will appear on screen, screenshot it, and reduce the screenshot to grayscale. If banding is visible in the grayscale version, the problem is in the luminance channel, not the hue. If it disappears in grayscale but is visible in color, the issue is the chroma path.
The Color module on MDN explains the available color functions and how they map to spaces. When you suspect a space mismatch, switching one or both endpoints to color(display-p3 …) or to an oklch() value often reduces the visible stepping without changing the design intent.
A reference checklist for QA review
Before a gradient ships, walk the artifact through this list. Each item catches a class of bugs that is cheap to test and expensive to ship.
- Render at the final CSS size, not at 1× zoom in the inspector. Re-screenshot and inspect at 100%.
- View the gradient on at least one wide-gamut (P3) display and one standard sRGB screen; diff the midpoints.
- Run each midpoint against WCAG AA contrast against both the lightest and darkest adjacent background the component might sit on.
- Confirm the
background-sizematches the intended dimension. A 3200 px gradient stretched into a 320 px container hides banding that the production page will expose. - Verify that each
linear-gradient()declaration lives inside a property that supports images; pasting one into aborder-colorrule silently fails. - Check the cascade order. A later rule that sets
background-image: nonewill erase the mix even if the shorthand survives.
If an automated visual diff is in place, capture the gradient as part of the baseline image. Pure pixel diffing catches regressions a unit test never will.
Common failure modes in production code
A few patterns recur in code review and incident reports.
Silent fallback to a single color. When background-image is set on an element that is later hidden and re-shown by a JavaScript framework, some animation paths replace the background with a solid color. The gradient is not "broken"; it has been replaced. The fix is to put the mix on a layer or pseudo-element that does not get toggled.
Prefix leakage. Older Safari builds need -webkit-linear-gradient(). If a build step strips prefixes or a CSP forbids inline styles, the modern syntax alone produces no visible result on legacy clients. A feature query or a runtime check can decide which form to emit.
Interpolation drift after a redesign. Designers move a brand color from a hex value to an HSL declaration. Both forms can express the same color, but if the gradient builder script parses hex and emits rgb(), a later redesign that feeds in HSL produces a different midpoint because the parser stores the value in a different space. Centralize the input format in the design system, or normalize everything to one canonical representation before interpolation.
Performance on long lists. A list of 500 cards, each with its own background: linear-gradient(...), forces the compositor to evaluate 500 separate paint operations. A single shared mix on the parent plus a per-card tint via mix-blend-mode or filter is usually faster and visually identical.
Edge cases worth encoding in the team's gradient spec
Specs that survive contact with a real codebase tend to make the boring cases explicit. For example:
- A gradient must be defined with at least two stops. A single-stop declaration is invalid; some browsers treat it as
transparent, others ignore it. Either encode the constraint at lint time or always emit two. - Stops beyond the
0%–100%range are legal and create a hard color edge. Decide whether your system permits them; if not, reject at build time. - Direction keywords (
to right,45deg) and the new angle syntax are not equivalent at boundaries. The CSS Images Module Level 3 defines the exact resolution rules; engineers writing a generator should normalize to one form before comparison.
A reusable artifact here is a JSON schema for gradient definitions: a list of stops with position, color, and an optional hint field for midpoint offsets. Both the design tool and the build pipeline consume the same schema, so a change in stop positions or space propagates without translation drift.
Frequently asked questions
Why does my gradient look fine in Chrome and banded in Safari?
The most likely cause is a difference in how each engine handles the working color space. Safari on some platforms still falls back to legacy sRGB interpolation for the standard syntax even when the display advertises P3. Re-declaring the stops in oklch() or color(display-p3 …) forces both engines onto a defined space and usually equalizes the result. Verify on real hardware, not in the simulator.
Can I animate a gradient smoothly with CSS transitions?
You can transition the background-position of a gradient or the background-size of a tiling gradient, but you cannot transition individual stops in a linear-gradient() declaration. The browser does not interpolate function arguments; it swaps the whole property at the midpoint of the transition. For animated stops, the common workaround is to layer two elements and animate their opacity, or to drive the value from a CSS variable that a JavaScript animation rewrites each frame.
What is the cheapest way to test a gradient for accessibility?
For text on top of a gradient, contrast is not a single number — it varies along the surface. A pragmatic approach is to pick three sample points (10%, 50%, 90% along the axis), compute the contrast against the text color at each, and require that all three pass your threshold. If any fails, either tighten the mix so the luminance range narrows, or apply a scrim layer under the text. The W3C's Web Content Accessibility Guidelines define the contrast formula; use it directly rather than eyeballing the result.
My gradient generator output uses different color stops than my design tool. Which is right?
Neither is "wrong" in isolation. The mismatch usually comes from a difference in the color space used for the interpolation step. Inspect both endpoints in each tool. If one is showing sRGB hex and the other is showing a P3 value that re-renders as sRGB on a wide-gamut display, normalize the inputs to one canonical space before you compare. A small amount of discipline at the input boundary prevents hours of pixel-level debugging later.
This article was drafted with AI assistance and reviewed for technical accuracy before publishing.
