Screen Typography: Font Size, Line Length, Line Height

Picture the help center of a booking tool, the kind that gets built in countless projects: the articles are well researched, the screenshots are up to date, the structure is thoughtful. Still, support tickets keep rising, and user interviews keep surfacing the same pattern: people skim the articles but never really read them. One look at the text explains why. It is set at 14 pixels across the full width of a large monitor, the lines sit tightly on top of each other, and justified alignment leaves gaps between the words.

None of this is a serious mistake on its own. Together, these details turn good writing into something nobody enjoys reading. The fix comes down to three values every interface has, whether anyone chose them deliberately or not: font size, line length and line height.

This article shows which values have proven themselves, where the often quoted numbers come from, and how to apply them directly in Figma and CSS. The help center serves as a running example, and a checklist for your next design review wraps things up.

Font size: 16 pixels is the floor, not the goal

The browser default as a starting point

If a website doesn’t set a font size, the browser uses its default. According to MDN, that is usually 16 pixels. The number isn’t a law of nature, but it is a solid anchor: it’s the size browsers, operating systems and many typefaces are optimized for, and the size people are used to.

For body text on screens, 16 pixels is therefore a sensible minimum, not the ideal. In his online book “Practical Typography,” Matthew Butterick recommends a range of 15 to 25 pixels for the web. The UK government’s GOV.UK Design System sets body text at 19 pixels on both large and small screens. For content that people are meant to actually read, such as articles, documentation or help pages, 17 to 20 pixels is worth considering.

The platforms point in the same direction. In its Human Interface Guidelines, Apple sets iOS body text at 17 points with 22 points of leading at the default text size. If you design apps, you naturally end up in the same range.

rem instead of px: respect people’s settings

Many people increase the default font size in their browser, perhaps because of low vision or because their monitor sits far away. That setting only takes effect if the CSS doesn’t override it. MDN puts it plainly: font sizes in px are not accessible, because in some browsers people can no longer change the size.

The solution is the rem unit. It is relative to the font size of the root element, which follows the browser setting. With default settings, 1rem equals 16 pixels; with a larger default font, it grows accordingly. In practice, that looks like this:

html { font-size: 100%; }
body { font-size: 1.125rem; } /* 18 px at default settings */

The first line matters. Setting html { font-size: 10px; } to get round numbers overrides people’s settings right at the root. The math works fine with the default too: 18 pixels is 1.125 rem, 20 pixels is 1.25 rem.

Figma has no rem. You keep working in pixels there but define text styles that map to the later rem values. If your team maintains a design system, the conversion belongs in the text style documentation so design and code speak the same language.

Mobile: keep input fields at 16 pixels or more

On smartphones there is another, very concrete reason for 16 pixels. Safari on iOS automatically zooms into an input field as soon as its text is smaller than 16 pixels. It feels jumpy, and after typing the page often stays zoomed in.

Some teams prevent this by restricting zoom in the viewport meta tag. That’s a bad idea, because it makes it harder for the very people who rely on zooming to enlarge the page. The clean fix: give input fields at least 16 pixels, meaning font-size: 1rem.

Fluid font sizes with clamp()

On a large monitor, text can be a little bigger than on a phone. Instead of juggling several breakpoints, you can scale font size fluidly with the CSS function clamp(). It takes a minimum, a preferred value and a maximum:

body { font-size: clamp(1rem, 0.9rem + 0.5vw, 1.25rem); }

This keeps text between 16 and 20 pixels and lets it grow with the window width in between. There is one trap: never use the vw unit on its own for font sizes. As web.dev points out, people can then no longer enlarge the text, because vw only follows the window width. Combining it with rem in the middle value keeps the text tied to people’s settings.

Same size, different effect

One detail that often gets lost in debates about pixel values: 16 pixels isn’t always 16 pixels. Font size describes the height of the em box, the full space a typeface occupies. How large the letters appear inside it depends mostly on the x-height, the height of lowercase letters without ascenders or descenders.

Typefaces with a large x-height look noticeably bigger at the same pixel size than those with a small x-height. When you switch typefaces, check the size again instead of carrying over the old value. The most reliable way is to set a real paragraph in both typefaces side by side and look at it on the target device, not on a zoomed-in Figma canvas.

Line length: 45 to 75 characters

Where the numbers come from

