20 Tailwind CSS Text Gradient

Gradient text uses three utilities working together. Apply a gradient background to the text element — in Tailwind v4 that's a direction utility like bg-linear-13 or bg-linear-120 plus colour stops such as from-indigo-500 via-fuchsia-500 to-rose-500. Then clip that background to the glyph shapes with bg-clip-text, and finally make the actual letters see-through with text-transparent so the clipped gradient shows through. Skip either of the last two and you get a solid-colour block or plain text. The hero heading (demo 01) applies all three to one line of an <h1>, which keeps the heading a real, selectable, indexable <h1> rather than an image. Because everything is a utility on the element itself, there is no wrapper markup and no custom CSS — the gradient paints only the text it is clipped to.

The usual culprit is a missing or out-of-order utility. bg-clip-text with no text-transparent leaves the solid text colour painted on top of the clipped gradient, so you see the colour, not the gradient; text-transparent with no bg-clip-text clips nothing, so the text vanishes into the element background. You need both. A second cause is the gradient itself being empty: a direction utility like bg-linear-120 with no from-*/to-* stops produces a transparent background, which clips to transparent text — invisible. The third is browser support: if background-clip: text is unsupported the letters fall back to transparent and disappear. Demo 17 guards against exactly this with an @supports layer that keeps a solid colour until clip-text is known to work.

Animating the hue flow means moving the gradient, not the text. Demo 08 makes the background a repeating tile roughly twice the text width — a bg-[length:...] sizing paired with repeating stops — then animates background-position from one tile edge to the next in a keyframe loop. Because the tile repeats seamlessly, the position can reset with no visible jump, giving a continuous flow through the word. The letters stay text-transparent and bg-clip-text throughout; only the background slides. Keep the loop on background-position rather than animating the colour stops, which cannot be interpolated. Add a motion-reduce:animate-none variant so the animation stops for users who ask for reduced motion — a looping colour shift is exactly the kind of continuous movement that variant exists to silence.

The text stays fully accessible to screen readers because it is still real text in the DOM — text-transparent only affects the visual fill, not the accessibility tree, so the word is announced and selected normally. The real risk is visual contrast for sighted users with low vision: a gradient means the contrast ratio changes letter to letter, and the lightest stop may fail against the background even if the darkest passes. Check the weakest stop, not the average. Demos 11 and 12 are built around this — gradient text on frosted glass and pale pastels on white are both contrast traps, so they keep stops dark enough to stay legible. For the decorative glow in demo 02, the blurred duplicate heading behind the real one is marked aria-hidden so it is not announced twice.

Demo 17 is a three-layer progressive-enhancement reference built entirely from utilities. Layer one is a plain text-* colour every browser renders — the guaranteed-readable baseline. Layer two adds the gradient plus bg-clip-text and text-transparent inside an @supports (background-clip: text) query (and the -webkit- prefixed form), so the see-through letters only activate where the clip is actually supported. If support is missing, the element never becomes transparent and the solid colour from layer one stays visible instead of vanishing. This ordering matters: declaring text-transparent unconditionally is what causes the invisible-text bug on unsupporting engines. Wrapping the transparency behind the feature query is the safe pattern for any gradient text you ship to a broad audience.

When gradient text wraps, the gradient is clipped to the element's full box, not to each line — so across a multi-line <p> the colours run continuously top-to-bottom through the whole block, and any single line shows only the slice of the gradient that falls across it. That often reads as muddy, because no one line sees the full sweep. Demo 19 shows this directly on a wrapped editorial paragraph rather than just describing it. The fix depends on intent: use a near-vertical or multi-stop gradient so each line still gets varied colour, keep gradient text to one or two lines for headings, and leave long body copy a solid colour. A horizontal bg-linear-90 on a three-line paragraph is the worst case — each line gets almost the same narrow colour band.

Two demos cover the less obvious gradient shapes. For a full rainbow from only two stops (demo 15), use v4's interpolation modifier — bg-linear-90/longer tells the gradient to travel the longer way around the colour wheel in OKLCH space, so near-identical endpoints sweep through every hue instead of a flat band. For a glow-from-within look (demo 14), use bg-radial-[circle_at_50%_50%] so the brightest stop sits at the centre of the text and darkens outward, rather than the left-to-right flow of a linear gradient. Both still rely on the same bg-clip-text and text-transparent pair; only the gradient utility changes. The /longer modifier and bg-radial-* are v4-specific, so check the cheat sheet in demo 18 for the v3 equivalents before porting older code.

Reach for a solid colour instead of a gradient when legibility or scale is at stake. Long body paragraphs are the clearest no — the multi-line clipping problem (demo 19) muddies the sweep, and a gradient makes dense text slower to read for everyone. Small UI text like captions, labels and fine print loses the gradient to its own size and only risks contrast, so demo 07's active nav link tints a pill and keeps the gradient as an accent rather than painting tiny letters. Avoid it anywhere the lightest stop can't clear a contrast threshold against the background, which is why the glass and pastel demos (11, 12) tune their stops carefully rather than using any palette. Good fits are the opposite: large, short, high-impact type — hero headings, logos, a single emphasised word — where the letters are big enough to show the full gradient and brief enough to stay readable.