Placeholder text done right
Design · 6 min read
Placeholder text is one of those small habits nobody teaches properly. You copy some lorem ipsum from a template, drop it into a layout, and move on. Most of the time that is fine. Sometimes it quietly wrecks your design review, because fake Latin behaves nothing like the words your users will actually read.
What lorem ipsum is actually good for
Lorem ipsum exists to fill space without distracting anyone with meaning. When you are testing a grid, checking line height, or showing a client how a two-column layout breathes, that neutrality is exactly what you want. Nobody reads the words, so nobody comments on the words.
It is also fast. A tool like a lorem ipsum generator gives you a paragraph or a page in seconds, in whatever length you need. For early wireframes where the point is proportion and rhythm rather than content, this is the right level of effort.
The trap is treating this convenience as a default for every stage of a project. Lorem ipsum is a wireframe tool, not a content strategy. Used past that point, it stops helping and starts hiding problems.
The ways placeholder text lies to you
Real sentences vary wildly in length. Lorem ipsum tends to produce suspiciously even paragraphs, which flatters your layout. A card component that looks balanced with three lines of filler can break completely when a real product description runs to one line or eight.
It also hides truncation problems. Buttons, tags and navigation items often need to handle short real-world labels like 'Settings' or long ones like 'Manage notification preferences', and lorem ipsum rarely produces either extreme. You only discover the overflow bug in production.
Perhaps the biggest lie is emotional. Latin-looking text feels calm and orderly, so a layout reviewed with lorem ipsum often looks more finished than it is. Swap in real copy and suddenly headlines wrap awkwardly, buttons feel cramped, and the whole thing looks rushed.
Greeking versus genuinely fake content
Greeking is the general term for any placeholder that mimics the shape of text without carrying meaning, whether that is grey bars, blurred text, or classic lorem ipsum. It is useful in very early, low-fidelity sketches where you want stakeholders to focus on layout and hierarchy, not read anything at all.
Once you move past sketches, greeking starts to cost you information. Grey bars cannot tell you if a heading is too long for its column. Real or realistic words can. The more finished the design gets, the less appropriate pure greeking becomes.
Better alternatives once you are past the sketch stage
Written-to-length dummy copy is a good middle ground: short sentences that sound like plausible product text, sized to match what real content will roughly be. It takes a bit more effort than pasting lorem ipsum, but it exposes truncation and wrapping issues much earlier.
Even better, when you can get it, is a small sample of real or realistic content from the client or from a similar existing product. Real names, real prices, real headline lengths. This is what will eventually go live, so it is the most honest test of your layout.
For data-heavy interfaces, generate content with the right statistical shape: some long entries, some short ones, some missing values, some edge cases like a name with no last name or a price with four digits. Boring, evenly-sized fake data is the enemy of a robust UI.
How much placeholder text to actually use
Match the density of your placeholder to the real content, not to what looks tidy. If the finished page will have a two-sentence bio, do not fill the space with four paragraphs of lorem ipsum just because it looks nicely full. You will build a layout that only works when it is over-stuffed with words.
It helps to prepare at least three variants for any component that holds variable text: a minimum-length version, a typical version, and a stress-test version that is noticeably longer than you expect in practice. Reviewing all three takes a few extra minutes and catches most layout bugs before launch.
Placeholder text in forms and inputs
Inside form fields, placeholder text has a different job: it is a hint, not a label, and it disappears the moment someone starts typing. Never use it as the only label for a field, because anyone who taps in and then looks away loses the context entirely.
Keep input placeholders short, concrete and example-shaped, such as 'jane@company.com' rather than a vague instruction like 'enter your email here'. This also happens to double as a length check: if your example email overflows the field, so will most real ones.
Handing off files with placeholder text
When you send a design file to a developer, mark clearly which text is genuinely final copy and which is still placeholder. Nothing wastes more time than a developer carefully pixel-matching a lorem ipsum paragraph that was never meant to ship.
A simple convention works well: a coloured layer, a comment, or a naming pattern like 'TBC - copy' on any text layer that is not final. It costs seconds to add and saves a confusing round of questions later.
Localisation and placeholder text
If your product will be translated, test your layout with a language that runs noticeably longer than English, such as German, or one that reads right to left, such as Arabic. Lorem ipsum, being pseudo-Latin, never warns you about this, and it is one of the most common sources of late-stage layout bugs in international products.
A quick trick is to pad your English placeholder copy by roughly thirty percent to roughly simulate the expansion that many European languages introduce during translation. It is rough, but far better than assuming every language matches English length.
A practical placeholder workflow
Start with pure greeking or lorem ipsum for the earliest, roughest sketches, where the only question is layout structure. Move to written-to-length dummy copy as soon as you are testing real components. Swap in genuine content, or at least a realistic sample, before anything goes near a client review or user test.
Keep a lorem ipsum generator bookmarked for the early stage, since it is genuinely the fastest way to fill a wireframe, but treat reaching for it later in a project as a small warning sign that content strategy has fallen behind design.
Common questions
- Is lorem ipsum bad practice?
- No, it is a legitimate tool for early-stage layout work where meaning would only distract. It becomes a problem when it is still in your mockups at the point you are testing real interactions, because it hides truncation, wrapping and tone issues that real content would reveal.
- What should I use instead of lorem ipsum for a client presentation?
- Use realistic, written-to-length copy that matches the tone and rough length of what will actually ship, or better still, a real sample from the client. Clients react to what they see, and Latin filler can make a rough layout look more polished than it is.
- How long should placeholder text be?
- As close to the real content's expected length as possible, and ideally tested at three lengths: a short case, a typical case, and a deliberately long stress case. This reveals how your component behaves at the edges, not just under ideal conditions.
- Should input placeholder text replace form labels?
- No. Placeholder text inside an input disappears once someone starts typing, so it cannot serve as the only label. Always pair it with a persistent label, and use the placeholder purely as a short example of the expected format.
- How do I flag unfinished copy to developers?
- Use a clear, consistent marker, such as a specific text colour, a layer name suffix, or a comment thread on the text layer, to show which strings are placeholder and which are final. Agree the convention with your team once and reuse it on every project.