In a design system, why do body text columns target roughly 45 to 75 characters per line, and how is that enforced?
answer
- the eye's trip back to the next line
- too long: readers lose their place
- too short: phrases chopped apart
- cap width relative to type size
- print convention, not a WCAG number
basics
~20 sRoughly 45 to 75 characters per line is a typographic convention: longer lines make the eye lose the start of the next line, shorter ones chop phrases apart. A system enforces it by capping reading-column width relative to the type size.
solid answer
~50 sThe **measure** is the length of a line of running text. Very long lines make the eye's return sweep to the next line land on the wrong line; very short ones split phrases and force constant sweeps. Roughly 45 to 75 characters for single-column body text is a long-standing typographic convention, not a WCAG rule: the nearest standard is the Level AAA criterion 1.4.8 Visual Presentation, which asks for a mechanism that can bring text blocks to no more than 80 characters wide. A design system encodes the convention as a default: long-form containers get a maximum reading width expressed relative to the body type size, so the character count holds if the size changes. On a news article page that means the body column stops widening on large screens, and the spare space goes to margins, a side rail or wider media.
go deeper
Recall that the measure is line length in characters, that roughly 45 to 75 is the common comfortable band for body text, and that it is a convention rather than a WCAG rule.
Explain the return sweep: why long lines cause lost places and short lines cause choppy reading, and why the cap is tied to the type size instead of a fixed width.
Show how you would build the cap into the long-form layout component, let media break out, and handle phones, tablets and brand size changes without teams hand-tuning widths.
Weigh a system-wide reading-width default against product requests for edge-to-edge text, and decide what the system enforces in components versus leaves as documented guidance.
## What the measure is In typography, the **measure** is the length of a line of running text, usually counted in characters including spaces. It is one of the three settings that most shape how comfortable a block of body copy is to read, alongside **line height** (the vertical distance from one baseline to the next) and the size of the type itself. A news article, a long help page or a report is read in long continuous passages, so the measure of its body column matters far more there than on a dashboard or a form. ## Why both extremes hurt Reading is not a smooth glide. The eye moves in short jumps along a line, then makes a long **return sweep** back to the start of the next line. The measure changes how hard those two movements are: - **Too long** (well past 80 characters): the return sweep is long and diagonal, so readers more often land on the wrong line, re-read a line, or lose their place. Very wide text blocks also look like a grey wall that is tiring to start. - **Too short** (well under 40 characters): the eye sweeps back constantly, phrases are split across lines, and the ragged edge becomes jagged. Reading feels choppy. - **In the comfortable band**: each line carries a meaningful phrase or two, the return sweep is short enough to land accurately, and line height does not have to be pushed very loose to compensate. Measure and line height interact: the longer the line, the more line height readers need to find the next line, which is one reason a system tunes the two together rather than in isolation. ## Where the numbers come from The 45 to 75 character range is a long-standing convention from book and print typography, with about 66 characters often quoted as a comfortable single-column target. It is **common practice with a readability rationale, not a rule any standard mandates**. The only nearby standard number is in WCAG, and it is different in kind: | Source | What it says | Status | |---|---|---| | Typographic convention | Roughly 45 to 75 characters for single-column body text | Guidance, widely followed | | WCAG 2.2 SC 1.4.8 Visual Presentation | A mechanism is available so blocks of text can be no more than 80 characters wide (40 if CJK) | Level AAA; the mechanism may come from the user agent | | WCAG 2.2 SC 1.4.12 Text Spacing | Content survives user overrides of line, paragraph, letter and word spacing | Level AA; says nothing about line length | So a candidate who calls the measure a WCAG AA requirement is wrong, and one who treats 75 as a hard pass-or-fail threshold is overstating a convention. ## How a design system encodes it A design system is where a readability convention becomes a default that every product team gets for free. The usual encoding: 1. **Define a reading-width constraint** for long-form text containers, expressed relative to the body type size (a width in characters, or in multiples of the type size), not as a fixed device width. The rule is about characters, so tie it to the thing being counted: if the body size changes for a brand or a density mode, the characters per line stay roughly constant. 2. **Build it into the long-form layout component** (an article body, a prose block) so teams do not re-derive it per page. On a wide desktop screen, the spare space goes to margins, a side rail of related stories or a wider media column, not to longer lines of text. 3. **Let media break out**: photographs, embedded charts and pull quotes can run wider than the text column, because they are not read line by line. 4. **Document the reason next to the value**, so a product team asking for full-width text on a promotional page knows what it trades away. ## Edge cases on a news site and app - **Phones**: a phone column often holds only 35 to 45 characters of body text. That is acceptable; the viewport is the constraint. Shrinking the body text to reach 60 characters trades a mild measure problem for a worse size problem. - **Tablets in landscape and desktops**: this is where the cap actually bites; without it an article body can run well past 100 characters per line. - **Headlines, captions and labels** are not continuous reading, so the body cap does not have to apply to them, though very long multi-line headlines also benefit from a sensible width. - **Data tables and code listings** are scanned rather than read as prose, and should not be squeezed into the reading column. - **Reader overrides**: when a reader enlarges spacing or text, the characters per line fall. The layout should reflow rather than clip, which is a separate requirement under WCAG 1.4.12. A strong answer frames the measure as a system-level default with a stated reason and an escape hatch for media, rather than as a magic number each designer has to remember.
- A phone column holds only about 38 characters of body text. Is that a defect to fix?Usually not. The lower edge of the band is softer than the upper one, and on a phone the viewport is the constraint. The wrong fix is shrinking body text to fit more characters, which trades a mild measure issue for a real size problem. Keep side margins modest and let the text wrap; the cap matters most on tablets and desktops.
- Why express the reading width relative to the type size instead of as a fixed width?The rule counts characters, and characters per line depend on the type size and the typeface. A fixed width tuned for one body size lets a smaller brand size run past the band and a larger one fall short of it. A width tied to the type size keeps roughly the same count across brands, density modes and platforms.
- Should embedded charts and photos in an article obey the same width cap as the prose?No. The cap exists for text read line by line. Media, pull quotes and data tables are viewed or scanned, so a system usually lets them break out wider than the reading column while the prose stays capped. The layout component should model both widths so teams do not hack around the cap.
saying these in an interview costs you the question
- WCAG 2.2 Level AA requires body text lines of 45 to 75 characters.
- Body text should simply fill whatever width the layout column provides.
- Wider lines are better on big screens because readers see more at once.
- A fixed pixel width guarantees the same characters per line for any font size.
- Shrinking phone body text to fit 60 characters per line improves reading.