Transparent Gradient Dark Edge CSS: Rendering Issue or Bad End Stop?

A transparent gradient dark edge CSS problem looks like a gray or muddy band where a colored fade meets the page. The cause is not always the same. Sometimes the blend picks up an unintended color. Other times a dark stop renders correctly and stays visible while its opacity falls.

This comparison separates those cases, gives you a two-line diagnostic to paste into a test page, and explains how to confirm the result in context. I use the Gradient Generator to preview stops and copy CSS, then edit the output by hand wherever a transparent stop needs to be written explicitly.

Designer's desk with a laptop showing a blue fade over a pale photograph

Is a Transparent Gradient Dark Edge CSS Problem a Bug or a Design Choice?

Short answer: check the stop color and its alpha before blaming the browser. A dark edge has two common sources, and they need different fixes.

  • Unintended blend: the fade passes through colors that neither stop contains, typically because transparent black was treated as a real dark color to blend toward.
  • Correct rendering of a dark stop: the start color is dark, and a partly transparent dark pixel still darkens whatever sits behind it.

The CSS Images Module Level 4 Working Draft, dated September 30, 2025, specifies premultiplied-alpha interpolation between gradient stops. In that model, a fully transparent stop contributes no visible color of its own. MDN’s gradient reference, last modified September 10, 2026, cautions that older browsers may behave differently with the transparent keyword. Neither source gives a universal list of affected versions, so test the browsers you actually support.

I have not measured browser output for this article. Treat the explanations below as reasoning to test in context, not as results.

Translucent blue film sheets fading from deep to clear on a light table

How Does Alpha Interpolation Turn a Fade Into a Dark Band?

Alpha is opacity, from 0 (invisible) to 1 (opaque). A gradient blends two stops that each have a color and an alpha, so there are two ways to do the arithmetic.

Take the dark blue #1E3A8A, which is rgb(30 58 138), fading toward the keyword transparent, which is transparent black, rgb(0 0 0 / 0). Look at the halfway point.

  • Without premultiplication: channels and alpha blend separately. Red, green and blue each move halfway to zero, giving rgb(15 29 69) at alpha 0.5. That is a darker blue than either intended color, and it is the dark band people notice.
  • With premultiplication: each stop is first multiplied by its alpha. The start stays (30, 58, 138) at alpha 1, and the transparent end becomes (0, 0, 0) at alpha 0. The halfway premultiplied value is (15, 29, 69) at alpha 0.5. Dividing by alpha recovers rgb(30 58 138) at alpha 0.5, the original blue at half strength.

These numbers are plain arithmetic, not browser measurements. They show why the specified behavior gives a clean fade: the visible hue stays on the blue while only the opacity falls. CSS Color Level 4 describes the same idea, noting that premultiplication stops transparent black from pulling a visible color toward black.

Alpha interpolation is separate from the choice of interpolation color space. Whether a blend runs in sRGB, OKLab or OKLCH is another decision, which I come back to at the end.

Two stacked horizontal fade banners compared side by side on a neutral wall

Transparent Keyword or Explicit Same-RGB Endpoint: Which Is Safer?

A simple diagnostic uses two hand-written declarations. They are illustrative CSS, not exports from any tool.

.fade-a { background: linear-gradient(to right, rgb(255 255 255 / 1), transparent); }
.fade-b { background: linear-gradient(to right, rgb(255 255 255 / 1), rgb(255 255 255 / 0)); }

In a browser that follows premultiplied interpolation, both should produce the same fade. The second spells out a white endpoint with zero alpha, which is also a useful workaround where an older browser treats transparent as black. If the two look different in a browser you support, you have found a rendering difference rather than a stop problem.

EndpointPremultiplied renderingOlder or non-premultiplied behaviorUse it when
transparent keywordShould keep the start hue while opacity fallsMay pull the fade toward blackYou target current browsers and want short code
Zero-alpha endpoint with the same RGB as the startSame fade as the keywordAvoids an unintended intermediate hueYou support mixed browser versions
Zero-alpha endpoint with a different RGBContributes no visible color of its ownCould tint the middle of the fadeRarely; avoid unless you have tested it
Dark endpoint with alpha above zeroDark color stays visibleNot a rendering issueYou want a deliberate scrim

The last row is the one people most often mistake for a bug. A same-RGB endpoint cannot remove darkening that your starting color intentionally adds.

Why Does a Dark Overlay Still Look Dark Over a Changing Background?

Each partly transparent pixel reveals some of whatever sits behind it. So a fade from dark blue to transparent dark blue can still look like a dark band against a pale or varying photograph, even when the interpolation is correct.

Here is compositing arithmetic for the blue rgb(30 58 138) at alpha 0.5. Over white, each channel averages with 255, giving about rgb(143 157 197). Over black, it averages with 0, giving rgb(15 29 69). Same overlay, two very different results. That is why one opaque endpoint color cannot be promised to match every underlying pixel when the background changes.

