Lorem Ipsum and Placeholder Content: Design Without Fake Meaning
How to use Lorem Ipsum, fake user data, and Markdown fixtures effectively — when placeholder text helps layouts, when it hides product problems, and how to generate it locally.
How to count words and characters the way products and platforms do — limits, diffs, Markdown pitfalls, and a practical editing workflow for developers who ship copy.
By codefunc
Character limits are product constraints as much as writing advice. Meta titles truncate in SERPs, tweets and Discord embeds cut mid-sentence, SMS segments bill per length, and form validators reject strings that looked fine in Figma. Developers who treat copy as "just strings" discover counting rules only after QA files a bug. A reliable count — and a clear diff when copy changes — saves rounds of back-and-forth with design and marketing.
Bottom line: Know whether your limit is characters, graphemes, or bytes; count in the same way the platform validates; and verify edits with a diff. Use a Word & Character Counter, Text Diff, and Markdown Preview in the browser so draft copy never needs to leave your machine.
Frontend engineers, technical writers, and PMs who enforce length limits in UI, generate meta tags, or review PR copy. If you have ever wondered why length in JavaScript disagreed with a designer's Google Doc count, this guide explains the gap.
| Metric | What it measures | Where it matters |
|---|---|---|
| Words | Tokens split on whitespace (locale-dependent) | Essays, docs, reading-time estimates |
| Characters (all) | Every code unit / character including spaces | Many "character limit" UIs |
| Characters (no spaces) | Letters and punctuation only | Some academic or contest rules |
| Graphemes | User-perceived characters (emoji, accents) | True UX length for display |
| UTF-8 bytes | Storage and some SMS / binary protocols | Databases, Twilio segment math |
JavaScript "e\u0301".length is 2 (base letter + combining acute), while users see one grapheme (é). Many emoji are also multiple UTF-16 code units. If your validator uses string.length, you are not always counting what humans see. For emoji-heavy or accented input, use a grapheme splitter or Intl.Segmenter where available.
Approximate ceilings change; always verify against current docs. Patterns stay stable:
| Surface | Typical constraint | Count type |
|---|---|---|
HTML title / SERP display |
~50–60 characters visible | Characters (display) |
| Meta description | ~150–160 characters visible | Characters |
| Open Graph titles | Truncation varies by network | Characters |
| SMS (GSM) | 160 chars per segment | Septets / encoding-dependent |
| SMS (UCS-2) | 70 chars per segment | When non-GSM characters appear |
| Many App Store subtitles | Hard character max | Characters |
Database VARCHAR(n) |
n characters or bytes by collation |
Check DB docs |
Ship validators that match the backend rule, and show the same count in the UI. Dual sources of truth (maxLength on an input vs Zod schema vs DB) are a classic off-by-one factory.
For product strings:
Paste into a Word & Character Counter during review, then lock the limit in code. Do not rely on eyeballing against a screenshot of a SERP.
Word counts feed "N min read" labels. Pick a fixed WPM assumption (often 200–250 for UI copy pages), document it, and compute from words — not characters. Changing the counter definition later shifts every badge.
Markdown sources fool raw counts:
**, #, []()) inflates characters if you count the source&) are multiple characters before decodeWorkflow:
When legal or marketing returns a revised paragraph, do not re-read the whole page hoping to spot changes. Paste old and new into Text Diff:
Diff-first review is especially useful in PRs where copy lives next to code — reviewers can approve string changes with the same rigor as logic changes.
Length problems often mean the sentence is doing too many jobs. Patterns that help:
Counting without rewriting just reports the fire. Use the number to justify a cut.
German, Finnish, and French UI strings often grow 20–40% versus English. If you only count English:
Budget slack in the layout (or use flexible containers) and run character counts on localized strings before release. Word counters that assume space-separated words undercount languages without spaces.
Unreleased product names, pricing, and legal drafts should not go to random online counters. Prefer client-side tools: paste, count, diff, preview — with no upload of the text to codefunc servers. Clear the tab on shared machines when the copy is sensitive.
Use these codefunc tools alongside this guide:
Treat counting rules as part of the API contract for strings. Align UI, validator, and database definitions; remember JavaScript length is not always what users see; and separate Markdown source counts from rendered text counts. When copy changes, diff it. For everyday work, keep drafts local with Word & Character Counter, Text Diff, and Markdown Preview — no data needs to leave your machine.
How to use Lorem Ipsum, fake user data, and Markdown fixtures effectively — when placeholder text helps layouts, when it hides product problems, and how to generate it locally.
A practical GFM workflow for developers — preview Markdown safely, convert HTML when needed, and understand the caveats of Markdown ↔ HTML round-trips.
Ship the right favicon and apple-touch-icon sizes, wire Web App Manifest icons, set theme-color, and avoid the common gaps that leave tabs and home screens looking broken.
Find a developer tool