CSS Gradient Generator

How to use this gradient generator

1. Choose a type — Linear fades in a straight line; Radial radiates from a centre point; Conic sweeps around an angle like a pie chart.
2. Set the angle or position — For linear gradients, drag the angle slider. For radial and conic, pick the origin position from the dropdown.
3. Edit colour stops — Click the colour swatch to open your browser's colour picker, then drag the position slider to place the stop anywhere from 0% to 100%. Click + Add Stop to add more (up to 6), or click × to remove one.
4. Use a preset — Click any named preset to instantly load a curated gradient. You can then adjust it further.
5. Copy the CSS — Click Copy next to the output box, then paste it into your stylesheet.

CSS gradient syntax reference

Common uses for CSS gradients

• Hero backgrounds — A linear or radial gradient replaces a heavy image file and loads instantly.
• Button hover states — Animate a gradient overlay on hover for a polished feel (use opacity transition on a ::before pseudo-element).
• Text effects — Apply a gradient to text with background-clip: text and color: transparent.
• Overlay on images — Stack a semi-transparent linear gradient over an image to improve text legibility.
• Progress bars and pie charts — Conic gradients are perfect for showing completion percentages.
• Decorative dividers — A thin element with a gradient that fades to transparent on both ends makes an elegant section separator.

A brief history of CSS gradients

Gradients feel native to CSS now, but for years the only way to get one was a background image — a PNG or JPEG painstakingly exported from Photoshop, which added an HTTP request, blurred on high-resolution screens, and couldn't be resized without re-exporting. WebKit broke that in 2008 with a proprietary -webkit-gradient() function (shipping in Safari 4), and Firefox soon followed with its own -moz-linear-gradient(). For a while every gradient had to be written three or four times — once per engine — which is the origin of the "prefix soup" older tutorials are full of.

The W3C standardised the modern syntax in the CSS Images Module Level 3, and by around 2012–2013 linear-gradient() and radial-gradient() worked unprefixed in every major browser. The standard even changed the meaning of the angle along the way: in today's syntax 0deg points to the top and 90deg to the right, whereas the early prefixed versions used a different convention — which is why copy-pasted legacy gradients sometimes point the "wrong" way. CSS Images Module Level 4 later added conic-gradient() (the sweep-around-a-point type, shipped in Chrome 69 in 2018) and the colour-interpolation controls described below. The upshot: the -webkit- prefix this generator still emits is now belt-and-braces insurance for very old browsers, not a requirement.

How gradient colour interpolation works (and the OKLCH upgrade)

A gradient is the browser computing all the in-between colours from your stops, and how it computes them turns out to matter a great deal. By default, CSS blends in the sRGB colour space — a straight numerical mix of the red, green and blue channels. That sounds reasonable but produces a notorious problem: a gradient between two vivid complementary colours (say blue to yellow) passes through a muddy, desaturated grey in the middle, because the midpoint of two opposite RGB values lands near grey. Designers call it the "grey dead zone," and it is the reason hand-picked gradients often need an extra middle stop to look good.

CSS Color 4 and Images Level 4 fix this at the source by letting you choose the interpolation space, e.g. linear-gradient(in oklch, blue, yellow). Blending in a perceptually uniform space like OKLCH or OKLab keeps the transition bright and even — the colours travel around the colour wheel instead of straight through grey. For polar spaces you can even pick the path with a hue-interpolation keyword (shorter hue, longer hue), choosing the short or long way around the wheel. This interpolation syntax shipped in Chrome 111, Firefox 113 and Safari 16.2 (all 2023), so it is increasingly safe to use. Pick a space in the Colour interpolation control above and this generator writes it straight into the copied CSS — leave it on sRGB (default) for the classic, maximally-compatible form. The -webkit- box deliberately keeps the interpolation method off its first line: any engine old enough to need that prefix predates the in <space> syntax and would simply fail to parse it, so that line stays as the plain-sRGB fallback and the modern declaration follows it.

The gradient line, the box, and "magic corners"

Understanding the geometry makes gradients predictable rather than trial-and-error. Every linear gradient has a gradient line — an axis running across the element at the angle you set — and your colour stops are positions along that line, projected perpendicular to it. A stop at 50% sits halfway along the line; everything on a line perpendicular to the gradient line gets the same colour.

• Angles vs keywords. 0deg is "to top," 90deg is "to right," and so on clockwise; the keyword forms (to right, to bottom left) are just friendlier names for the common cases.
• The "magic corner." When you aim a gradient at a corner of a non-square box (e.g. to bottom right), CSS does something clever: the corner you point at and the opposite corner each sit on a line perpendicular to the gradient line, so the gradient always finishes exactly in the corners regardless of the box's shape. This is why a corner gradient looks "right" whether the element is a tall sidebar or a wide banner.
• Radial size keywords. A radial gradient's reach is controlled by keywords like closest-side and farthest-corner (the default), which decide where the final colour stop lands relative to the element's edges and corners.
• Hard stops and repeats. Placing two stops at the same position creates a crisp edge with no blend, and repeating-linear-gradient() tiles the stop pattern to make stripes — both are pure-CSS patterns that need no image.

Banding, and how to keep gradients smooth

On large, subtle gradients — a near-black hero that fades to slightly-less-black — you may notice faint bands instead of a seamless blend. This is not a CSS bug; it is the limit of 8-bits-per-channel colour. Across a wide area there simply aren't enough distinct values between the two endpoints, so the display steps between them in visible increments, especially in dark tones where the eye is most sensitive to small changes. Three practical remedies help: spread the same colours over a shorter distance (smaller elements band less); add intermediate stops so each segment covers a narrower range; or overlay a very subtle transparent noise texture, which dithers the band edges so the eye blends them — a trick used on many polished hero sections. Interpolating in OKLab can also reduce banding because the steps are spaced perceptually rather than numerically.

Putting text over a gradient: an accessibility note

A gradient background is a contrast minefield, because the background colour changes across the element while the text colour stays constant. A heading might have plenty of contrast where the gradient is dark and far too little where it lightens — and accessibility is judged by the worst point, not the average. Before shipping text on a gradient, check the text colour against the lightest background colour the text sits over and aim for at least the WCAG 4.5:1 ratio for body text (3:1 for large text). When a gradient spans too wide a lightness range to keep text legible throughout, the usual fix is a semi-transparent solid overlay between the gradient and the text, or a subtle text shadow, to flatten the worst case. Our WCAG contrast checker is the companion tool for verifying the result.

Frequently asked questions