Optimal Line Length and Line Height for Body Text

Optimal Line Length and Line Height for Body Text

Body text reads best at about 45 to 80 characters per line, spaces included, with a unitless line-height of 1.5. Only two of those numbers are written into a standard: WCAG 2.2 sets 80 characters and space-and-a-half line spacing at Level AAA. In our measurements of six Google Fonts, 66 characters came to about 31em.

The common shortcut, max-width: 65ch, does not hold 65 characters. We shaped two English paragraphs in six popular Google Fonts and found that a 65ch column holds between 72 and 87 characters, depending on the font. In Roboto, Lora, Inter and Merriweather it holds more than the 80 characters WCAG allows. The cause is that the ch unit is the width of the digit zero, and in most of these fonts a zero is a good deal wider than the average character in a sentence. The em unit turned out to be the steadier ruler: the average character width varied by only 8 percent across the six fonts, while the zero varied by 24 percent.

Standard, Technique or Habit: The Rule Table

Line length and line height advice comes from very different kinds of documents, and they do not carry the same weight. A Level AA success criterion is something a conformance claim can fail on. A sufficient technique is one documented way of meeting a criterion. A style book or a literature review is advice. The table sorts the numbers you will see quoted by where they actually come from, as of November 13, 2026.

Two things stand out. First, nothing in this table requires a website's default layout to set lines at 80 characters or line height at 1.5. Level AA asks only that the page survives a reader's overrides, and Level AAA asks that a mechanism exists. Second, the numbers agree more than they disagree. Every source puts comfortable prose somewhere between the mid-40s and 80 characters, and only the style book's line spacing range (topping out at 1.45) sits below the 1.5 that WCAG and MDN use.

What SC 1.4.8 Really Requires at 80 Characters

The text of Success Criterion 1.4.8 is short: "For the visual presentation of blocks of text, a mechanism is available to achieve the following", followed by five bullets. The width bullet reads "Width is no more than 80 characters or glyphs (40 if CJK)." The first note under the criterion then says that content "is not required to use these values" and that the mechanism "can be provided by the browser or other user agent."

