Typography Testing with Placeholder Text: A Designer's Guide

Placeholder text is the right tool for typography work because typography is about texture — the grey density a block of prose makes on a page — and texture is exactly what Lorem Ipsum reproduces well and meaning-bearing text gets in the way of.

But it reproduces that texture imperfectly, and knowing precisely where it lies to you is what separates useful testing from false confidence. Start there, because it changes how you use everything else.

What Lorem Ipsum won't show you

It contains no k, w, y, z, or j. Classical Latin barely uses these letters, and the standard passage has none of them. If you are evaluating a typeface, you will not see five of its glyphs — including y, whose descender interacts with line height, and w, which is often a font's widest and most awkward lowercase letter. Always type a pangram alongside your placeholder block before committing to a face.

It has no diacritics. No accented characters at all. Accents extend above the cap height, and tight line height clips them. Your layout can look perfect in Latin and break the moment someone's name contains an é or ü. Paste a few accented characters in deliberately.

It has no numerals. Figure design varies enormously — lining vs old-style, tabular vs proportional — and affects tables, prices, and dates more than any body-text decision. Placeholder text tells you nothing here.

Its word lengths are Latin, not English. Around six characters on average, versus roughly five for English prose. Blocks read slightly denser than real copy will. Useful to know when a layout looks marginally tight.

Its punctuation is monotonous. Mostly commas and periods. No quotation marks, apostrophes, em dashes, parentheses, or colons — the characters most likely to be badly kerned or to reveal that your quotes are rendering as dumb straight marks.

None of this means don't use it. It means use it for the thing it's good at — texture, rhythm, and flow — and use targeted strings for glyph-level checks.

Measure: the decision that matters most

Comfortable line length for body text runs about 50–75 characters, including spaces. Below roughly 45, the eye makes return sweeps too often and reading feels choppy. Above about 85, it loses its place finding the next line.

This is the single most common failure in otherwise competent designs, and it's invisible until you have a block long enough to sweep several times. A hundred words is about the minimum — try 100 words from the generator.

The reliable fix is to set measure in ch units rather than pixels, since ch is relative to the font's 0 glyph width and therefore tracks the actual character count:

.prose {
  max-inline-size: 66ch; /* ~66 characters regardless of font size */
}

To count characters per line in a live layout, resize until a full line ends naturally and count it, or check in devtools. Don't estimate by eye — people consistently guess low.

Line height, and why one value is wrong

The common advice — 1.5 for body, 1.2 for headings — is a starting point that hides a relationship: optimal line height scales inversely with font size and directly with measure.

Large text needs proportionally less leading. A 48px heading at 1.5 looks unglued; at 1.1 it reads as a unit. Small text needs more. Wide measures need more leading, because the eye needs help finding the line start on the return sweep.

h1 { font-size: 3rem;    line-height: 1.1; }
h2 { font-size: 2rem;    line-height: 1.2; }
p  { font-size: 1.0625rem; line-height: 1.6; }
.caption { font-size: 0.875rem; line-height: 1.7; }

Test with real paragraph volume, not one line. Line height is only visible in aggregate — five paragraphs give you four inter-paragraph junctions plus dozens of internal line gaps to judge. Five paragraphs is a reasonable default for this.

Rivers, runts, orphans, and widows

These terms get muddled constantly, including in a lot of design writing. The distinctions:

Rivers — vertical channels of white space that align by accident across several lines, pulling the eye downward. Almost exclusively a justified-text problem. If you use text-align: justify on the web without hyphenation, you will get them, because the browser can only stretch word spaces. Either enable hyphens: auto or don't justify.

Runts — a single short word alone on a paragraph's last line. Ugly but minor.

Orphans — the first line of a paragraph stranded alone at the bottom of a page or column, with the rest of the paragraph continuing overleaf.

Widows — the last line of a paragraph stranded alone at the top of the next page or column.