The best known rule of thumb comes from print. In “The Elements of Typographic Style,” Robert Bringhurst writes that anything from 45 to 75 characters is widely regarded as a satisfactory line length, and that the 66-character line, counting letters and spaces, is widely regarded as ideal. For multi-column layouts he suggests 40 to 50 characters as a better average.

Sources focused on screens arrive at similar values. The Baymard Institute recommends 50 to 75 characters per line for body text, with 80 characters as the upper limit. Butterick is a bit more generous at 45 to 90 characters. And the WCAG, the international Web Content Accessibility Guidelines, set a maximum width of 80 characters in success criterion 1.4.8 at the highest level, AAA.

Why does this matter? With very long lines, the eye has to travel a long way back at the end of each line and has a harder time finding the start of the next one. The WCAG justify their limit with exactly this: some people with reading or vision disabilities lose their place more easily in long lines. In Baymard’s testing, people tired faster with lines of 100 characters or more and were more likely to skip the text entirely. Lines that are too short are tiring as well, because the eye has to jump constantly and the reading rhythm falls apart.

In CSS: limit the width in ch

CSS has no property for line length. Instead, you limit the width of the text container. The right unit for that is ch, the width of the digit zero in the current font:

.article-text { max-width: 66ch; }

Because ch is tied to font size, the column grows when someone enlarges the text, and the line length measured in characters stays roughly stable. A fixed pixel width can’t do that, as web.dev also notes.

A note on precision: the zero is usually wider than an average letter, so 66ch produces slightly more than 66 characters per line in many typefaces. Baymard suggests 70ch or 34em as a starting point and recommends adjusting it to your typeface. When in doubt, just count: select a typical line and see how many characters it holds.

In Figma: the text box is the column

In Figma, the container is the width of the text box. A pragmatic approach: paste a real paragraph into the box, not lorem ipsum, and drag it until a typical line holds about 60 to 75 characters. Record the resulting width in the text style or as a variable so it doesn’t get lost in the handoff.

The key is to separate layout from text. An article page can easily be 1,200 pixels wide on a large monitor. The body text inside it doesn’t need the full width, though. Sidebars, a table of contents or simply white space can fill the rest.

On narrow screens

On smartphones, the problem is usually the opposite. At 16 to 18 pixels with typical page margins, often only 35 to 45 characters fit on a line. That’s fine and hard to avoid. It does mean you shouldn’t be too generous with side margins, because every bit of text width counts here.

Especially in languages with long compound words, such as German, automatic hyphenation with hyphens: auto helps in narrow columns. It only works if the language is declared correctly in the HTML, for example <html lang="en">. According to MDN, browsers only hyphenate when this attribute is present and a matching hyphenation dictionary is available.

No justified text

Justified text, aligned flush to both the left and right edges, looks tidy in layouts. On screens, however, it usually lacks the fine-grained hyphenation and word spacing control that keeps print looking even. The result is irregular gaps between words, which in narrow columns can line up into visible rivers running through the paragraph. WCAG criterion 1.4.8 also lists text that isn’t justified as a goal. For body text in interfaces, left-aligned, ragged-right text is the safe choice.

Line height: 1.5 as a starting point

Why text needs room to breathe

Line height, line-height in CSS, determines how much vertical space a line takes up. If it’s too tight, the eye easily slips into the wrong line when moving to the next one. If it’s too loose, the paragraph breaks apart into separate strips and no longer reads as one block of text.

For body text, 1.5, or one and a half times the font size, is a good starting point. MDN recommends it as a minimum for paragraphs because it helps people with low vision and with reading difficulties such as dyslexia. The WCAG name the same value in criterion 1.4.8. Butterick sets the range a little lower, at 120 to 145 percent of the font size. The two recommendations contradict each other less than it seems: how much space you need depends on typeface, size and line length.

As a rule of thumb, the longer the line, the more line height it needs so the eye can find its way back. web.dev describes exactly this relationship. A paragraph with 70 characters per line can take 1.6, while a narrow column on a phone often works well with 1.4 to 1.5.

In CSS: unitless

For line-height, both MDN and web.dev recommend unitless values:

body { line-height: 1.5; }

The reason is inheritance. A value like 1.5em or 150% is calculated once and passed down to all child elements as a fixed pixel value. A 40-pixel heading might then inherit a line height of 24 pixels, and its lines overlap. A unitless value, on the other hand, is multiplied by each element’s own font size.

In Figma: percent instead of Auto

