You’ve stared at a paragraph of body text on a screen, and halfway through the third line, your eye jumps — not to the next line, but to the one after it. You re-read. You lose your place again. You give up and close the tab. That’s not a content problem. That’s a line-height problem, and it’s one of the most quietly damaging mistakes in web typography.
I’m Rohan Ratnayake, and I’ve spent the last five years as a front-end typographic systems developer, which basically means I obsess over the invisible geometry that holds text together on screens. I’ve watched well-written articles bleed readers because a designer set line-height: 1 on a paragraph block and called it done. I’ve seen product teams spend three sprint cycles improving copy, then wonder why session times didn’t move — never once checking the line spacing that was cramping every paragraph into an unreadable wall.
The hard lesson I learned early on: I once shipped a documentation site for a SaaS product with line-height: 1.3 on the body copy. The font was Inter at 16px. The client came back two weeks later saying their support tickets had doubled because users “couldn’t follow the setup guides.” We A/B tested line-height at 1.6 against the original. Time-on-page for the tutorial section went from 1 minute 40 seconds to 3 minutes 10 seconds. Same words. Same font. Just more vertical breathing room. That was the moment I stopped treating line-height as a styling preference and started treating it as a reading mechanics problem.
This article gives you the actual math — the ratios, the logic behind them, and how different font families change the equation entirely.
Why Line-Height Isn’t “Set It and Forget It”
Most CSS tutorials tell you to set line-height: 1.5 and move on. That advice works okay for a system font at a medium size on a clean background. It fails the moment you switch font families, because line-height interacts directly with a font’s internal metrics — specifically its x-height and ascender/descender ratios — not just its rendered size.
Here’s what that means practically. Line-height in CSS is a unitless multiplier. When you write line-height: 1.6, you’re telling the browser: render the distance from one baseline to the next at 1.6× the font’s computed size. What that looks like depends on how much of that vertical space the font actually occupies.
A font with tall ascenders and deep descenders (like Georgia or Playfair Display) visually fills more of that space. A font with a compact x-height and shallow descenders (like Helvetica Neue or system-ui) leaves more open air in the same multiplier. Same number. Very different experience for the reader’s eye.
The Core Math: What the Ratio Is Actually Measuring
The leading you perceive is not the full line-height value. It’s the half-leading — the space split above and below each line of text. When you set line-height: 1.6 on a font with a computed size of 16px, you get 25.6px of total line height. The font itself occupies roughly 16px of that. The remaining 9.6px splits in half: 4.8px above the line and 4.8px below it.
That 9.6px of breathing room is what your eye uses to track from one line to the next without jumping.
| Line-Height Value | Total Line Height (at 16px base) | Available Leading (half above, half below) |
|---|---|---|
| 1.0 | 16px | 0px — lines touching |
| 1.2 | 19.2px | 1.6px each side |
| 1.4 | 22.4px | 3.2px each side |
| 1.5 | 24px | 4px each side |
| 1.6 | 25.6px | 4.8px each side |
| 1.8 | 28.8px | 6.4px each side |
| 2.0 | 32px | 8px each side |
The moment leading drops below about 3px per side, readers start losing their place — especially in longer paragraphs. That’s why 1.2 feels suffocating on body text even though it looks fine in a heading.
How Font Family Changes the Ideal Ratio
This is the part that trips up even experienced developers. The same line-height: 1.5 can look comfortably spaced in one font and claustrophobic in another. The reason is the font’s x-height ratio — the height of lowercase letters relative to the cap height.
Fonts with a high x-height (tall lowercase letters relative to the cap height) feel denser because the letterforms themselves occupy more of the visual line space. They need more leading to breathe. Fonts with a low x-height feel naturally airier and can tolerate tighter line-height values.
| Font Family | X-Height Ratio (approx.) | Recommended Line-Height for Body | Notes |
|---|---|---|---|
| Georgia | 0.48 | 1.5–1.6 | Classic serif, moderate density |
| Times New Roman | 0.45 | 1.5 | Low x-height, reads well tighter |
| Playfair Display | 0.44 | 1.5–1.55 | Decorative serif, use sparingly for body |
| Inter | 0.73 | 1.6–1.7 | Very high x-height, needs generous leading |
| Roboto | 0.69 | 1.55–1.65 | High x-height, common on Android |
| Helvetica Neue | 0.52 | 1.45–1.55 | Moderate, balanced |
| system-ui | Varies | 1.5–1.6 | Safe default; test on each OS |
| Source Serif Pro | 0.47 | 1.5–1.55 | Designed for screens, efficient |
Inter is probably the most common mistake I see. It’s everywhere right now, and it ships on most design systems at line-height: 1.5. Given its x-height sits around 0.73 — one of the highest of any popular UI font — that value consistently produces text that feels harder to scan than it should. Bumping it to 1.65 costs you nothing but fixes the tracking problem completely.
The Paragraph Width Problem (And How It Multiplies the Line-Height Effect)
Line-height doesn’t work in isolation. It interacts directly with your measure — the width of your text column. A wide column with tight line-height is a recipe for lost readers. A narrow column with generous line-height feels like a list. You’re balancing two variables at once.
The general principle: longer lines need more leading. Your eye has a longer horizontal distance to travel before snapping back to the start of the next line. If the vertical gap is small, it picks up the wrong line on the return trip.
A practical pairing guide:
| Column Width (characters per line) | Recommended Line-Height Adjustment |
|---|---|
| Under 45 characters | Drop 0.05–0.1 from your base ratio |
| 45–75 characters (ideal range) | Use your base ratio as-is |
| 75–90 characters | Add 0.05–0.1 to your base ratio |
| Over 90 characters | Add 0.1–0.15 and reconsider column width |
The W3C Web Content Accessibility Guidelines specifically recommend that users be able to set line-height to at least 1.5 times the font size without loss of content or functionality — which is a floor, not a ceiling. Building your baseline around 1.5 and adjusting upward based on font and column width is a safer approach than picking one value and assuming it works everywhere.
Headings Are a Different Conversation
What works for body text actively breaks headings. At large display sizes, generous line-height creates awkward gaps between wrapped lines. A heading that wraps onto two lines at line-height: 1.6 looks like two separate thoughts with a void between them.
The rule here flips: tighter is better for headings, down to about 1.1 or 1.15 for display-size text (anything above roughly 24px rendered). Many design systems hard-code line-height: 1 for the largest heading sizes, which can clip descenders on certain fonts — particularly italic treatments of serif faces.
A safe framework for heading line-heights:
- H1 / Display text (large):
1.1to1.2 - H2 / Section headings:
1.2to1.3 - H3 / Subheadings:
1.3to1.4 - Body text:
1.5to1.7depending on font and column width - Small print / captions:
1.4to1.5(small text paradoxically needs more, not less, leading)
Caption text at line-height: 1.2 is something I see constantly on news sites and it’s brutal — small letterforms already cramped by their size, then squeezed vertically on top of it.
A Calculation You Can Actually Use
If you want a starting number and don’t want to guess, use this:
Base Line-Height = 1.2 + (0.4 × x-height ratio)
For Inter (x-height ~0.73): 1.2 + (0.4 × 0.73) = 1.492, round to 1.5 — and then nudge upward because Inter’s density still benefits from a bit more air. Call it 1.6 in practice.
For Georgia (x-height ~0.48): 1.2 + (0.4 × 0.48) = 1.392, round to 1.4 — but given Georgia’s wider letter spacing at most sizes, 1.5 reads more comfortably.
This formula won’t replace your eyes, but it gives you a principled starting point instead of a random guess. The MDN Web Docs entry on line-height explains the CSS spec behavior around unitless values vs. length values — worth reading if you’re working with inherited line-heights in complex component trees, because the inheritance behavior is one of the more counterintuitive parts of the CSS box model.
The One CSS Mistake That Breaks All of This
Setting line-height with a unit — like line-height: 24px or line-height: 1.5em — on a parent element. When you use a unitless value like 1.6, child elements inherit the multiplier and apply it to their own font size. When you use a fixed pixel or em value, they inherit the computed number, not the ratio.
This means your headings — which are larger — might have less visual leading than your body text. It’s a silent bug that causes inconsistent rhythm across a page without any obvious CSS error to debug.
The fix is simple: always use unitless values for line-height.
FAQs
Is there a universal “safe” line-height I can set on the body element and forget about?
If you need one fallback for a system-font stack, line-height: 1.6 is the most defensible choice. It handles high x-height sans-serifs adequately and doesn’t over-space lower x-height serif fonts enough to look broken. It’s not optimal for any one font, but it fails gracefully across most of them.
Does line-height affect SEO?
Not directly. But it affects reading time, bounce rate, and content engagement — all of which are behavioral signals. Tighter-than-necessary line-height on a long article consistently produces higher bounce rates in split tests, particularly on mobile where line lengths are naturally longer relative to screen width.
Should line-height be different on mobile?
Often, yes. Mobile viewports compress column width, which should theoretically allow tighter line-height — but device pixel density means text is rendered smaller in perceived terms, and users read at arm’s length. Many well-built design systems use line-height: 1.5 on desktop and 1.6 on mobile, targeting the narrower viewport and lower pixel density of older devices.
Before You Close This Tab
The core tension here is that line-height looks like a simple number but it’s actually a ratio in conversation with your font’s internal geometry. Setting it once and forgetting it means every font family change, every column width adjustment, every heading level is working against a number that was tuned for something else.
Pick the font family first. Check its x-height ratio. Run the formula. Test it against your actual column width. Adjust headings downward, body text upward. And use unitless values — always. That’s the whole system. Do that before your next launch and you’ll stop losing readers to a problem they can’t name but absolutely feel.
