Common Mistakes Designers Make with Placeholder Text

Most placeholder mistakes have the same root: the placeholder made the design look better than it will look with real content, and nobody noticed until real content arrived. Each mistake below is a different way that happens, and each comes with a check you can run in a few minutes.

1. Designing to the comfortable average

A card designed around a tidy 40-word block of Lorem Ipsum works for tidy 40-word blocks. Real content isn't tidy. One product name is two words and the next is eleven. One user has no bio and the next has pasted a CV. The average case is the one case that was never at risk.

The check: for every text slot, generate three versions: the shortest plausible content (often empty), the typical case, and the longest plausible case. The long case should be longer than you think is reasonable, because someone will exceed it. If the layout only works for the middle one, it doesn't work.

2. Sizing with themed placeholder text

Hipster, cupcake and bacon ipsum are English, so it's natural to assume they size like English. They don't. When we measured them, 100 words of hipster ipsum rendered 21% wider than 100 words of real English prose. Cupcake was 14% wider and bacon 12%. Standard Lorem Ipsum, the Latin, was within 3–4%.

A card that looks well filled with hipster ipsum will look sparse with real copy. A headline that just fits in cupcake ipsum has room to spare in English.

The check: use themed text for tone in a presentation, and standard Lorem Ipsum (or real copy) for any decision about how much fits.

3. Finalising line height in Latin

Latin's letters aren't distributed like English. The standard Lorem Ipsum text has a quarter to a third fewer tall-stroke letters (b, d, f, h, k, l, t) than English prose, and almost no h, the letter behind th, sh and wh. A paragraph of it looks smoother and lower on the page than the same paragraph in English.

That makes tight leading look better than it is. The collisions between one line's ascenders and the previous line's descenders show up less in Latin than they will in production.

The check: before signing off on line height, swap one paragraph for real English (any real paragraph will do) and compare at the actual size.

4. Evaluating a typeface in Lorem Ipsum alone

The canonical Lorem Ipsum paragraph never uses j, k, w, y or z. It has no numerals, no accented letters, and no punctuation beyond commas and full stops. So a typeface specimen set in it hides the w (often the most awkward lowercase glyph), the descenders of y and j, every figure, every diacritic, and the quotation marks and apostrophes most likely to show poor kerning.

The check: put a pangram, a line of figures ("0123456789 £$€ 3/4 12:45"), a few accented names ("Zoë Łukasz Ångström Nguyễn") and a sentence with real quotation marks next to the placeholder block. Typography testing with placeholder text has the full list.

5. Latin in the accessibility layer

Latin in a paragraph is harmless: everyone sees the same meaningless block. Latin in an alt attribute, an aria-label, a form label or a link is a different kind of problem. It breaks the page for screen reader users specifically, and it's invisible in every visual review, so it tends to ship.

The check: search the markup, not the screen:

git grep -niE "(alt|aria-label|aria-description|title|placeholder)=\"[^\"]*(lorem|ipsum|dolor)" -- src

And write missing alt text as an explicit to-do (alt="[TODO: describe the chart]") rather than filling it with Latin. More in accessibility and placeholder text.

6. Placeholder in anything a user has to act on

Buttons, form labels, validation messages, empty states and navigation are content people depend on to know what to do next. When they're Latin in a mockup, the design review can't catch the real problem, which is usually that the label is ambiguous or the error message doesn't explain the fix. And if the mockup goes into user testing, the test measures whether people can guess.

The check: write every interactive label and message for real, even in a low-fidelity mockup. Draft wording is fine; Latin isn't.

7. Letting it ship

Placeholder text reaching production is common enough that platforms police it. Apple's App Review Guidelines (section 2.1a) tell developers that placeholder text should be scrubbed before an app is submitted. On the web nobody checks for you.

Latin at least announces itself when it slips through. Readable placeholder is worse: a stray paragraph of corporate ipsum reads like weak marketing copy, so nobody reports it.

The check: make it a build failure, not a review item. A grep in CI that skips fixtures and stories:

git grep -niE "lorem ipsum|dolor sit amet|consectetur adipiscing" -- \
  'src/**' 'content/**' ':!**/*.test.*' ':!**/*.stories.*' ':!**/fixtures/**' \
  && { echo "Placeholder text found"; exit 1; } || true

If you use themed placeholder, add its signature words to the pattern too: cupcake ipsum, bacon ipsum, I'm baby, synergy.

Also worth watching

Presenting placeholder without framing it. Stakeholders approve what they see. If a mockup's headlines are Lorem Ipsum, say out loud which parts are unwritten, and what length and purpose the real copy will have. Otherwise "approved" quietly includes assumptions nobody made. See presenting designs with placeholder text.

Using it to test translation. Latin runs about English length and uses no accents. It can't show you German compounds, text expansion in short UI strings, or right-to-left layout. Internationalization and placeholder text covers what to use instead.

Identical blocks everywhere. The same paragraph in every card makes a component library look more robust than it is. Vary lengths deliberately.

The short version

None of these need better placeholder text. They need testing that looks at the cases the placeholder hides. When you do need text to test with, the generator produces any length in six styles.