The 66-Character Line: Why Narrower Notes Are Easier to Read

Your note editor is the wrong shape by default. On a 27-inch monitor, a Markdown file at full window width stretches one line of prose across a hundred and thirty characters or more — well outside the range typographers converged on for readable body text. The typographic measure is the design decision most note apps quietly leave to the viewport.

Robert Bringhurst named the range in 1992: "Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size," with "the 66-character line (counting both letters and spaces) widely regarded as ideal" ¹.

That prescription predates the modern note editor. What the note editor added was the ability to ignore it. A Markdown renderer with no width hint fills whatever container it is given, so the shape of your reading column becomes an accident of your window, not a decision. The fix is one CSS rule. The interesting part is why the rule is worth setting.

What is the ideal line length for reading?

Between 45 and 75 characters per line, with 66 characters widely regarded as ideal — that is Bringhurst's print prescription. Butterick's web-oriented rule is a compatible range of 45 to 90. A "measure" is not a single number; the point is not to hit 66 exactly, but to leave the default hundred-plus behind.

The two rules overlap by design. Butterick's upper end is wider because a web viewport is more forgiving than a serifed print page, and because reading speed rises with line length even where comprehension does not.

His practitioner rule of thumb, "You should be able to fit be­tween two and three al­pha­bets on a line" ², is the way you can eyeball a measure without a character counter. Type the alphabet twice. If a line of your notes fits into that horizontal span, you are in the range.

Why wide text lines are hard to read

The reason is not aesthetic. It is a specific problem with the return sweep — the movement your eye makes from the end of one line to the start of the next — which gets less reliable as the line gets longer. Butterick states the mechanism plainly, and the fix is architectural, not cosmetic.

His full sentence: "As line length in­creases, your eye has to travel far­ther from the end of one line to the be­gin­ning of the next, mak­ing it harder to track your progress ver­ti­cally" ². The wider the column, the more often you lose your place.

Butterick also names why characters is the right unit, not inches, not pixels, not em-widths. "The most use­ful way to mea­sure line length is by av­er­age char­ac­ters per line. Mea­sur­ing in inches or cen­time­ters is less use­ful be­cause the point size of the font af­fects the num­ber of char­ac­ters per inch. Whereas char­ac­ters per line works at any point size" ².

A note editor that respects the measure has to reason about characters, not viewport width — which is exactly what the browser primitive we come to below was designed for.

The peer-reviewed screen-reading study

The counterintuitive finding is that the comfortable line and the fast line are not the same. Mary Dyson's 2004 review in Behaviour & Information Technology synthesizes her own 2001 study with Mark Haselgrove and reports both effects in one sentence: 55 characters per line produces better comprehension; 100 characters is read faster.

The exact wording: "Dyson and Haselgrove (2001) found that line length in­fluences readers' comprehension with documents at 55 characters per line producing better comprehension scores than the longest line length (100 characters per line)" ³. The same paper found that "a medium line length of 55 characters per line was rated as easiest to read, but was not read the fastest" ³.

The study's method matters. Dyson and Haselgrove compared "six line lengths… ranging from 25 to 100 characters per line" on screen, measuring both reading rate and comprehension ³. The peer-reviewed finding lands inside the Bringhurst-Butterick range, which is why the print-and-screen prescriptions can be quoted in the same paragraph without contradicting each other.

Bringhurst's "widely regarded" is what a controlled trial confirmed, on screen, seventy-five years after most of the print rules got written down.

The honest counter — wider is faster to skim

The measure is not universally superior. Two other empirical results push the other way. Shaikh and Chaparro's Wichita State study reported that 95 characters per line produced significantly faster reading speed. Human Factors International's review of the same body of work said users prefer moderately long lines even when they read wider ones faster.

The full findings: Shaikh and Chaparro found "a main effect of line length was found with the 95 cpl condition resulting in significantly faster reading speed" ⁴. Human Factors International summarized it as: "Users tend to read faster if the line lengths are longer (up to 10 inches). If the line lengths are too short (2.5 inches or less) it may impede rapid reading. Finally, users tend to prefer lines that are moderately long (4 to 5 inches)" ⁵.

The honest reconciliation is that the measure is for the way you read your own notes, not for every reading task there is. Long lines are faster when you are skimming.

Narrower lines are better comprehended when you are re-reading carefully — the same Shaikh and Chaparro paper found "the 35 cpl condition resulted in the highest comprehension score for the narrative passages" ⁴. Note-taking is closer to careful re-reading than to skim; that is what makes the measure worth setting for a note editor. If the tool were a news aggregator, the answer would flip.

The CSS one line that sets the measure

The implementation is a single browser primitive: the CSS ch unit. MDN defines it as the advance measure of the digit 0 in the element's current font, so 66ch stays the intended measure whether the reader picks a 14-pixel screen font or a 24-pixel comfort font. One rule of CSS sets the shape.

MDN's exact language: ch "represents the width or, more precisely, the advance measure of the glyph 0 (zero, the Unicode character U+0030) in the element's font" ⁶. The rule can live at whichever level of the editor accepts a style: the article container, the editor pane, or the site's global stylesheet.

.note, article, .editor {
  max-width: 66ch;
  margin-inline: auto;
}

One caveat keeps the CSS honest. Because ch is anchored to the width of the digit 0, it is not a true average character width — real prose contains letters both narrower and wider than a monospace zero.

