How Many Words of Lorem Ipsum Does a Mockup Need?

Most people paste whatever their generator hands them — usually 30 words — into every text block and move on. That number is an editor default, not a design decision. How many words of lorem ipsum a mockup actually needs depends on one thing: how wide the container is and how many lines you want it to fill. Here is the arithmetic, plus per-block targets you can copy straight into a design file.

#TL;DR

• Words needed ≈ (characters per line × lines wanted) ÷ 6.4.
• Latin filler averages 6.4 characters per word including the space.
• Card body: 18–25 words. Article paragraph: 40–60. List item: 6–12.
• The 30-word default comes from Emmet's lorem abbreviation, not research.
• Fill one pass at 2× your target to find overflow before launch does.

#How many words of lorem ipsum should a mockup have?

There is no single number, but there is a single formula. Everything below is derived from it.

#The formula: words = (chars per line × lines) ÷ 6.4

I counted the canonical 69-word Lorem ipsum dolor sit amet passage: 445 characters including spaces, which works out to 6.45 characters per word. Round it to 6.4. English body copy is slightly tighter — closer to 5.8–6.1 — so Latin filler runs about 5–10% long per word. That is a useful bias: your mockup errs toward the harder case.

So if you know how many characters fit on a line, and how many lines you want the block to occupy, you know the word count:

words = (chars_per_line × target_lines) / 6.4

A 48-character line, three lines deep: (48 × 3) / 6.4 ≈ 22 words.

#The short answer, by block type

These are the counts I reach for. They assume a typical 45–70 character measure; narrow the container and you narrow the count.

Note what is missing: headings and buttons. Those need character counts, not word counts, and they should never be Latin at all — more on that below.

#Why every editor defaults to 30 words

The number is inherited. Emmet — the abbreviation engine behind VS Code's built-in HTML expansion, plus Sublime, WebStorm and most of the rest — defines lorem as a generator, and its documentation states that expanding it produces a 30-word dummy text split into a few sentences. Every editor that shipped Emmet inherited 30 as the default, and every designer who learned filler text from an editor inherited it too.

Thirty words is about two and a half lines at a 66-character measure. That happens to look fine in a card, which is why nobody ever questioned it. It is a convenient number, not a correct one.

#How to work out filler length from your container width

The formula needs chars_per_line. There are two ways to get it: estimate, or measure.

#Measure the container in ch, not pixels

CSS has a unit built for exactly this. Per MDN's CSS length reference, the ch unit equals the advance width of the 0 glyph in the current font. Set a max width in ch and the container is self-describing:

.prose p {
  max-width: 66ch;   /* ≈ 66 characters per line */
  line-height: 1.6;
}

At 66ch, a three-line paragraph is (66 × 3) / 6.4 ≈ 31 words. Now the 30-word default finally has a justification — but only for that one measure.

If you are working in pixels, the rough conversion is that an average lowercase character occupies about half the font size. A 384 px container at 16 px type gives roughly 48 characters per line. Or just ask the browser:

const el = document.querySelector('.prose p');
const fontSize = parseFloat(getComputedStyle(el).fontSize);
const chars = Math.round(el.clientWidth / (fontSize * 0.5));
console.log(chars, 'chars/line →',
  Math.round(chars * 3 / 6.4), 'words for 3 lines');

#Where the 45–75 character measure comes from

The range is Robert Bringhurst's, restated for the web in The Elements of Typographic Style Applied to the Web, which records that anything from 45 to 75 characters is a satisfactory line length for single-column text, with 66 characters widely regarded as ideal. Multi-column work sits lower, around 40–50.

Accessibility guidance puts a hard ceiling on top of that aesthetic range. Per W3C's Understanding SC 1.4.8: Visual Presentation (Level AAA), lines should not exceed 80 characters or glyphs — 40 for CJK, because CJK glyphs are roughly twice as wide at equivalent readability.

That last row matters if you are designing for Chinese, Japanese or Korean: Latin filler is the wrong shape entirely, and a word counter that handles CJK correctly will tell you why your character counts look wrong.

#Worked example: a 384 px card

Say you are filling a Tailwind w-96 card, 384 px wide with 16 px type and 24 px of horizontal padding on each side:

1. Usable width: 384 − 48 = 336 px
2. Characters per line: 336 ÷ 8 = 42
3. Target: three lines → 42 × 3 = 126 characters
4. Words: 126 ÷ 6.4 ≈ 20 words

Generate 20 words, not 30. Then generate 40 and check the card again — that is the pass that finds the bug.

#Why too much lorem ipsum breaks a design later

The instinct is to under-fill, because short filler makes a layout look clean in a review. That instinct is backwards.

#Overflow that only shows up with real copy

