Also available in: Español · Português · Français · العربية
Line Height Calculator
Work out the CSS line-height each font size really gets after inheritance, with the sizes where your lines start overlapping marked.
What is line-height in CSS?
Line-height is the distance between the baselines of consecutive lines of text. In CSS you can write it four ways — a plain number like 1.5, a percentage like 150%, a length like 24px, or a font-relative unit like 1.5em — and on the element where you declare it, all four can produce exactly the same result. On a 16px root every one of those gives 24px.
They stop being the same the moment anything inherits them, and the difference is not a browser quirk. It is written into the specification: CSS 2.2 defines the computed value of line-height as the specified value when it is a number, and as the absolute value when it is a length or a percentage. So a number inherits as a number and each descendant multiplies it by its own font size, while everything else inherits as one fixed length that never changes again.
This line height calculator makes that concrete. Give it your root size, the declaration you actually wrote, and the font sizes on your page, and it shows what each of those sizes ends up with — alongside what the unitless equivalent would have given.
How to use it
- Enter your root font size and the line-height you wrote. The value and its unit are separate controls, so you can hold the value still and change only the unit. That is the fastest way to see the whole point of the page.
- List the font sizes that appear on your page. Headings, captions, anything that is not at the root size. The defaults are a standard type scale, so you can leave them alone to see the shape of the problem.
- Read the ratio column, then switch the unit to no unit. Any row marked as touching has a line box no taller than its own text. Switching to a plain number recalculates every row against its own size, and the marks disappear.
Why 150% and 1.5 are not the same thing
Take the page defaults: a 16px root with line-height: 150%, and a type scale running 16, 20, 25, 31, 39, 49 and 61 pixels. The percentage resolves once, against the root, to 24px. Every one of those seven sizes then inherits 24px — not 150% of itself, 24 pixels flat.
At 16px that is a ratio of 1.5, which is what you asked for. At 25px it is 0.96, and a ratio below 1 means the line box is shorter than the text inside it, so consecutive lines physically overlap. By 61px the ratio is 0.39: the heading still gets 24 pixels of line box for text that is 61 pixels tall. Five of the seven sizes end up at or below 1.0, and six of the seven fall below the 1.5 that WCAG success criterion 1.4.12 asks of paragraph text.
Write 1.5 with no unit instead and nothing else changes: 16px gets 24px, 25px gets 37.5px, 61px gets 91.5px. Every row is 1.5. Nothing overlaps, because each element does its own multiplication.
There is an exact point where the trouble starts, and it needs no measuring. The inherited ratio is the computed length divided by the element's own size, so it passes through 1 precisely when the font size equals the computed line-height and nowhere else. Whatever your percentage resolves to in pixels is the font size at which your lines begin to collide.
The reason this survives code review is that the two declarations are genuinely indistinguishable where you wrote them. Swept across every descendant size from 8px to 96px, 1.5 and 150% agree at exactly one size — the root — and disagree at all 176 others. The body text looks right, so the declaration looks right.
Honest limitations
The em unit is a length, so it behaves exactly like a percentage here, and rem is a length too. They differ only in what they resolve against: em and percentage both use the font size of the element that declares them, while rem always uses the root. If you declare on the root — which is where these usually go — all three collapse to the same number, which is precisely why the distinction is so easy to miss.
This tool models inheritance, not rendering. A browser's actual line box also depends on the font's own ascent, descent and line-gap metrics, so two typefaces at the same size and line-height will not produce identical spacing. The ratios here are the ones CSS computes; the ink is a separate question that depends on the font file.
The 1.5 figure comes from WCAG 2.1 success criterion 1.4.12, which asks that users be able to set line height to at least 1.5 times the font size in blocks of text. It is about paragraphs, not headings, so a large heading below 1.5 is not automatically a failure — which is why the tool counts those rows separately from the ones where lines actually touch.
Finally, a ratio above 1 is not automatically comfortable. 1.05 clears the overlap test and still reads badly. The collision mark is a floor, not a recommendation.
Why is it free?
It is arithmetic, and it runs in your browser. There is no server doing the work, so there is nothing to bill for and no account to create.
Nothing is uploaded and nothing is stored. Reload the page and it has forgotten your settings.