Type something to search...
What Is the Ideal Line Length for Readable Web Content?

What Is the Ideal Line Length for Readable Web Content?

You open a blog post on a 27-inch monitor and the paragraphs stretch edge to edge, 180 characters per line. By the end of each line, your eyes have to sweep all the way back to the left margin and hunt for the start of the next one. You lose your place twice in the first paragraph and give up. The same article on a phone is fine. Nothing about the font, size, or color changed. The only problem was the length of the line.

This article explains what the ideal line length for web content is, why it matters, how to measure it, and how to enforce it in CSS with ch units, max-width, and modern layout techniques. It also covers how line length interacts with font size and line height, and how to handle mobile screens, wide layouts, and different languages.

What Is Line Length?

Line length, also called measure, is the width of a block of text, usually expressed as the number of characters (including spaces) per line. Typographers measure in characters rather than pixels or inches because what matters to reading is how many words the eye takes in before it has to jump back.

The widely accepted guidance:

ContextCharacters per lineNotes
Ideal for body text60–70Comfortable for most readers and typefaces
Acceptable range45–75The classic Bringhurst range
Mobile body text35–50Constrained by screen width; still readable
Wide multi-column layouts40–50 per columnNarrower columns for magazine-style layouts
Captions, sidebars30–50Short blocks tolerate shorter measures
Accessibility upper bound80WCAG 1.4.8 (AAA) recommends no more than 80

Robert Bringhurst's The Elements of Typographic Style gives 45–75 characters as satisfactory for single-column text, with 66 often described as ideal. Those numbers come from print, but research and practice on screens have landed in roughly the same place.

Why Line Length Affects Readability

Reading isn't a smooth glide. Your eyes move in short jumps called saccades and briefly stop on words (fixations). At the end of each line, they make a long return sweep back to the left. Line length affects both halves of this process.

Lines That Are Too Long

  • The return sweep is long, so readers more often land on the wrong line, rereading or skipping one.
  • Readers lose their sense of progress and are more likely to skim or abandon the text.
  • Paragraphs look like dense grey slabs, which is discouraging before reading even starts.

Lines That Are Too Short

  • The eye has to jump back constantly, which breaks the rhythm.
  • Phrases get split across lines, so readers have to reassemble meaning.
  • Ragged right edges become more jagged, and hyphenation or awkward breaks become more frequent.
  • Words like "the" and "a" end up stranded at line ends.

The sweet spot balances these: long enough to carry a phrase or two, short enough that the return sweep is easy and accurate.

The WCAG Angle

Line length appears in WCAG as Success Criterion 1.4.8 Visual Presentation, a Level AAA requirement. Among other things, it says that for blocks of text, width should be no more than 80 characters (40 for CJK scripts), and that text shouldn't be fully justified.

Level AAA isn't required for most compliance targets, but the 80-character limit is a sensible hard ceiling. People with dyslexia and some cognitive and low-vision conditions find long lines particularly hard, so a measure in the 60s helps them most. For related accessibility settings, see how to make website typography accessible.

How to Set Line Length in CSS

Use the ch Unit

The ch unit equals the width of the "0" character in the current font. It's not an exact character count, because average letter widths vary, but it's the closest CSS gets to measuring in characters.

.prose {
  max-inline-size: 65ch;
  margin-inline: auto;
}

max-inline-size is the logical equivalent of max-width in horizontal writing modes, and adapts correctly for vertical text. Use max-width if you prefer; the effect is the same for left-to-right and right-to-left languages.

Because most lowercase letters are narrower than "0," 65ch usually holds around 70–80 actual characters of English text. If you want a true count in the mid-60s, start around 60ch and measure.

Measure Your Real Character Count

Fonts differ, so verify. In the browser console, you can count the characters on the first line of a paragraph:

function charsPerLine(el) {
  const range = document.createRange();
  const text = el.firstChild;
  const top = el.getBoundingClientRect().top;
  let count = 0;

  for (let i = 0; i < text.length; i++) {
    range.setStart(text, i);
    range.setEnd(text, i + 1);
    if (range.getBoundingClientRect().top > top + 2) break;
    count++;
  }
  return count;
}

charsPerLine(document.querySelector("article p"));

Run it on a few paragraphs and adjust your ch value until the count lands where you want it. For a quick manual check, copy a line of text into any character counter.

Constrain the Text, Not the Whole Page

A common mistake is limiting the entire layout to 700px, which leaves images, code blocks, and tables cramped. Constrain the text and let other content break out:

.article {
  display: grid;
  grid-template-columns:
    [full-start] minmax(1rem, 1fr)
    [content-start] min(65ch, 100% - 2rem)
    [content-end] minmax(1rem, 1fr)
    [full-end];
}

.article > * {
  grid-column: content;
}

.article > .full-bleed {
  grid-column: full;
}

This keeps every paragraph at a readable measure while letting hero images, wide tables, or diagrams span the full width. The min() call keeps a 1rem gutter on small screens.

Tailwind CSS v4

Tailwind ships a max-w-prose utility out of the box, set to 65ch, and the typography plugin's .prose class applies the same 65ch limit by default. When you want a different measure, use an arbitrary value:

<article class="mx-auto max-w-prose">
  ...
</article>

<article class="mx-auto max-w-[60ch] text-lg/relaxed">
  ...
</article>

The second example also sets font size and line height together with the text-lg/relaxed shorthand, which keeps measure and leading in step. For more on long-form styling with the plugin, see how to use the Tailwind Typography plugin.

How Line Length Interacts with Font Size and Line Height