A max-width: 66ch rule delivers a line that is close to 66 characters of body text on most humanist typefaces, not exactly 66. That is fine. The point is the range, not the count, and the browser primitive is what makes the range easy to preserve.

The note file has no width — the renderer does

The CSS decision belongs at the display layer because the Markdown file itself has no line-length hint. CommonMark, the spec most Markdown implementations follow, says so in §6.8: a soft break can render as a line ending or as a space, and the result is the same in the browser. The width is a display choice.

The spec's language: "A regular line ending (not in a code span or HTML tag) that is not preceded by two or more spaces or a backslash is parsed as a softbreak. (A soft line break may be rendered in HTML either as a line ending or as a space. The result will be the same in browsers…)" ⁷

That decision is separate from another one that gets confused with it: whether to hard-wrap the source file for a reason unrelated to reading. Diffs, review workflows, and code-adjacent notes have their own case for wrapping the source at 72 to 80 columns — a different application of the same 45-to-75 span, and one we cover in Hard-Wrap or Soft-Wrap Your Notes? The Diff Decides.

That piece is about wrap-on-disk for diff granularity. This one is about display column for reading. Same measure; two different jobs.

When the measure is the wrong tool

The measure is a prose rule. Code, tables, ASCII diagrams, and log excerpts are not prose, and constraining them to 66 characters actively harms them. A note that mixes prose with a wide code block deserves a layout that lets the prose column stay narrow while the other blocks break free.

The Linux kernel style guide famously puts the preferred line-length limit at 80 columns because C programmers read syntax, not sentences. Other code style guides go to 100 or 120. Tables need whatever width keeps their columns legible; ASCII diagrams need whatever width they were drawn at.

A single hard max-width: 66ch on every element in an editor is a blunt fix, and it will squeeze code and tables that would be more readable at full viewport. The polite version is one width for prose elements, and a wider one (or none) for pre, table, figure, and their kin. Two rules instead of one.

What sits inside the measure matters too

A narrower column changes how the rest of the type reads. Long lines mask small line-height problems; the measure exposes them. Line length is one lever in a small set — point size, line spacing, and the typeface itself are the others — and each one decides what your prose looks like inside the column you just narrowed.

Butterick's opening in "Typography in ten minutes" states the whole set in three sentences: "Point size is how big the font is. In print, the most com­fort­able range for body text is 10–12 point. On the web, 15–25 pix­els" ⁸. He recommends "an av­er­age of 45–90 char­ac­ters per line" as one of the four choices in that same opening.

The font side of the same decision is a story on its own — a viral cognitive-science claim, its failed replication, and the more durable finding about how a typeface changes how hard you feel you are working. We cover it in The Font on Your Screen Is Shaping How You Think.

Font and measure are the two axes of a legible reading surface for your own notes. This piece owns the width axis; that one owns the font axis.

Frequently asked questions

How wide should a text column be?

Between 45 and 75 characters per line for a single-column page of body text, with 66 characters "widely regarded as ideal," per Robert Bringhurst's Elements of Typographic Style. Matthew Butterick's web-oriented rule widens the upper end to 90. The number is a range, not a target; the point is to leave the default full-viewport width behind.

What is the ideal line length for reading?

45 to 75 characters per line in print typography (Bringhurst), 45 to 90 in web practice (Butterick), and 55 characters per line in a peer-reviewed screen-reading study by Dyson and Haselgrove (2001) that measured both comfort and comprehension. All three overlap in the 55 to 75 span.

Why are wide text lines hard to read?

Because the return sweep — the eye's movement from the end of one line to the beginning of the next — becomes less reliable as the line gets longer. As line length increases, the eye has to travel farther to find the next line, making it harder to track progress vertically. The wider the column, the more often you lose your place.

What is the CSS for a 66-character line?

max-width: 66ch on the container. The ch unit is defined by MDN as the advance width of the 0 glyph in the current font, so it scales with the reader's font choice. The rule is not exactly 66 characters of prose because ch is a monospace-derived approximation, but it delivers a line close to the intended measure across any font size.

Does hard-wrapping my Markdown file at 80 columns achieve the same thing?

No — it is a different job. Wrapping the source file at 72 to 80 columns is about diff granularity and source-file readability, not about how prose displays for a reader. A soft-wrapped source can still display at max-width: 66ch; a hard-wrapped source can still display at full viewport. The measure is a display decision; the wrap is a source-file decision.

Is a narrower measure always better?

No. Narrower is better for comprehension and re-reading; wider is faster for skimming. Shaikh and Chaparro found 95 characters per line produced significantly faster reading speed, while 35 characters per line produced the highest comprehension for narrative passages. Note-taking is closer to careful re-reading than to skim, which is why the measure is worth setting for a note editor specifically.

What is the right line length for code?

Wider than for prose — the Linux kernel style guide prefers 80 columns, other code style guides go to 100 or 120. Code is not prose, and the return-sweep argument does not apply to reading syntax. A note editor with a narrow prose measure should let code blocks, tables, and diagrams break the measure and use the width they need.

References

A note editor at full window width across a wide monitor is a design decision the app made for you and left unspoken; the measure is the same decision, set on purpose, by someone who has to re-read what they wrote — a plain-Markdown reading surface for your own device, at a shape you can set once, is what mnmnote.com is built around.