4 min read

Why line-height is harder on the web than it looks

Line-height looks simple in design tools, but web rendering, wrapping, unit choices, and font metrics make it one of the most common typography handoff problems.

Design tools hide font metrics

In a design file, line-height often feels like a visible box around text. In the browser, the result depends on font metrics, rendering engines, fallback fonts, and how text wraps. Two fonts with the same font-size and line-height can occupy space very differently.

That is why exact pixel values from a design tool do not always feel exact in the browser. The value may be right, while the rendered rhythm still needs adjustment.

Unitless values are usually safer

For body text and reusable components, unitless line-height is often more resilient because it scales with font-size. A line-height of 1.45 keeps a useful relationship when text size changes, while a fixed pixel value can become too tight or too loose.

Pixel line-height can still be useful for carefully controlled display styles, especially when the design needs a precise editorial look.

Responsive headings need separate attention

Large headings often need tighter line-height on desktop and more breathing room once they wrap on mobile. A single value can fail when a two-word headline becomes four lines.

The practical fix is to preview headings at multiple widths, not just to copy a Figma number. Typography is spatial, and wrapping changes the space.