Line length doesn't exist in isolation. Three settings work together:

  1. Font size sets how wide each character is.
  2. Line length sets how many characters fit.
  3. Line height sets how easy it is to find the next line.

Because ch scales with font size, increasing the font size automatically widens a 65ch container, keeping the character count constant. That's exactly what you want.

Line height should increase as line length increases. Longer lines need more vertical space between them so the eye can track back accurately:

MeasureSuggested line height
35–50 characters1.4–1.5
50–65 characters1.5–1.6
65–80 characters1.6–1.75

You can express this relationship in CSS by tying line height to container width with container queries:

.prose-wrapper {
  container-type: inline-size;
}

.prose {
  max-inline-size: 65ch;
  line-height: 1.5;
}

@container (min-width: 36rem) {
  .prose {
    line-height: 1.65;
  }
}

For more on vertical spacing, see what leading is and how to set the right line height.

Line Length on Mobile

On a phone, the screen width usually sets the line length for you. A 375px-wide viewport with 16px side padding and 17px body text gives roughly 35–45 characters per line. That's at the low end of the range but fine for reading.

Practical rules for mobile:

  • Don't shrink the font to fit more characters. Keep body text at 16px or larger and accept a shorter measure.
  • Keep side padding modest, around 16–20px. Huge margins on a small screen push the measure below 35 characters.
  • Watch for text in cards and grids. A three-column card grid that collapses to a single column is fine; one that stays two-column on a phone often drops to 20 characters per line.
  • Reduce line height slightly for short mobile lines, since the return sweep is short.

Line Length on Wide Screens

On large monitors, the problem reverses: there's too much space. Options:

  1. Center the text column with margin-inline: auto and let whitespace fill the sides.
  2. Add a sidebar for table of contents, related posts, or notes, rather than widening the text.
  3. Increase the font size slightly on very large screens with clamp(), which widens the ch-based column proportionally.
  4. Use multiple columns only for short, scannable content. Multi-column long-form text forces vertical scrolling up and down, which is worse on the web than in print.

Other Languages and Scripts

Character counts depend on the writing system:

  • German, Finnish, and Dutch have long compound words, so lines with fewer than 50 characters produce many ragged breaks. Lean toward 60–75, and consider hyphenation with CSS.
  • Chinese, Japanese, and Korean pack more information per character. WCAG recommends at most 40 characters; 30–40 is typical. The ic unit (width of the CJK water ideograph) is the CJK equivalent of ch.
  • Arabic and Hebrew follow similar ranges to Latin scripts, but use logical properties like max-inline-size so layouts mirror correctly.
:lang(ja) .prose,
:lang(zh) .prose {
  max-inline-size: 38ic;
}

Line Length FAQ

For body text, aim for about 60 to 70 characters per line, including spaces. The broader acceptable range is 45 to 75, and WCAG's enhanced visual presentation guideline recommends no more than 80 characters.

Not exactly. The ch unit is the width of the zero character, and most lowercase letters are narrower, so a 65ch container usually holds somewhat more than 65 characters of real text. Measure your font and adjust.

Use ch, or rem if you prefer. A ch-based width scales automatically when the font size changes, including when users zoom or change their default font size, so the character count stays stable.

Phone screens usually produce 35 to 50 characters per line, which is acceptable. Keep body text at 16 pixels or larger and use modest side padding rather than shrinking the font to fit more characters.

Yes. Long lines are particularly difficult for people with dyslexia and some cognitive and low-vision conditions. WCAG 1.4.8, a Level AAA criterion, limits text blocks to 80 characters, or 40 for Chinese, Japanese, and Korean.

Headings can be wider or narrower, but very long headings spanning a full page width are hard to scan. Many designers limit headings to around 20 to 30 characters and use text-wrap balance to even out line breaks.

Conclusion

The ideal line length for web content is around 60–70 characters per line, inside a broader 45–75 range, with 80 as a hard ceiling. Lines that are too long make readers lose their place on the return sweep. Lines that are too short break up phrases and create a choppy rhythm. Getting it right is one of the cheapest, most effective improvements you can make to readability.

In CSS, set max-inline-size in ch on your text containers rather than the whole page, measure the real character count in your chosen font, and pair the measure with a matching line height. Let mobile screens set shorter measures naturally, center and frame text on wide screens, and adjust for languages with long words or dense scripts.

Here are some useful references for going deeper on line length:

  1. W3C: Understanding SC 1.4.8 Visual Presentation — the AAA criterion that sets the 80-character limit.
  2. Butterick's Practical Typography: Line length — a concise, practical take on measure for screen and print.
  3. MDN Web Docs: CSS values and units — how ch, ic, rem, and other units are calculated.
  4. Tailwind CSS Docs: max-width — the built-in max-w-prose utility and container scale.
  5. Smashing Magazine: Typography articles — in-depth pieces on measure, rhythm, and responsive text.
Share :

Related Posts

Ascenders, Descenders, and Baselines: The Anatomy of a Letterform

Ascenders, Descenders, and Baselines: The Anatomy of a Letterform

You align an icon next to a button label and it looks a pixel or two too high, no matter how you adjust vertical-align. You set overflow: hidden

Continue Reading
Are Google Fonts GDPR-Compliant?

Are Google Fonts GDPR-Compliant?

In late 2022, thousands of small business owners in Germany and Austria opened letters demanding a few hundred euros in "damages" because their websi

Continue Reading
How to Audit Web Font Performance with Lighthouse?

How to Audit Web Font Performance with Lighthouse?

A client sends you a screenshot of their PageSpeed Insights report: performance score 61, LCP 3.9 seconds, and a vague list of warnings. They want to

Continue Reading