Matching the endpoint RGB channels to the starting color removes an unintended intermediate hue. It does not remove the starting color’s intended darkening. These changes address the design issue instead:

  • Move the fade earlier, so less of the image sits under high alpha.
  • Reduce the initial alpha of the starting stop.
  • Choose a lighter overlay color, especially over light photography.
  • Test the overlay on the lightest and darkest areas of the real background.

If the overlay sits behind text, remember that forced-colors modes may drop gradients entirely, which I cover in the forced-colors fallback for gradient text article. Never let a gradient be the only thing that keeps text readable.

How Do I Test a Transparent Gradient Dark Edge in CSS Step by Step?

A reproducible test changes one variable at a time. This is the order I would follow.

  1. Hold the stops and their positions fixed. Do not change the angle while testing.
  2. Place the gradient on solid white, on solid black, and on the real changing background.
  3. Change only the endpoint color or its opacity, then compare again.
  4. If darkening persists in a current browser with same-RGB endpoints, inspect the chosen color, the alpha and the stop positions before blaming interpolation.
  5. Repeat in the oldest browser versions you support. The sources do not establish an affected-version list, so only your own test answers this.

For tooling, the Gradient Generator lets you preview stop colors and positions and copy CSS. The Color Interpolation Tool compares color-space blends between chosen colors and exports CSS examples. Its documented color-space comparison is not, by itself, evidence that its preview models an alpha fade over a changing background. If either export does not express the transparent stop you need, edit the CSS so the endpoint is explicit, then retest over the target background.

Tool capabilities were checked on October 23, 2026, and the retrieved pages did not show a publication date.

When Should I Choose Each Fix, and Where Does Color Space Fit?

Pick the fix by what the diagnostic pair shows you.

  • The two diagnostic gradients differ: write the explicit same-RGB zero-alpha endpoint for browsers that need it, and keep the keyword where testing shows no difference.
  • They match, but the band is dark on pale areas: the start color is doing its job. Lighten the overlay, lower the starting alpha or move the fade earlier.
  • The band shows an odd hue: check the endpoint RGB values, since a different channel set at zero alpha can tint a fade in a non-premultiplied path.
  • Alpha is 1 at both stops and the middle looks gray or muddy: this is a color-space question, not an alpha one.

That last case is about the route the blend takes, not transparency. The Gradient Generator page notes that browsers interpolate HEX colors in gamma-encoded sRGB by default, which can make blends between saturated colors look gray in the middle. For hue routes, see my guide to shorter hue versus longer hue, and for tints and hover states built in a perceptual space, the guide to CSS color-mix in OKLCH. Keep the two ideas apart: alpha interpolation decides how opacity and color combine, while the color space decides how the color channels travel.

Frequently asked questions

Is the transparent keyword always wrong in a gradient?

No. In a browser that follows premultiplied-alpha interpolation, it should fade the same way as a zero-alpha version of your start color. The explicit endpoint is a precaution for older browsers, and only testing in your supported versions confirms whether you need it.

Does a same-RGB endpoint fix an intentionally dark overlay?

No. It avoids an unintended intermediate hue, but your starting color still darkens whatever sits behind it. To lighten the effect, change the overlay color, lower its starting alpha or begin the fade earlier.

Is alpha interpolation the same as choosing an interpolation color space?

No. Alpha interpolation covers how opacity and color combine between stops. The color space, such as sRGB, OKLab or OKLCH, covers how the color channels move. A muddy blend between two opaque colors is a color-space question.

Which browsers show the dark edge?

The cited sources say older browsers may behave differently with the transparent keyword, but they do not list affected versions. Test the exact browsers you support and record the result next to your gradient code.

Why does my fade look fine on white but dark on a photograph?

A partly transparent pixel shows some of the backdrop. Over white, a half-opaque dark blue averages toward light values. Over a darker area, it averages toward dark values, so the same overlay reads differently across the image.

Can one opaque end color match a varying background?

Not reliably. An opaque endpoint is a single color, while the image behind the gradient changes from pixel to pixel. If you need the fade to disappear into a changing backdrop, keep the end transparent and test the result on the real image.

Does the Color Interpolation Tool preview an alpha fade over a background?

Its documented purpose is comparing color-space blends between chosen colors and exporting CSS examples. That does not show it models transparency over a changing background, so edit any export to include the transparent stop and retest it in context.

Next steps

A transparent gradient dark edge CSS issue is either an unintended blend or a dark stop doing exactly what you asked. Run the paired diagnostic, test on white, black and the real background, then change only the endpoint color or opacity. If the same-RGB endpoint matches the keyword, adjust the design: lighter overlay color, lower alpha or an earlier fade. If they differ, write the endpoint explicitly and test it in each supported browser.

Related tools & resources on 66Colorful:

Sources and further reading