The 45 to 75 character line length comes from a book that cites no study

A lesson from UI and UX for Engineers: Judging the Interfaces You Ship. Play it above, or read it through below.

• The measure is a preference, and preference does not track performance.

  The common read: 45 to 75 characters is the researched optimal line length, and 66 is the measured ideal.

  The sentence everyone cites contains the words "is widely regarded as", and it contains them twice. Bringhurst writes that anything from 45 to 75 characters is widely regarded as a satisfactory length for a single-column page set in a serifed text face, and that the 66-character line is widely regarded as ideal. He cites nobody, the subject is print, and the book's own justification is a copyfitting table and an informal guideline.

  On speed, the screen studies find the opposite. The review that synthesises them states that most studies on line length report faster reading with longer lines. One study at 25 to 100 characters found the longest read fastest; another at 35 to 95 found 95 significantly faster; a third at 45, 76 and 132 found no significant difference in reading time at all, and recommended 65 to 75 on stated preference.

  The more useful finding is the reviewer's own sentence: subjective judgements of text format on screen have not been in close agreement with objective performance measures. Longer lines may be read faster, and people still prefer a moderate length. The reviewer also suggests a cause: the preferred range may be preferred because it is familiar from print.

  A common failure: a redesign is validated only on satisfaction scores and shipped, time-on-task gets worse, and nobody connects the two, because a survey replaced the study that would have measured time on task. Keep the measure. Defend it as comfort, which is what a century of preference data supports, and do not attach a speed claim to it, because the studies find the opposite.

• Sixteen is a default, and the good argument for it is not the one you were given.

  The common read: 16 pixels is the minimum accessible body size, and shipping smaller is a conformance problem.

  Sixteen pixels is a default, not a minimum. The CSS absolute-size keyword medium is defined as the user's preferred font size, and every other keyword scales from it. WCAG names no minimum font size. The only sizes it names, 18 point and 14 point bold, define large-scale text for the contrast criteria. The only floor the reference documentation states is that the smallest font size should not be less than 9 pixels, and Apple's own guidance says text should be at least 11 points.

  So the rule people enforce does not exist, but a better argument does. If a user has not changed their browser's font size, 16 pixels is the size they implicitly accepted. Shipping body text at 14 overrides a preference they expressed by omission. That argument is consistent with the specifications, and it is stronger than citing a rule that a reviewer cannot name.

  The preference argument also explains something the 16px-minimum version does not. The argument is about the ROOT size and the user's control of it, which is why the unit question follows from it rather than the other way round: rem inherits the preference and px ignores it. The reason to prefer rem for type is not that px is deprecated, and it is not that rem renders differently. It is that rem is relative to a value the user sets.

  A common failure: a reviewer comments "16px minimum per WCAG" on a component that is fine, quoting a rule that is not in the document, while the same product's hero is sized in a viewport unit that zoom cannot enlarge. Make the argument you can defend, and spend review time on the two criteria that do exist, which the next screen covers.

• Two criteria are about what the reader changes, and one unit fails the first.

  The common read: rem is the accessible unit, so a fluid type scale built from clamp with a vw middle term is the accessible way to size text.

  Two criteria govern what happens when a reader makes the text bigger, and one named failure technique says a unit you probably shipped this year fails the first of them. SC 1.4.4 Resize Text, Level AA, requires that text can be resized without assistive technology up to 200 percent without loss of content or functionality. SC 1.4.10 Reflow, Level AA, requires no two-dimensional scrolling at a width equivalent to 320 CSS pixels.

  The 320 does not refer to a phone. The Understanding document says it corresponds to a desktop browser window of 1280 pixels zoomed to 400 percent, and the companion height of 256 pixels is 1024 at the same zoom. A criterion most engineers read as a mobile requirement is a magnification requirement, which is why a layout can pass every device test and fail it.

  F94 names sizing text in viewport units as a failure of 1.4.4, because those units cannot be resized by zooming or adjusting text size. A clamp() with a vw middle term can fail the same way. At 200 percent zoom the window is half as many CSS pixels wide, so the vw value halves, and a heading sized by it or held at its maximum grows less than the body text. Zoom to 200, 300 and 400 percent and check that the heading reaches twice its original size.

  A common failure: one user files a support ticket, three people test at 100 percent on 27-inch monitors and close it as not reproducible, and nobody connects it to the release that converted the stylesheet to rem for accessibility. Test at the numbers the criteria name: 200 percent, then 400 percent at a 1280-pixel window, and look for the two things they name, which are clipping and horizontal scrolling.

• Font size changed reading measures. Line spacing did not.

  The common read: Longer lines need more leading, and a leading scale tuned per breakpoint is the research-based way to set body text.

  Which typographic variable has been shown to change reading? Font size, not the line spacing that type systems tune per breakpoint. The largest modern experiment varied six font sizes and four line spacings with 104 eye-tracked participants. Line spacing had only minimal effects, with weak evidence that 0.8 and 1.8 may impair readability. Comprehension was significantly lower at 10 and 12 points, and 12 points is 16 CSS pixels, the browser default. Mean fixation duration kept falling up to 18 points, which is 24 CSS pixels.

  The rule the industry teaches about leading and measure has no clear evidence behind it. Long lines are SAID to need more interlinear spacing so the return sweep reaches the start of the next line accurately. The review's verdict is that increasing interlinear space might help and that this has not been explored, and that the limited studies are from the early 1980s and are inconclusive.

  There is also a methodological problem. As line length increases without a corresponding increase in leading, the ratio between the two changes, so any difference attributed to the longer line might be due to the reduced relative leading. So when a line-length study reports a difference and credits it to the longer line, the cause may be the smaller relative leading instead.

  A common failure: two people spend a week on a type system with a leading value per breakpoint per role, defended in review as research-based, for a product whose body text is 14 pixels. Spend the effort on the variable that was measured: make the text bigger. Font size is the variable that changed reading measures in the same experiment that found line spacing had only minimal effects.

• The browser chooses the line breaks, and stops balancing without a warning.

  The common read: text-wrap: balance evens out my paragraphs, so putting it on body copy in a reset improves every block of text on the page.

  The specification leaves the algorithm to the browser engine, and says so explicitly. balance chooses line breaks to balance the remaining space in each line box if better balance than auto is possible, the exact algorithm is user-agent defined, and the specification permits an engine to treat the value as auto past ten lines. So the specification allows the property to do nothing.

  The line limit exists, and sources give different numbers for it. This lesson measured Chromium 151 balancing at 6 lines and not at 7. The reference documentation reports six or fewer for Chromium and ten or fewer for Firefox. Chrome's own article says six. WebKit's says Chromium limits balancing to four lines and that its own implementation needs no limit at all.

  pretty is the body-copy value and it also differs by engine today. Safari 26, released in September 2025, evaluates the whole paragraph, and describes its own goal as preventing short lines, improving the rag and reducing the need for hyphenation across all of the text no matter how long it is. Chromium adjusts only the last few lines of the paragraph. The same declaration produces materially different line breaks in the two engines.

  A common failure: a developer adds the declaration to p in a reset, sees nothing change, concludes the property is broken, and never uses either value on the headings and pull quotes where one of them works. Treat both as progressive enhancement and never as layout: put balance on short things, put pretty on prose, and check the line count before believing that a declaration you can see in the stylesheet is doing anything at all.