Nielsen Norman Group's write-up on layout versus content catalogues the failure modes: content too big for its allotted space, elements that do not grow gracefully, and early placeholder assumptions hardening into arbitrary constraints — "all summaries must be one paragraph having 5 lines." A mockup filled with 20 tidy words never surfaces any of that. Fill it with 60 once and the card tells you immediately whether it grows, clips, or pushes its neighbour off the grid.

#Line clamps hide the problem rather than solving it

-webkit-line-clamp is the standard fix for variable-length copy, and it works — but it means overflow is now invisible. You are not seeing the layout fail; you are seeing it truncate:

.card__summary {
  display: -webkit-box;
  -webkit-line-clamp: 3;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

Before you clamp, mock the block at 2× your target word count with the clamp off. If losing that content changes what the card means, a clamp is the wrong answer and the card needs a different shape.

#Filler length becomes an accidental spec

This is the quiet one. A stakeholder sees a card with 20 words in it and internalises 20 words as the brief. Six weeks later a writer submits 45 and gets told the copy is too long — not because it is, but because a generator default became a requirement. Say the number out loud in the review: this is 20 words of filler; real summaries will run 30 to 50.

#How many words should headings and buttons have?

Different rules. These blocks are short enough that a single extra word changes the layout, and they are the blocks users actually read first.

#Headlines: count characters, not words

A headline lives or dies on whether it wraps. Count characters against the container and test three cases: shortest plausible, longest plausible, and one word longer than longest. If your H1 is a two-line design, find the character count where it becomes three lines and write to stay under it.

#Buttons and labels: one or two words, then test three

Latin filler in a button is actively misleading — "Consectetur" is 11 characters and tells you nothing about whether "Add to basket" fits. Write real candidate labels. Then write the German translation, which will be about 30% longer, and check again. Filler text passes every i18n test it should fail.

#Never use Latin for microcopy

Error messages, empty states, helper text, confirmation dialogs — these are the places where placeholder text does the most damage, because they are the places where the exact wording is the design. Use draft English, however rough. Save the Latin for blocks where only the shape matters.

#Generating exactly the word count you need

Once you know the number, hitting it should take two seconds.

#Emmet: lorem20, lorem100, p*4>lorem

In any editor with Emmet, append the count directly to the abbreviation. lorem100 produces 100 words. The generator also works inside repeaters, so p*4>lorem40 fills four paragraphs with 40 words each — different text in each one, which is what you want when you are checking how a stack of paragraphs behaves:

<!-- type this, press Tab -->
ul.menu>lorem8.item*5

<!-- expands to five list items, 8 words each -->

#A browser generator when you need a precise count

Editor abbreviations only help inside an editor. For a Figma frame, a CMS field or a slide, generate the exact count in the iKit Lorem Ipsum Generator, which runs entirely in the browser — nothing you type is uploaded. Paste the output into a live Markdown preview if you want to see how the block breaks before it reaches the design file.

#Test the long tail: 2× and 0.5× your target

Three passes, in this order:

• 0.5× target — does the block collapse, or does the card go ragged next to its siblings?
• 1× target — the realistic case, the one you screenshot for the review.
• 2× target — the overflow case. This is the pass that earns its keep.

Most teams only ever do the middle one. The other two cost thirty seconds each and catch the bugs that otherwise ship.

#References

• “Lorem Ipsum” generator — Emmet Documentation — source of the 30-word default and the lorem100 / p*4>lorem syntax.
• 2.1.2 Choose a comfortable measure — The Elements of Typographic Style Applied to the Web — Bringhurst's 45–75 character measure and the 66-character ideal.
• Understanding Success Criterion 1.4.8: Visual Presentation — W3C WAI — the 80-character (40 CJK) line-width provision at Level AAA.
• Which Comes First? Layout or Content? — Nielsen Norman Group — scaling failures and placeholder-driven constraints in templates.
• CSS length — MDN Web Docs — definition of the ch unit used for container-width math.

#Related on iKit

• Start with the full picture of what filler text is for — the practical overview of Lorem Ipsum for designers and developers, of which word count is one chapter.
• Understand why filler survived sixty years of design tooling — the case for Latin placeholder text, and the specific points where it costs you.
• See exactly what a full text block hides in a design review — when filler misleads, and which blocks need real copy instead.
• Test layouts against German and CJK before you localise — why Latin filler passes overflow tests that real translations fail.
• Learn how the generator picks those words in the first place — the word bank, sentence windows and punctuation rules behind any word count you request.
• Generate markup-ready filler instead of pasting plain text — the Emmet abbreviations and tag choices for filling HTML blocks.
• Fill a README or docs page without breaking the renderer — which Markdown blocks to fill, and the characters that quietly become syntax.
• Swap Latin for themed filler when the tone matters — Bacon, Cat and Hipster Ipsum, and the word-length differences they introduce.
• Trace the passage back past the 1500s printer myth — Cicero, the 1914 Loeb edition and Letraset, for the 69 words everyone quotes.