Fluid Line Height and Measure: Keeping Text Readable as It Scales
Fluid typography usually means one thing: font sizes that grow with the viewport or container via clamp(). But readable text depends on three values working together — size, line height and line length — and scaling only the first one breaks the other two. Large headings inherit body leading and look gappy; body text on a wide screen stretches to 120 characters per line and becomes tiring to read; a zoomed reader finds lines rewrapping unpredictably. This page treats line height and measure as fluid values too: how each should respond as size changes, how to express that in CSS, and how to keep everything accessible under zoom. It belongs to Fluid Typography With clamp() in the Mastering Container Queries & Responsive Layouts guide.
Why size, leading and measure must move together
Line height exists to help the eye travel from the end of one line to the start of the next. The longer the line, the harder that return sweep, and the more vertical separation helps. The larger the type, the more space its own ascenders and descenders already create, and the less extra leading it needs. Those two rules pull in opposite directions depending on context:
- Headings are large and short. They need tight leading, around 1.1 to 1.25, or multi-line headings fall apart into separate lines.
- Body text is small and long. It needs generous leading, around 1.5 to 1.7, and a capped line length.
- As body text grows with the viewport, lines get longer unless the measure is capped, and leading should increase slightly to compensate; if the measure is capped, leading can stay steady or even tighten a touch as size grows.
The practical conclusion is that line height should be a function of font size, just as font size is a function of available space.
The complete implementation
The article below uses a fluid font size, a line height that falls as the size rises, and a measure capped in ch. Headings get their own tighter formula.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Fluid line height and measure</title>
<style>
:root {
/* Body size: 1rem at small widths, 1.25rem at large, fluid between.
The rem term keeps it responsive to user zoom (WCAG 1.4.4). */
--step-0: clamp(1rem, 0.9rem + 0.5vw, 1.25rem);
--step-3: clamp(1.75rem, 1.2rem + 2.5vw, 3rem);
}
body {
margin: 0;
padding: 1.5rem;
font-family: Georgia, serif;
font-size: var(--step-0);
line-height: 1.65; /* unitless default, inherits as a ratio */
}
.prose {
/* Measure: about 65 characters, never wider than the space available.
ch is the width of "0" in the current font, so the cap scales with
font size and zoom. */
max-width: min(65ch, 100%);
margin-inline: auto;
}
.prose h2 {
font-size: var(--step-3);
/* Display leading: tight, and a little tighter at the largest size. */
line-height: 1.15;
/* Balanced wrapping stops a single orphaned word on the last line. */
text-wrap: balance;
margin-block: 1.5em 0.5em;
}
.prose p {
margin-block: 0 1em;
/* Leading eases from 1.65 at 16px toward 1.575 at 20px.
tan(atan2(1em, 1rem)) is font size ÷ root size as a plain number. */
line-height: clamp(1.5, 1.95 - 0.3 * tan(atan2(1em, 1rem)), 1.7);
text-wrap: pretty; /* avoid very short last lines in paragraphs */
}
</style>
</head>
<body>
<article class="prose">
<h2>What the coastline remembers about the storm</h2>
<p>Line length and leading work together. As the text grows, the measure stays
near sixty-five characters and the leading eases so lines stay easy to follow.</p>
</article>
</body>
</html>
The paragraph line height is the part that needs explaining. The formula most people reach for first — something like 1.8 - 0.25 * (var(--step-0) - 1rem) / 0.25rem — is invalid: it divides a length by a length, which calc() does not allow, so the whole declaration is silently dropped. The working version above uses tan(atan2(1em, 1rem)) to obtain the size ratio as a plain number, and the next section explains that idiom alongside two simpler alternatives.
The key technique: expressing a size-dependent ratio
CSS arithmetic has type rules: lengths can be added to lengths and multiplied by numbers, but a length divided by a length is not permitted in calc(). That rules out the direct "leading as a function of font size" formula. There are three working alternatives, from simplest to most precise.
1. Let a length-based line height do the maths. line-height: calc(1em + 0.5rem) adds a fixed half-rem of leading to the font size. At 16 pixels that is 24 pixels, a ratio of 1.5; at 48 pixels it is 56, a ratio of about 1.17. The ratio falls as size grows, which is exactly the desired behaviour, with no division at all. The trade-off is that a length line height inherits as a computed length, so set it on each text element rather than on a container.
2. Assign a ratio per scale step. Type scales have a handful of steps; give each a unitless line height token. Predictable, easy to review, and it inherits correctly.
:root {
--lh-0: 1.65; /* body */
--lh-1: 1.45; /* lead paragraph */
--lh-2: 1.3; /* h3 */
--lh-3: 1.15; /* h2 */
--lh-4: 1.08; /* h1 */
}
p { font-size: var(--step-0); line-height: var(--lh-0); }
h2 { font-size: var(--step-3); line-height: var(--lh-3); }
3. Compute a ratio with tan(atan2()). atan2(a, b) accepts two lengths and returns an angle; tan() of that angle is the plain number a / b. So tan(atan2(1em, 1rem)) is the element's font size divided by the root font size, as a number usable in clamp():
p {
font-size: var(--step-0);
/* ratio = current size / 1rem, e.g. 1 at 16px, 1.25 at 20px */
--ratio: tan(atan2(1em, 1rem));
line-height: clamp(1.5, 1.95 - 0.3 * var(--ratio), 1.7);
}
At a 16-pixel font the ratio is 1 and the leading is 1.65; at 20 pixels the ratio is 1.25 and the leading is 1.575. The same idiom is used for motion in Motion That Scales With Container Size, where the ratio of container width to a reference length drives duration.
Measure: ch, min() and container widths
The measure should be capped in a font-relative unit so it scales with the text. max-width: 65ch keeps roughly 65 characters per line regardless of font size or zoom: when the user zooms to 200%, the characters double in size and so does the cap, so the number of characters per line stays constant and the line simply wraps within a narrower viewport. A px or rem cap does not track a fluid font size and drifts in characters-per-line as the size scales.
Wrap the cap in min() with 100% so it never exceeds the space available, which matters inside narrow containers and at high zoom. Where the text lives inside a component, the same logic applies to the component's width — a card's description can use max-width: min(55ch, 100%) and the card's container query can adjust type size, with the measure following automatically.
ch is not exact: it is the advance width of the "0" glyph, and average character widths vary by font. For proportional serif fonts, 65ch typically yields somewhat more than 65 average characters, so designers often choose 60 to 70 and check by eye. The accessibility dimension of zoom, including why the rem term in the font size is not optional, is covered in Fluid Type, Accessibility and Zoom.
Variation: user spacing overrides
WCAG 1.4.12 Text Spacing requires that no content is lost when users override line height to 1.5, paragraph spacing to 2 times the font size, letter spacing to 0.12em and word spacing to 0.16em — typically with a browser extension or user stylesheet. Fluid line heights must survive those overrides.
/* Avoid fixed heights on text containers: an override that increases
leading must be able to make the box taller. */
.card__excerpt {
/* Fragile: clips text when the user raises line-height. */
/* height: 4.5em; overflow: hidden; */
/* Robust: clamp by lines instead, and let the box grow. */
display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: 3;
line-clamp: 3;
overflow: hidden;
}
The rule of thumb is that anything whose height depends on text must be allowed to grow. Fixed heights in em or px on text boxes are the most common cause of text-spacing failures, and they are easy to introduce when tuning fluid leading by eye.
Browser support
clamp(), min() and max() are supported in Chrome and Edge 79+, Firefox 75+ and Safari 13.1+. The trigonometric functions used for tan(atan2()) are supported in current versions of all three engines. text-wrap: balance is supported in Chrome and Edge 114+, Firefox 121+ and Safari 17.5+; text-wrap: pretty is newer and supported in current Chromium and Safari, with other engines treating it as normal wrapping. The ch unit is universally supported.
FAQ
Should line-height get smaller as font size gets larger? Generally yes. Large display text reads better with tight leading around 1.1 to 1.2, while body text needs more, around 1.5 to 1.7. A fluid type scale should therefore let line-height decrease as size increases rather than keeping one ratio for everything.
What is a good measure for body text?
Roughly 45 to 75 characters per line, with about 65 a common target. In CSS that is max-width: 65ch on the text container, which tracks the font so the character count stays stable when the text is zoomed.
Can line-height use clamp()?
Yes. line-height accepts lengths and unitless numbers, and clamp() works with either. Unitless values are usually better because they inherit as a ratio, so nested elements with different font sizes get proportional leading.
Why does my text look too loose on wide screens? Usually because the font size grew with the viewport but line-height and measure did not adapt. Long lines with generous leading make it hard for the eye to find the start of the next line. Cap the measure and let line-height tighten slightly as lines get longer.
Related
- Fluid Typography With clamp() — the parent guide.
- Fluid Typography Without JavaScript — building the size scale these values follow.
- Text Wrap Balance and Pretty — controlling where lines break.
- Full-Bleed Sections in Constrained Layouts — the grid that holds a measured column.
Related articles
More pages in the same section.