The mnemonic: an orphan is left behind at the bottom; a widow goes on ahead to the top. Both are page-break phenomena, which is why they matter most in print, PDFs, and multi-column layouts — and why you need enough placeholder text to actually cross a break before you can see them. CSS has direct control:

p { orphans: 3; widows: 3; } /* Minimum lines either side of a break */

For runts and awkward headline breaks, modern CSS is genuinely better than manual fixes:

h1, h2, h3 { text-wrap: balance; } /* Evens out lines in short blocks */
p          { text-wrap: pretty; }  /* Avoids runts on the last line */

balance is intended for headings and short blocks; pretty for body copy. Both degrade harmlessly in browsers that don't support them.

Font pairing: compare x-heights, not names

When testing two faces together, the property that determines whether they sit comfortably is x-height relative to cap height, not classification or era. Two fonts with similar x-height ratios will feel related even across categories; a mismatch reads as an accident regardless of how well the names go together.

Set both at the same nominal size in a placeholder block and look at the lowercase. If one looks noticeably smaller, you'll need to compensate — either with explicit sizing or with font-size-adjust, which normalises perceived size across faces:

body { font-family: Georgia, serif; font-size-adjust: 0.5; }

This also matters for fallback fonts. If your webfont fails or is still loading, a mismatched fallback causes a visible reflow. Testing with a placeholder block while blocking the webfont in devtools shows you exactly how bad the shift will be.

Testing hierarchy in context, not in a specimen

A type scale that looks coherent in a specimen — h1 through h6 stacked in a column — routinely falls apart in a real document, because real documents put headings next to body copy in awkward sequences.

The case that breaks naive margin rules most often is an h2 followed immediately by an h3 with no paragraph between. If your heading margins are defined only as margin-block-start, the two collide or space oddly.

Generate structured placeholder rather than flat prose so the hierarchy actually appears — Lorem Ipsum Markdown produces headings, lists, blockquotes, and code blocks. If your stylesheet has rules for an element, your test content should contain that element. Otherwise the first real article becomes your test case, in production.

Dark mode changes perceived weight

The same text at the same weight looks heavier on a dark background than on a light one, because light bleeds optically into the surrounding dark. A body weight tuned on white often looks bloated in dark mode.

The usual correction is to drop a step in dark mode:

@media (prefers-color-scheme: dark) {
  body { font-weight: 350; } /* From 400 - variable fonts make this smooth */
}

You can only judge this with a full block of text at reading size. A heading tells you nothing.

Responsive: test the reflow, not the breakpoints

Checking three fixed widths misses most problems, which occur between breakpoints. Drag the viewport slowly and watch for measure exceeding 75 characters just before a breakpoint fires, headings that go from two lines to four, and text that collides with a floated element mid-range.

Fluid type reduces the need for breakpoint-specific sizes, but clamp its bounds so it can't become unreadable at extremes:

h1 { font-size: clamp(1.75rem, 5vw, 3.5rem); }

Note that using vw alone in font-size can break user zoom, which is an accessibility failure. The clamp() form with a rem minimum avoids the worst of it.

A working checklist

Before signing off on typography:

• Measure lands in the 50–75 character range at every viewport width
• Line height tested with at least five paragraphs, not one
• h2-immediately-followed-by-h3 doesn't collapse
• Accented characters don't clip against the line above
• Numerals checked in tables — tabular figures where columns must align
• Quotes render as curly, not straight; apostrophes correct
• Fallback font tested with the webfont blocked
• Dark mode weight checked at full paragraph length
• Long enough content to cross a page break, if print or PDF matters
• Contrast verified against WCAG at the final colours, not approximations

Conclusion

Placeholder text is the right instrument for the aggregate properties of type — texture, rhythm, measure, hierarchy under load — and the wrong instrument for glyph-level detail, because the standard passage is missing five letters of the alphabet, every diacritic, all numerals, and most punctuation.

Use it in volume for the first category. Use deliberate strings — a pangram, a few accented names, a table of figures, a paragraph with real quotation marks — for the second. Most typographic embarrassments come from testing only the first and assuming the second followed.