Skip to main content

05.24Interfaces

Technical blog readability: evidence-based typography and layout

Which typography, contrast, spacing and code-block choices make technical blog posts easiest to read in light and dark mode, graded by strength of evidence.

Plate: a page split into light and dark halves, each with a large Aa and a text column marked with its measure.A page split down the middle by a violet line: the left half paper with ink type, the right half ink with paper type, each showing a large Aa and a column of text lines with a measure bracket.AaAaMEASURELIGHTDARKR-24INTERFACESMOTIF: GRIDS2026 · 07 · PLATE 24 / 30FINDINGEVERY TYPE CHOICE GRADED BY ITS EVIDENCE
On this page
  1. Summary
  2. Checklist of testable principles
  3. Findings by sub-domain, with evidence
  4. Evidence gaps
  5. Methodology
  6. Sources with CRAAP notes

Which typography and layout choices make long-form technical blog posts easiest to read on screen, in both light and dark mode? AR Labs researched this question in July 2026 as background for the reading pages of arlabs.tech. The report triangulates typography authorities, usability research from Baymard and Nielsen Norman Group, the WCAG accessibility standard and peer-reviewed studies, and grades each finding as high, moderate or low confidence.

Method: two research passes (breadth, then pathway exploration), 10 searches and 28 sources analysed, 19 of them scoring 4.0 or higher on CRAAP source evaluation (currency, relevance, authority, accuracy, purpose).

Summary