Figma offers three options for line height: a fixed pixel value, a percentage and “Auto.” Auto uses the default built into the font file, which varies from typeface to typeface. For text styles that will end up in CSS, a percentage is the best choice: 150% in Figma equals line-height: 1.5 in code. Pixel values make sense when your team deliberately works with a baseline grid, for example in steps of 4 or 8 pixels.

Headings need less

What works for body text feels too airy for large headings. A two-line heading at 40 pixels with a line height of 1.5 visually falls apart. For headings, values between roughly 1.1 and 1.3 work well, tighter as the text gets bigger. Always check this on a heading that actually wraps, because any line height looks fine on a single line.

Don’t forget paragraph spacing

There should be more space between two paragraphs than between two lines, otherwise paragraphs blur into one block. WCAG criterion 1.4.8 calls for paragraph spacing of at least 1.5 times the line spacing. In CSS, a gap of about one line height after each paragraph is often enough, for example p + p { margin-top: 1.5em; } with a line height of 1.5.

Accessibility: the values have to be adjustable

Good defaults are only half the job. The other half is making sure people can adapt them to their needs. For accessibility, two level AA criteria are crucial here, and they are often overlooked in practice.

Resize text (criterion 1.4.4): Text must be resizable up to 200 percent without assistive technology and without loss of content or functionality. With rem values and containers without fixed heights, this usually comes for free. Trouble starts with fixed-height text boxes, clipped buttons and navigation that overflows at larger sizes.

Text spacing (criterion 1.4.12): If someone uses a browser extension or their own stylesheet to set line height to 1.5 times, paragraph spacing to 2 times, letter spacing to 0.12 times and word spacing to 0.16 times the font size, nothing may get cut off or overlap. This mostly affects components with fixed dimensions, such as cards, tabs or badges.

A quick test: zoom the page to 200 percent in your browser, set the default font size in the browser settings to “very large,” and click through the most important pages. Whatever breaks is a candidate for your next ticket. Sufficient contrast between text and background is part of this too. The glossary explains what the contrast ratio measures and which values apply.

Before and after: the help center

Back to the help center from the beginning. Here are the text settings before the redesign:

Font size: 14 px, fixed in pixels, including search and input fields
Line length: full container width of 1,100 px, roughly an estimated 150 characters per line on large monitors
Line height: “Auto” in Figma, about 1.2 in code
Alignment: justified
Paragraphs: 8 px spacing

After the redesign:

Font size: clamp(1rem, 0.9rem + 0.5vw, 1.125rem), so 16 to 18 px depending on window width, with input fields at 1rem throughout
Line length: max-width: 68ch for the article text, with a table of contents in the freed-up space
Line height: 1.6 for body text, 1.2 for headings, stored as percentages in the Figma text styles
Alignment: left-aligned, with hyphens: auto for narrow screens
Paragraphs: 1.5em spacing

Nothing about the content or structure changed. Yet the text is a different one, because people can now read it instead of just skimming it. Whether that also reduces support tickets will only show once it’s live. A quick test with five people who each have to answer a specific question using the article will give you a good sense of it beforehand, though.

One often underestimated side effect: readable typography reduces cognitive load. When people don’t have to fight the form of a text, they have more attention left for what it says.

Conclusion

Good screen typography doesn’t need a special typeface or an elaborate layout. It needs three deliberately chosen values: a font size of at least 16 pixels in rem, a line length of roughly 45 to 75 characters limited with ch, and a unitless line height around 1.5. Add left-aligned text, enough space between paragraphs, and values that people can adapt to their needs.

None of these numbers is a law. They are well-founded starting points that you adjust to your typeface, your content and your target devices. In the end, what counts isn’t the value in the inspector but whether a real paragraph is comfortable to read on a real device.

Checklist

Body text is at least 16 px, ideally 17 to 20 px for longer reads.
Font sizes in CSS use rem, and the root element doesn’t override the browser setting.
Input fields are at least 16 px, and zoom isn’t disabled via the viewport meta tag.
Fluid font sizes always combine vw with rem, for example in clamp().
Text containers are limited to about 60 to 75 characters, for example with max-width in ch.
Body text is left-aligned, not justified, with hyphenation and a correct lang attribute.
Line height is around 1.5 for body text and roughly 1.1 to 1.3 for headings, unitless in CSS.
Figma text styles use percentages instead of “Auto.”
Paragraphs have visibly more spacing than lines.
The page works at 200 percent zoom and with increased text spacing.

Screen Typography: Font Size, Line Length and Line Height