So a page with 100-character lines does not fail 1.4.8 by that fact alone, provided the reader has a way to get narrower lines. The Understanding document lists two sufficient techniques for the width bullet, G204 (not interfering with the user agent's reflow of text as the window is narrowed) and C20 (relative column widths). C20's own test procedure has two steps: check that columns use relative units, and "check to see that line length can be set to 80 characters or less by resizing the browser window."

The C20 example is a good illustration of how loose that is. Its first code sample is #main-content {max-width: 70em}. Using our measured average character width for Inter (0.474em), a 70em column holds about 148 characters on a wide screen. The technique still counts, because the reader can shrink the window until the column narrows below 80. A design that wants to meet the number without asking anything of the reader has to set a much smaller width, and the conversion tables below give that width for six fonts.

What the Understanding page leaves open. It gives no measurement method, and it does not say whether spaces count. It does define "on a full-screen window" as the most common desktop or laptop display with the viewport maximized, which matters for the separate 200 percent resize bullet. We count spaces, because the typographic tradition the number grew out of does (Butterick says "including spaces" explicitly), and because a line of text is spaces as much as letters: in our two sample paragraphs, spaces were 18 percent of all characters.

The CJK figure. The 40-character limit for Chinese, Japanese and Korean text rests on the Understanding page's statement that CJK characters are "approximately twice as wide" as non-CJK characters at the same readability. The page does not name the study. For CJK text, CSS has a matching unit: MDN defines ic as the advance measure of the "水" ideograph in the font used, so max-width: 40ic targets 40 full-width characters directly, without the averaging problem that ch has with Latin text.

Where 45, 66 and 70 Come From

The lower bound and the "ideal" figures have no standards body behind them.

• Butterick's Practical Typography gives the clearest public statement: aim "for an average line length" of 45 to 90 characters, "including spaces." It also offers a quick check for layouts where you cannot count: you "should be able to fit between two and three alphabets on a line."
• Nanavati and Bias (2005), a literature review in the journal Visible Language, summarizes that "research has led to recommendations that line length should not exceed about 70 characters per line," and that "both very short and very long lines slow down reading by interrupting the normal pattern of eye movements." The review also lists font, spacing and screen size among the factors that move the optimum, which is a fair warning against treating any single number as exact.
• 45 to 75, with 66 as the ideal is the range most design blogs repeat, usually with a credit to a print typography manual. We have not put a primary source for it in the Sources list, so we treat it as a convention: a sensible target, not a requirement.

The research picture is less tidy than the rules. Reading speed, comprehension and preference do not always move together, which is why the review talks about trade-offs instead of a single optimum. For a website, the practical consequence is modest: pick a target in the 60s, keep the maximum under 80 so the AAA number is met by default, and let narrow screens go below 45 rather than shrinking the type. For readers with dyslexia, shorter lines have their own evidence base, covered in our dyslexia-friendly fonts evidence review.

Six Google Fonts, Measured: Why ch Misleads for Prose

To turn a character target into CSS you need one number per font: the average width of a character in running text, as a fraction of the font size. Font files store that information exactly, so we measured it instead of guessing.

How we measured, on November 13, 2026. We downloaded the variable TTF files for Inter, Roboto, Open Sans, Lora, Merriweather and Source Serif 4 from the google/fonts repository on GitHub and pinned each to a body-text instance: weight 400, width 100 where the font has a width axis, and optical size 16 where it has one (Merriweather's optical size axis starts at 18, so it was set to 18). We then shaped two plain English paragraphs of 631 and 551 characters with HarfBuzz, with kerning and ligatures on, summed the advance widths, and divided by the number of characters. The ch width is the advance of the "0" glyph in the same instance, which is exactly what CSS uses: MDN defines ch as "the advance measure of the glyph 0 (zero, the Unicode character U+0030) in the element's font."

The average column is the mean of the two sample paragraphs; the two samples differed from each other by at most 0.007em in any font. The zero column runs from 0.519em to 0.645em, a spread of 24 percent. The average column runs from 0.447em to 0.482em, a spread of 8 percent. A ruler that changes by a quarter from font to font is a poor tool for a target that should stay put.

Why is the zero so wide? Digits in these fonts are designed to line up in tables, so they are drawn at a fixed, generous width, while running text is full of narrow letters (i, l, t, f, r), punctuation and spaces. In Inter, the lowercase alphabet alone averages 0.531em per letter, and spaces pull the sentence average down to 0.474em.

Three caveats apply to these numbers. They describe English prose in these two samples; text heavy in capitals, numerals or long words will run wider. They describe the files in the GitHub repository on the check date, which may differ in version from a file a CDN serves you. And they ignore letter-spacing, which adds to every character (that matters for the 1.4.12 overrides, worked through below).

Converting a Character Target to max-width

With an average width per character, the conversion is one multiplication:

• max-width in em = target characters × average character width (em)
• max-width in ch = target characters × average character width ÷ zero width
• max-width in rem = the em figure × (body font size ÷ root font size)

Here is the arithmetic for three targets: 45 (the convention's lower bound), 66 (a mid-range target) and 80 (the WCAG maximum).

Read down the 66-character column in em and the values sit between 29.5em and 31.8em. Read down the same column in ch and they run from 49.3ch to 59.4ch. If you want one value that works across a font swap, the em column is the one to use: max-width: 31em gives 65.4 characters in Inter, 69.3 in Roboto, 65.6 in Open Sans, 65.9 in Lora, 64.3 in Merriweather and 66.4 in Source Serif 4. That is a spread of five characters, against fifteen for a ch value.

Worked example: Inter at 18px. A blog sets paragraphs at 1.125rem (18px with the browser's default 16px root) in Inter and wants 66 characters per line.

1. Average character width: 0.474em, so 66 characters need 66 × 0.474 = 31.3em.
2. Set max-width: 31.3em on the element that has the 18px font size. That is 31.3 × 18 = 563px at default settings.
3. If the width must go on a wrapper that inherits the 16px root size, convert: 31.3 × 18 ÷ 16 = 35.2rem.
4. Do not write 65ch here: in Inter that is 86 characters, over the AAA limit.

Where the width goes. Put the max-width on the text column itself, not on a page wrapper that also holds a sidebar, and set it in em on the element whose font size it should follow. By default CSS max-width applies to the content box; if your reset sets box-sizing: border-box, the padding comes out of the same width, so add the horizontal padding to the value.

When ch is the right unit. Monospaced text is the exception. In a monospaced font every character has the same advance as the zero, so max-width: 80ch on a code block holds exactly 80 characters. Number-heavy tables are close too, because their characters are mostly digits. For prose, measure an average or use em.

Fallback fonts move ch more than em. The ch unit comes from whichever font is rendering, so while a web font is still loading, a column set in ch takes the fallback font's zero width and then changes when the web font arrives. An em width does not depend on any glyph and stays the same size through the swap, although the number of characters per line still changes with the font. If layout shift from font loading is a concern on your pages, our CLS worked examples show how to estimate its score.

px Widths Under Larger Text Settings

A fixed pixel column counts characters correctly only at one text size. Take max-width: 680px with Inter body text at 16px: 680 ÷ (16 × 0.474) = 89.6 characters, already over 80. Now suppose a reader sets their browser's default text size to 32px and your text is in rem. The text doubles, the column does not, and the line drops to 44.8 characters. Full-page zoom scales the pixel column along with the text, so the problem shows up with text size settings, not with page zoom.

An em or rem column scales with the text in both cases, so the character count stays where you set it. That is the same argument our px, rem and em units guide makes for font sizes, applied to widths.

The 200 percent bullet of 1.4.8 and the reflow behaviour that G204 describes are about horizontal scrolling, and a max-width never causes that: on a narrow window the column simply fills the space available. What causes horizontal scrolling is a fixed width or a min-width, so avoid width: 680px on text containers even when max-width would do.

Phones are below 45, and that is fine. On a 360px wide screen with 16px side padding, the column is 328px. In Inter at 16px that holds 328 ÷ 7.59 = 43 characters. Shrinking the type to reach 45 would trade a convention for legibility. Keep the text size and accept the shorter lines.

Line Height: What "Space-and-a-Half" Means

For line spacing the documents line up in a short chain:

1. SC 1.4.8 (AAA) asks that a mechanism can get line spacing to "at least space-and-a-half within paragraphs."
2. SC 1.4.12 (AA) asks that nothing is lost when a user sets line height to "at least 1.5 times the font size."
3. Technique C21 shows body { line-height: 1.5; } and tests that spacing in blocks of text "is between 1.5 and 2."
4. MDN's line-height reference says to "use a minimum value of 1.5 for line-height for main paragraph content."

There is one wrinkle. The 1.4.8 Understanding page defines space-and-a-half as the top of one line being "150% further from the top of the line below it than would be true when the text is 'single spaced'." If "single spaced" meant the browser's normal line-height of roughly 1.2, then 150 percent of it would be 1.8. The techniques settle it the other way: C21 uses line-height: 1.5, and 1.4.12 states its value as 1.5 times the font size. The working reading, and the one we use here, is 1.5 times the font size.

Butterick's range, "between 120% and 145% of the point size," tops out just below that. If you follow the style book you end up slightly under the number WCAG and MDN use. For web body text, start at 1.5.

What normal resolves to in six fonts

If you set no line-height at all, you get normal. CSS 2 describes it as a "reasonable" value "based on the font of the element" and recommends "a used value for 'normal' between 1.0 to 1.2." MDN says desktop browsers use "roughly 1.2, depending on the element's font-family." The font files show how wide "depending" can be. Each font declares an ascender, a descender and a line gap; their sum, divided by the units per em, is the line height the font's designers built in.

These are the values in the files' metric tables. Which table a given browser and operating system reads can differ (Roboto, for example, declares 1.172 in one table and 1.050 in another and does not set the flag that tells software to prefer the second), so treat the column as an approximation of normal, not a promise. The useful conclusion is that normal varies by about 0.2em between fonts, roughly 3px at 16px, and in five of the six fonts the declared value is above the 1.2 ceiling that CSS 2 recommends. Set an explicit value and the difference disappears.

Unitless Values and the Inheritance Trap

A unitless line-height is a multiplier. CSS 2 defines it as "this number multiplied by the element's font size," and MDN calls it "the preferred way to set line-height and avoid unexpected results due to inheritance." Children inherit the number, not a computed length, so each element multiplies by its own size.

Now the trap. Suppose an article wrapper sets font-size: 16px; line-height: 1.5em. The em is resolved on the wrapper, so the computed value is 24px, and every descendant inherits 24px. A 32px h2 inside it gets 24px lines, less than its own font size, and a two-line heading overlaps itself. With line-height: 1.5 the h2 computes 32 × 1.5 = 48px instead. MDN's own example shows the same effect at smaller sizes: an h1 at 30px with line-height 1.1 gets 33px, but if it inherits a computed value from a 15px parent it gets 16.5px. Percentages behave like em here, which is why both are worth avoiding on containers.

Headings do want less leading than body text, because the gap between lines grows with the font size. Give them their own unitless values. The typography scale system guide sets out a full set of ranges by text role, and the arithmetic in the table above applies to whatever values you pick.

Why the same 1.5 can look tight or loose

Line height is measured from the font size, but the eye reads the gap between lines of lowercase letters, which depends on the x-height. Dividing the line pitch by each font's x-height gives a rough sense of how airy 1.5 will look. At line-height 1.5, the line pitch is 2.70 x-heights in Merriweather (x-height 0.555em), 2.77 in Inter (0.542em), 2.80 in Open Sans, 2.84 in Roboto, 3.00 in Lora (0.500em) and 3.16 in Source Serif 4 (0.475em).

So Source Serif 4 at 1.5 looks noticeably looser than Merriweather at 1.5. Matching Inter's look in Source Serif 4 would take a line-height of about 1.32. That is a visual comparison from our arithmetic, not a recommendation to go below 1.5: if you are following MDN's minimum or setting your defaults to the AAA values, keep 1.5 and accept the more open texture. A font with a small x-height may simply want a slightly larger font size, which also raises the x-height in pixels.

Paragraph Spacing: Two Different Numbers

The two success criteria describe paragraph spacing differently, and it helps to compute both.

SC 1.4.12 (AA). Spacing following paragraphs of at least 2 times the font size. At 16px that is 32px after each paragraph. Your layout does not have to use it; it has to survive a reader applying it.

SC 1.4.8 (AAA). Paragraph spacing "at least 1.5 times larger than the line spacing." The Understanding page explains it as the top of the last line of one paragraph being 250 percent farther from the top of the first line of the next than ordinary line spacing would put it, and as a blank line between paragraphs "that is 150% of the single space blank line." With 16px text at line-height 1.5, line spacing is 24px. Moving the next line's top from 24px to 2.5 × 24 = 60px away means adding 36px, and 150 percent of a 24px blank line is also 36px. Both descriptions arrive at 36px, or 2.25em, under that reading.

In CSS, p { margin-block: 0 2.25em; } with line-height: 1.5 matches the AAA reading at any body size. A smaller default such as 1em is common and fine for AA, since nothing requires the AAA value in the page's own styles. For an article column, margins in em follow the paragraph's own font size, so they stay in proportion when the reader's settings change.

Testing Against the 1.4.12 Overrides

The fastest way to see whether a text column holds up is to apply the four 1.4.12 values yourself. A user stylesheet or a bookmarklet with these rules does it:

* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}
p {
  margin-bottom: 2em !important;
}

The Understanding page notes that users can apply these through "a user stylesheet, bookmarklet, extension, or application", and it lists a text adaptation bookmarklet among its resources.

The overrides change your line length as well as your line height. Our arithmetic adds 0.12em to every character and a further 0.16em to every space (18 percent of the characters in our samples). In Inter, a character then averages 0.474 + 0.12 + 0.16 × 0.18 = 0.623em, so a 31.3em column designed for 66 characters holds about 50. All six fonts come out at 49.5 to 50.4 characters under the overrides. That is not a failure: 1.4.12 asks that no content or function is lost, and a column that simply wraps more text passes. What fails is anything that assumes a line count: fixed-height cards, line-clamped excerpts that hide their last words, and buttons with a fixed height.

What to look for with the overrides on:

• Text cut off at the bottom of a box with a fixed height
• Teaser cards that clamp to three lines and now hide a word that changed the meaning
• Labels and badges with fixed widths that now overlap their neighbours
• Captions positioned over images with absolute offsets that collide with the image's focal point

A Starting Stylesheet With Every Value Explained

Here is a base for an article column that meets the AAA width and spacing values by default and survives the AA overrides. The comments give the reason for each number.

.article {
  font-size: 1.125rem;   /* 18px at the default root size */
  line-height: 1.5;      /* unitless: 27px here, recomputed per element */
  max-width: 31em;       /* about 64 to 69 characters in the six fonts measured */
  margin-inline: auto;
  padding-inline: 1rem;  /* add this to max-width if box-sizing is border-box */
}

.article p {
  margin-block: 0 2.25em; /* the 1.4.8 reading; 1em is enough for AA */
}

.article h2 {
  line-height: 1.2;      /* headings get their own unitless value */
}

.article pre {
  max-width: 80ch;       /* monospace: ch is exact */
  overflow-x: auto;
}

Two choices in this block deserve a comment. The 31em width is the cross-font value from the conversion table; if you know your font, use its own number from that table (Roboto is narrower, so 33.5em gives it about 75 characters, for example). And the code block's overflow-x: auto keeps long lines of code inside their own box, which matters for the 200 percent bullet: horizontal scrolling of a code block is a different matter from scrolling the whole page to read a line of prose.

For CJK pages, swap the width for max-width: 40ic on the same element, and check line spacing against the conventions of that writing system: the second note under both criteria encourages authors to follow local guidance for their script.

A Five-Minute Check of a Live Page

You do not need a font editor to check an existing page.

1. Count one real line. Select a full line of body text in the middle of a paragraph, paste it into any character counter that counts spaces, and repeat for three or four lines. The average is your measure. If it is over 80, the AAA width is not met by default.
2. Run the alphabet test. Paste "abcdefghijklmnopqrstuvwxyz" two and a half times into a paragraph in DevTools. Butterick's test says two to three alphabets should fit. Lowercase letters run wider than prose with spaces (0.531em against 0.474em in Inter), so this test reads a little conservative.
3. Read the computed line-height. In DevTools, inspect a paragraph and a heading. If both show the same pixel value, a length or percentage is being inherited and headings are at risk.
4. Apply the overrides. Use the stylesheet above and scroll the page for clipped text.
5. Raise the default text size. Change the browser's default font size to the largest setting and check whether the column width grew with it or the lines got shorter.

For the wider accessibility picture around these checks, including contrast and resize testing, see our WCAG compliance guide. If the line spacing looks right but the face still reads poorly at body sizes, the problem may be the typeface itself, and our guide to choosing fonts for web design covers that side.

Line Length and Line Height Questions

What is the optimal line length for reading on a website?

There is no single proven optimum. WCAG 2.2 SC 1.4.8 (Level AAA) sets a maximum of 80 characters, a 2005 literature review in Visible Language summarized research recommendations as no more than about 70, and Butterick's Practical Typography recommends an average of 45 to 90 characters including spaces. A target in the mid-60s with a hard ceiling under 80 satisfies all three.

Does max-width: 65ch give 65 characters per line?

No. The ch unit is the width of the digit zero, which in most text fonts is wider than an average character in a sentence. In our measurements a 65ch column held 72 characters in Source Serif 4 and 86 to 87 in Inter, Lora and Merriweather. For prose, an em value based on the font's average character width is more accurate; about 31em gives roughly 64 to 69 characters across the six fonts we measured.

What is the best line height for body text?

Start with a unitless 1.5. It matches the space-and-a-half spacing in SC 1.4.8, the 1.5 value in SC 1.4.12 and Technique C21, and MDN's recommended minimum for paragraph content. A font with a small x-height may look airy at 1.5, which is better handled with a slightly larger font size than with tighter leading.

Do I have to set line-height to 1.5 to meet WCAG AA?

No. SC 1.4.12 at Level AA requires that content works when a user forces line height to 1.5 times the font size, along with the paragraph, letter and word spacing values. The criterion's own note says content "is not required to use these text spacing values." Setting 1.5 as your default is still a good idea, because your layout is then already tested at that value.

Should line-height use px, em or a unitless number?

A unitless number. It is inherited as a multiplier, so each element computes its own line height from its own font size. A px, em or percentage value is resolved on the element where it is set and inherited as a fixed length, so a larger heading inside it can end up with lines shorter than its font size.

How does line length work for Chinese, Japanese and Korean text?

SC 1.4.8 halves the limit to 40 characters for CJK, based on the Understanding page's statement that CJK characters are about twice as wide at equal readability. CSS's ic unit, the advance of the "水" ideograph, makes max-width: 40ic a direct way to set it.

Sources

All sources checked November 13, 2026.

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation 12 December 2024: text of SC 1.4.8 Visual Presentation (Level AAA) and SC 1.4.12 Text Spacing (Level AA), including the notes that content is not required to use these values.
• W3C WAI, Understanding SC 1.4.8 Visual Presentation (updated 06 September 2026): definitions of space-and-a-half and paragraph spacing, full-screen window, CJK width statement, sufficient techniques G204, C20, C21 and G188.
• W3C WAI, Understanding SC 1.4.12 Text Spacing (updated 01 October 2025): authors not required to use the values, user stylesheet and bookmarklet methods, basis in the McLeish study.
• W3C WAI, Technique C20: Using relative measurements to set column widths: example max-width 70em, test procedure.
• W3C WAI, Technique C21: Specifying line spacing in CSS: example line-height 1.5, test for spacing between 1.5 and 2.
• W3C, CSS 2, Visual formatting model details, section 10.8: line-height normal as a reasonable value based on the font, recommended 1.0 to 1.2, number values multiplied by font size.
• MDN Web Docs, line-height (last modified August 11, 2026): normal roughly 1.2 depending on font-family, unitless values preferred, inheritance example, minimum 1.5 for paragraph content.
• MDN Web Docs, length (last modified July 8, 2026): definitions of ch (advance of the 0 glyph, 0.5em fallback), ic, em and rem.
• Nanavati, A. A. and Bias, R. G., Optimal Line Length in Reading: A Literature Review, Visible Language 39(2), 2005: about 70 characters per line, short and long lines both slow reading.
• Matthew Butterick, Practical Typography, Line length and Line spacing: 45 to 90 characters including spaces, the alphabet test, 120 to 145 percent line spacing, unitless CSS line-height.
• Google Fonts, google/fonts repository on GitHub: variable TTF files for Inter 4.001, Roboto 3.015, Open Sans 3.003, Lora 3.008, Merriweather 2.100 and Source Serif 4 4.004, downloaded November 13, 2026.

The character widths, ch widths, declared line metrics and x-heights were measured here on November 13, 2026 from those font files, instanced at weight 400 (and width 100, optical size 16 where available, 18 for Merriweather) with fontTools and shaped with HarfBuzz over two English sample paragraphs of 631 and 551 characters. Every conversion, override and spacing figure on this page is our own arithmetic from those measurements and the definitions above.