Evidence-based web typography for long-form technical reading converges on a clear set of numeric ranges: 16–20px body text, 1.5–1.6× line height, 45–75 characters per line (with 66 chars the most-cited optimum), and a column width of 600–750px. These recommendations have strong triangulation from typography authorities (Butterick), usability research (Baymard, Nielsen Norman Group), and accessibility standards (WCAG). Dark-mode-primary blogs face real trade-offs: research shows light mode has a measurable legibility advantage ("positive polarity effect"), but dark mode comfort preferences are real and the gap narrows with proper implementation. The highest-impact dark-mode interventions are using off-white text (not pure #FFFFFF), off-black backgrounds (not #000000), and slightly elevated font weight. Code block presentation has the weakest evidence base of all seven sub-domains: practitioner consensus (horizontal scroll preferred over line-wrap for code) exists but formal research is sparse.

Checklist of testable principles

This checklist contains concrete, auditable criteria derived from the evidence. Each item is tagged with a confidence grade (H = High, M = Moderate, L = Low).

1. Body typography

Criterion Target Range Confidence
Body font size 16–20px (18px ideal for text-heavy blogs) H
Line height 1.5–1.6× font size (24–32px at 16–20px base) H
Characters per line (measure) 45–75 chars; 66 chars optimum H
Content column width 600–750px at default zoom H
Font type (serif vs sans-serif) Either acceptable on modern screens; specific typeface design matters more than classification M
System font vs web font System fonts: better performance, zero FOUT; web fonts: brand identity but ~16% page weight M
Font x-height Larger x-height improves letter recognition across all letters M

2. Contrast and colour

Criterion Target Confidence
Body text contrast ratio ≥4.5:1 (AA) against background; ≥7:1 (AAA) for enhanced H
Large text (18pt+) contrast ratio ≥3:1 (AA) H
Pure black (#000000) on pure white (#FFFFFF) 21:1 ratio; passes WCAG but causes halation for ~30–60% of users with astigmatism H
Recommended light-mode body text colour Soft near-black: #1a1a1a to #333333 (contrast still ≥10:1 on white) M
Colour alone for links Insufficient per WCAG 1.4.1; must have non-colour differentiator H

3. Dark mode readability

Criterion Target Confidence
Dark mode vs light mode comprehension Light mode has small but measurable advantage ("positive polarity effect") M
Dark background colour Near-black, not pure black; Material Design recommends #121212 H
Dark mode text colour Off-white, not #FFFFFF; #E0E0E0 or #CCCCCC reduces halation H
Font weight in dark mode Increase slightly (e.g. 400→500) to compensate for reduced perceived stroke width M
Line height in dark mode 1.5–1.6× (same as light; some practitioners recommend 1.6× minimum) M
Dark mode contrast ratio Still requires ≥4.5:1; WCAG applies in both modes H
Elevated surfaces for hierarchy Use luminance steps (lighter = higher elevation), not shadows (shadows invisible on dark) M

4. Spacing and rhythm

Criterion Target Confidence
Paragraph spacing method for web Space between paragraphs (not first-line indent); the web convention H
Paragraph spacing amount Approximately line-height ÷ 1.5 (e.g. if line-height = 30px, paragraph gap ≈ 20px) M
Heading top margin vs bottom margin Top margin should be ≥2× bottom margin; heading must connect visually to text below it M
Space before heading (vs paragraph gap) ≥2× paragraph spacing (e.g. 40px+ if paragraph gap is 20px) M
Vertical rhythm baseline Consistent spacing multiples of base line-height; reduces cognitive friction M

5. Layout

Criterion Target Confidence
Content column width 600–750px (enforces 45–75 CPL at typical sizes) H
Single-column vs multi-column Single column for body text; multi-column reduces focus and engagement H
Sidebar presence Only justified for long-form (TOC); sidebars distract from primary reading M
TOC placement Static in body (above content) OR sticky in right rail; right-rail TOC suffers from "right-rail blindness" in some users M
TOC for short posts Omit TOC if fewer than 3–4 sections; adds noise without navigation value M
F-pattern implications Put information-bearing words at the left edge of content; front-load headings H

6. Code block presentation

Criterion Target Confidence
Code font Monospace with clear glyph differentiation (0 vs O, 1 vs l vs I) H
Code font size relative to body 90–95% of body text size is common practice; too-small code is a frequent issue L
Horizontal scroll vs line wrap Horizontal scroll preferred for code; line-wrapping destroys syntactic structure M
Syntax highlighting contrast Maintain ≥4.5:1 for all token colours against code block background M
Code block background Distinct from prose background (slightly different shade) to signal context switch M
Copy button Include; reduces friction for technical readers M
Line numbers Useful for long blocks referenced in prose; adds clutter on short snippets L

7. Secondary factors

Criterion Target Confidence
Link underlines in body text Required or include underline-on-hover; colour alone violates WCAG 1.4.1 H
Link colour Blue-family hues have strongest learned signal; visited links should be visually distinct (desaturated/darker) H
Reading time estimate Display on article index AND post header; reduces bounce by signaling time investment upfront M
Bold/emphasis usage Use sparingly; overuse degrades signal value; never use for decorative purposes M
Images/figures Include alt text; use captions; avoid decorative images that interrupt reading flow M

Findings by sub-domain, with evidence

1. Body typography

Font size (high confidence)

The convergent recommendation across Butterick (15–25px on web), Learn UI Design (18–24px for text-heavy), and USWDS system standards is 16–20px for body text on text-heavy pages, with 18px as the practical sweet spot for long-form reading. 16px is the browser default and passes the Lighthouse "legible font sizes" audit, but sustained reading comfort is better served at 18px. Medium, Substack, and comparable publishing platforms consistently default to 18–21px for article body text.

Evidence for 16px as floor: it approximates 11–12pt in print, the proven comfort zone for book typography (Butterick, Ruder). Evidence for going to 18–20px on technical blogs: screens are typically viewed from further away than print (arm-length vs. lap), justifying the upward shift.

Line height (high confidence)

Butterick cites 120–145% of point size (1.2–1.45×) as the optimal range for print. Web conventions add 5–10% to this: 1.5–1.6× is the most commonly recommended range for screen reading (Moldstud, Dark Mode Typography analysis, WCAG SC 1.4.12 which requires ability to set line height to at least 1.5× without loss of content). The W3C's WCAG 1.4.12 "Text Spacing" success criterion uses 1.5× line height as its minimum functional threshold, lending it de facto normative weight.

Important distinction: Butterick's 120–145% is grounded in print aesthetics and typographic convention, not controlled readability studies. The web 1.5–1.6× recommendation is practitioner consensus cross-validated by multiple design systems, not a single empirical RCT.

Line length, or measure (high confidence)

Three independent authorities triangulate tightly:

  • Emil Ruder (mid-20th century): 50–60 characters optimal, up to 75 acceptable (cited by Baymard)
  • Robert Bringhurst (Elements of Typographic Style): 45–75 characters
  • Butterick (Practical Typography): 45–90 characters (broader range)
  • WCAG 1.4.8 (AAA): 80 characters maximum

The practical takeaway: 45–75 characters is the consensus range, with 66 characters as the frequently cited optimum. WCAG's 80-character ceiling sets a hard accessibility floor; 66 is the design target.

Provenance note: The "45–75 character rule" traces to Ruder's 1967 Typographie and Bringhurst's 1992 Elements, both print authorities. Eye-tracking research on web reading supports shorter measures (Dyson & Haselgrove found ~55 CPL supports effective reading at both normal and fast speeds), but no modern RCT has specifically validated the 66-character figure for screen-based long-form reading. The rule is well-regarded typographic convention, not a peer-reviewed empirical result, an important evidence-quality caveat.

Implementation: at 18px with a typical body font, 66 characters ≈ 650–700px column width. Use CSS max-width: 70ch to enforce this programmatically.

Serif vs sans-serif (moderate confidence)

Historical assumption: sans-serif is superior for screens due to pixel grid aliasing. This was valid at low screen resolutions (<72 DPI). On modern displays (120–220 DPI), the evidence gap has narrowed substantially.

An eye-tracking study comparing Times New Roman and Arial found faster, more accurate reading with Arial (sans-serif), but this compared print-optimised fonts, not screen-optimised serif fonts. A 2023 NCBI study on e-commerce found no statistically significant usability difference between serif and sans-serif within the same font family. The Springer book The Legibility of Serif and Sans Serif Typefaces (2021) confirms no consistent winner. Specific typeface design (x-height, weight, spacing) matters more than serif/sans classification.

Practical implication for technical blogs: either is defensible on modern screens. Sans-serif (Inter, System UI, -apple-system) is the default engineering blog choice and carries no readability penalty. Serif (Georgia, Merriweather) can signal editorial quality without harming legibility.

System fonts vs web fonts (moderate confidence)

System font stacks (e.g. -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif) eliminate FOUT (Flash of Unstyled Text), zero network request for font files, and improve Largest Contentful Paint. As of July 2024, web fonts account for ~16% of average page weight (DebugBear data). The tradeoff is reduced typographic differentiation, all sites using system fonts look similar.

For engineering blogs where content and readability are primary, system fonts are a defensible default. Variable fonts (WOFF2) + font-display: swap is the correct loading strategy if web fonts are used.

2. Contrast and colour

WCAG thresholds (high confidence)

WCAG 2.1 SC 1.4.3 (AA): 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt bold+). These are minimum floors, not targets. WCAG SC 1.4.6 (AAA): 7:1 for normal text. Both levels apply equally to light and dark modes: if a site supports a dark theme, the dark theme must independently meet the 4.5:1 AA threshold.

Pure black vs softened contrast (high confidence)

Pure #000000 on #FFFFFF achieves 21:1 contrast, technically the maximum possible. However, astigmatism (affecting approximately 30–60% of the general population) causes halation: white text or a white background "bleeds" into adjacent dark areas, creating a glowing/smearing effect that slows and fatigues reading. This is documented in accessibility literature (WebAIM, AccessibilityChecker) and supported by the empirical literature on "crowding" effects in vision science.

Recommended practice: near-black text on white (#1a1a1a, #2d2d2d, or #333333 on #ffffff). These achieve contrast ratios of 10:1 to 15:1, well above the AA floor and substantially below the halation-inducing 21:1 ceiling. No peer-reviewed RCT directly quantifies the optimal softening amount; this remains practitioner consensus informed by vision science.

Link colour (high confidence)

WCAG SC 1.4.1 requires colour not be the sole means of distinguishing links from body text. In practice this means: links must have underlines, or the link-to-text colour contrast must be ≥3:1 AND links must have a non-colour indicator on hover/focus. Blue-family hues are the strongest learned affordance for links (Nielsen Norman Group, decades of usability testing). Visited links should be visually distinct (desaturated/darker blue or purple) to support navigational memory.

3. Dark mode readability

Comprehension research (moderate confidence)

A 2025 ACM eye-tracking study (Eye Tracking Study on the Effects of Dark and Light Themes) found no statistically significant difference in reading speed or comprehension between dark and light modes in controlled conditions. A Taylor & Francis study (2025) found cognitive scores slightly higher in light mode. A systematic review (ResearchGate, 2024) confirms the "positive polarity advantage" (dark text on light background outperforms the reverse) but characterises it as a "slight negative polarity disadvantage" for dark mode rather than a large effect.

The nuance: the advantage of light mode appears larger for older users and in low-ambient-light conditions. For younger engineering blog readers under typical working conditions (room lighting, modern display), the gap is small enough that dark mode preference and comfort may dominate.

Halation (high confidence)

Pure white (#FFFFFF) text on pure black (#000000) creates halation for users with astigmatism. The same mechanism as the light-mode issue above, reversed. Material Design's adoption of #121212 as the canonical dark-mode base colour is one of the best-documented practitioner solutions with an explicit rationale (Google Codelabs / Material dark theme documentation).

Recommended dark mode colour targets (high confidence for WCAG, moderate for specific values)

  • Background: #121212 to #1e1e1e (Material Design baseline; ≈8–12% relative luminance above pure black)
  • Body text: #E0E0E0 to #CCCCCC (contrast: 12:1 to 16:1 against #121212, well above AA, below halation-inducing 21:1)
  • Surface elevation: use lighter grays at higher z-levels rather than drop shadows (shadows are invisible in dark UI)

Font weight in dark mode (moderate confidence)

Practitioner consensus (Design Shack, Moldstud, multiple 2023–2024 blog design analyses) recommends slightly increased font weight (e.g. regular 400→medium 500) for body text in dark mode. The mechanism: screen glare around light text on dark backgrounds makes thin strokes appear thinner than they are; heavier weight compensates. No controlled study quantifies this effect size. The recommendation is informed by display physics and practitioner observation, not RCT evidence.

4. Spacing and rhythm

Paragraph separation method (high confidence)

Web convention is unambiguously space-between-paragraphs rather than first-line indent. Butterick (First-line indents) is explicit: use one method or the other, never both. First-line indents are print-optimised (page economy); paragraph spacing is the web default because CSS margin-bottom or margin-top is trivial to set and readers are conditioned to it. Evidence is practitioner consensus, not an empirical study, but the consensus is universal across sources.

Paragraph spacing amount (moderate confidence)

The BetterWebType / Matej Latin formula: paragraph spacing = line-height ÷ 1.5. At 18px body text with 1.5× line-height (27px), paragraph spacing = 18px. This maintains visual grouping without "falling apart." If spacing is too large, paragraphs become disconnected islands; too small and text becomes a wall. No controlled study validates this specific formula, it is a practitioner heuristic from typographic convention.

Heading spacing hierarchy (moderate confidence)

The consensus pattern: heading's top margin should be ≥2× its bottom margin, and ≥2× the paragraph spacing used in body text. This creates visual attachment between the heading and its following text block: the heading "belongs to" the text below it. The most frequent failure mode is equal top/bottom heading margins, which causes headings to float disconnected from their content.

Example: if paragraph spacing is 20px, heading top-margin should be ≥40px, heading bottom-margin ≈ 12–16px.

5. Layout

Column width (high confidence)

600–750px is the range that enforces 45–75 CPL at typical body font sizes. This number is derived from the line-length rule (the authoritative constraint) rather than being independently established. At 18px body text with a typical font, max-width: 65ch to max-width: 75ch achieves this.

The USWDS (U.S. Web Design System) sets a 68-character-per-line recommendation. Nielsen Norman Group F-pattern research found content beyond ~600px from the left edge is rarely viewed in F-pattern reading, consistent with a 600–700px column constraint.

Single column for body text (high confidence)

Multi-column layouts tested poorly for long-form reading in usability research (NN/G). The Dyson & Haselgrove research (cited in multiple sources) found medium line lengths outperformed both very short and very long lines, and multi-column text forces very short lines. Single-column layouts also eliminate the eye-tracking discontinuity of column breaks.

Sidebar and TOC placement (moderate confidence)

Nielsen Norman Group's dedicated TOC study finds:

  • Right-rail sticky TOC is subject to "right-rail blindness" (users trained to ignore the right side as ad-heavy)
  • Users often fail to notice collapsible/sticky TOC implementations
  • If using a rail TOC: must be sticky (non-sticky requires scrolling back to top to navigate)
  • If using body TOC: should be non-sticky (a sticky horizontal bar confuses users who mistake it for global navigation)
  • TOC links must be coloured and underlined to be noticed

F-pattern eye-tracking evidence (NN/G, original Alertbox study) supports leading with information-carrying words at the left edge: headings, bullet starts and paragraph openers should front-load their meaning.

6. Code block presentation

Monospace font (high confidence)

No credible source disputes that code should use a monospace font. The rationale is functional, not aesthetic: column alignment, visual separation from prose, and preserved whitespace are necessary for code comprehension. Monospace fonts with strong glyph differentiation (0 vs O, l vs I vs 1) are critical: Fira Code, JetBrains Mono, and Cascadia Code are engineered specifically for this. Standard system monospace (Courier New, Menlo, Monaco) is acceptable but sub-optimal at small sizes.

Horizontal scroll vs line wrap (moderate confidence: practitioner consensus, not RCT)

Practitioner consensus from developer community discussions, GitHub issue trackers, and documentation system debates: line-wrapping code is considered harmful because it destroys syntactic structure (indent levels lose meaning, continuation lines are indistinguishable from new statements). Horizontal scroll, though ergonomically imperfect (horizontal scrolling is less natural than vertical), preserves code structure.

Hybrid approach supported by some practitioners: wrap on mobile (no mouse for horizontal scroll, limited viewport), scroll on desktop. No formal study compares comprehension of wrapped vs scrolled code in blog contexts.

Syntax highlighting contrast (moderate confidence)

WCAG 1.4.3 applies to all text, including code tokens. A common failure is low-contrast comment text (grey comments on slightly lighter grey background). Each token colour must achieve ≥4.5:1 against the code block background. Themes like GitHub Light, VS Code Light+, Dracula (dark), or Nord (dark) are designed with this in mind. Custom or minimal themes frequently fail for comment and string token contrast.

Code font size (low confidence)

No research establishes an evidence-based relative size for code vs prose. Practitioner convention suggests 90–95% of body text size (0.9em) because monospace fonts appear larger than proportional fonts at the same nominal size due to their wider character spacing. However, small code text is a documented readability problem in technical blogs, if 16px body text produces unreadably small inline code at 0.9em, the correct fix is increasing body text size or setting code at 1:1 with body text.

7. Secondary factors

Reading time estimates (moderate confidence)

Practitioner analysis (Ravi Kumar, UX discussions) supports displaying reading time on both the article index page and the post header. The rationale is behavioural: readers make commitment decisions before clicking; reading time provides the signal needed to decide. No formal A/B test result with published data was located to quantify the exact engagement improvement, making this practitioner-backed rather than empirically proven.

Emphasis and bold usage (moderate confidence)

Nielsen Norman Group research on scanning behaviour establishes that bold text functions as a visual anchor for F-pattern and layer-cake scanners. However, excessive bolding degrades this function: each bold span competes with others for attention. The practical implication: bold should mark critical terms or key phrases per paragraph, not be used decoratively. No controlled study establishes an optimal bold-per-paragraph ratio.

Alt text and figure treatment (high confidence)

WCAG SC 1.1.1 (Level A) requires non-text content have text alternatives. This is non-negotiable for accessibility compliance. For technical blogs, figure captions that explain why the image is relevant (not just what it shows) improve comprehension for readers in scanning mode who may not engage with the image itself.

Evidence gaps

Gap 1: Screen-specific empirical validation of line length The 45–75 character rule traces to print typography (Ruder 1967, Bringhurst 1992). Modern eye-tracking studies on screens support shorter measures but do not rigorously validate the specific 66-character optimum. What's needed: a controlled RCT comparing comprehension and reading speed at 45, 60, 75, and 90 CPL on screen specifically.

Gap 2: Quantified dark-mode font weight adjustment Multiple practitioners recommend "increase weight slightly" in dark mode but no source provides quantified effect size. The claim that increasing from 400→500 "improves readability by 15%" appeared in one source (Moldstud) without citation or methodology. Treat as aspirational practitioner claim, not evidence. No peer-reviewed study specifically examines dark-mode font weight.

Gap 3: Code block readability research No academic or rigorous usability research was found specifically examining code block presentation choices (font size, horizontal scroll vs wrap, syntax highlighting contrast impact on comprehension) in blog contexts. All guidance is practitioner convention from developer community discussions.

Gap 4: Optimal paragraph spacing for web The "line-height ÷ 1.5" formula is a single practitioner's heuristic (BetterWebType). No independent study validates this formula. WCAG SC 1.4.12 provides minimum spacing requirements but not optimal values.

Gap 5: TOC placement A/B test data NNGroup's TOC article cites "decades of research" on attention patterns but does not publish specific A/B test data on TOC placement and user task completion. Specific numbers on right-rail blindness for TOCs are inferred from general right-rail ad-blindness research.

Methodology

Search strategy: 10 searches across 7 sub-domains, biased toward authoritative sources (Baymard, NNGroup, WCAG/W3C, Butterick, academic databases). Pass 1 established the landscape; Pass 2 deep-dived Baymard line-length research, Butterick's practical guidance, NNGroup TOC study, WCAG contrast specifics, dark mode colour and font weight recommendations, and serif/sans-serif empirical literature.

Confidence distribution: 10 High, 14 Moderate, 4 Low confidence findings.

Key limitation: This research captures best evidence available as of July 2026. Several foundational typography recommendations (line length, line height) derive from mid-20th-century print authorities whose findings have been extended to screen contexts by practitioner convention rather than formal re-testing. The gap between "typography authority says X" and "RCT proves X on screens" is noted explicitly throughout.

Sources with CRAAP notes

High CRAAP (≥4.5): primary sources

Moderate CRAAP (3.5–4.4): supporting sources

Lower CRAAP (3.0–3.4): corroborating sources