| # | Preview | Sentences | Words | Chars | Copy |
|---|---|---|---|---|---|
| {{ p.index }} | {{ p.preview }} | {{ p.sentenceCount }} | {{ p.wordCount }} | {{ p.charCount }} |
| Word | Count | Share | Copy |
|---|---|---|---|
| {{ row.word }} | {{ row.count }} | {{ row.share }} |
Placeholder text is a practical design tool, not a writing goal. Teams use it when they need real-looking blocks of language to test layout, spacing, rhythm, and export flows before final copy is ready. This generator turns that need into controllable text so a mockup or draft can be judged on structure instead of waiting for finished editorial work.
The package is useful because it does more than repeat a stock Latin paragraph. It can aim at paragraph count, sentence count, or total word budget, then shape the result with sentence-length ranges, tone, case handling, wrap style, topic hints, custom vocabulary, punctuation variation, and a Latin-to-modern ratio. That combination makes it suitable for wireframes, documentation samples, product copy rehearsals, and content QA where volume alone is not enough.
A common use case is a designer who wants a landing page to feel technical rather than generic. Another is a writer who needs bulleted placeholder text for a draft knowledge base article. In both cases the output needs to occupy realistic space, carry a believable cadence, and stay stable long enough to compare layout changes without rewriting the filler from scratch.
The optional seed matters for that stability. When the same seed and settings are reused, the generator recreates the same pseudo-random sequence and therefore the same text pattern. That helps when screenshots, bug reports, or review decks need controlled repetition rather than a fresh variation on every pass.
The important limit is meaning. This package can make scaffold text feel more on-brand, more technical, or more conversational, but it does not turn placeholder language into reviewed content. The result is best read as a layout and workflow aid, not as a substitute for domain expertise, factual editing, or final copy approval.
The first decision is what should stay fixed. If your concern is visual block count, use paragraph mode. If you want a specific narrative rhythm across cards, callouts, or alerts, sentence mode is usually the better anchor. If you are stress-testing a copy budget for a fixed panel or report section, word mode gives the most direct control.
Sentence and word ranges do most of the realism work. Narrow ranges produce more even blocks, which is helpful when the layout needs calm, predictable placeholder text. Wider ranges create a rougher editorial rhythm with more variation from one sentence to the next. That can be useful when you want to see how an interface behaves with less uniform content density.
Tone, topic hints, and custom vocabulary shape the character of the result in different ways. Tone adds a built-in word pool such as classic, friendly, playful, or technical. Topic hints are lighter guidance, while custom vocabulary has the strongest pull because those words are given a larger selection share. If you want filler that echoes product language, documentation jargon, or campaign terms, custom vocabulary is the control that most clearly changes the output.
Wrap style matters at handoff. Plain text is best when you will paste into notes or another editor. HTML paragraphs are helpful when you need escaped paragraph tags. Markdown paragraphs fit README or documentation drafting. Bulleted list mode is the simplest option when you want short stacked items instead of prose blocks.
Use the summary and companion views together. The headline tells you how much text was produced. The paragraph table shows whether one block is disproportionately heavy. The vocabulary view reveals repetition, the sentence-length chart reveals pacing, and the JSON view gives you a structured record of both settings and output. That combination is what makes the package more useful than a single text box full of filler.
All generation happens in the browser. The package builds paragraphs from local form state and does not depend on a tool-specific backend. The active settings include output focus, amount, sentence and word bounds, tone, case style, wrap style, topic text, custom vocabulary, punctuation randomness, Latin ratio, the classic opener toggle, and the optional seed.
The engine assembles text paragraph by paragraph. In paragraph mode it creates the requested number of blocks. In sentence mode it keeps creating paragraph-sized chunks until the requested sentence total has been exhausted. In word mode it keeps adding blocks until the word budget is reached, but it stops after forty-eight generated blocks so the output cannot grow without bound from a bad combination of settings.
Sentence construction is weighted rather than purely uniform. When topic words are present, the earliest selection band prefers them. Custom vocabulary gets the next strongest chance. Tone-specific words come after that. The remaining picks come from either the Latin pool or the modern English pool, with the fallback split controlled by the Latin ratio slider. That is why the result can drift from classic lorem ipsum toward technical or contemporary filler without abandoning the underlying placeholder role.
Randomness affects punctuation and sentence feel more than high-level structure. When the value is low, endings stay close to plain full stops. As it rises, the package becomes more willing to add commas inside longer sentences and to end lines with question marks, exclamation points, or semicolons. The result is more stylistic variety, not better semantics.
The generator also enforces hard caps. Sentences per paragraph are limited to 24, words per sentence are limited to 36, and invalid combinations reset the output instead of generating a partial result. Reading time is estimated from the finished word count at 200 words per minute, which is a practical pacing signal rather than a readability metric.
| Rule or control | Package behavior | Why it matters |
|---|---|---|
output_type |
Chooses paragraph count, sentence count, or total word budget as the stopping rule. | Keeps the output aligned with layout planning, pacing checks, or copy-budget testing. |
| Classic opener toggle | Can force the first generated sentence to the familiar lorem ipsum opening before normal weighted generation takes over. | Lets the text begin with a recognisable filler pattern when that convention is useful. |
| Weighted word selection | Prefers topic words first, then custom vocabulary, then tone words, then a Latin or English fallback pool. | Explains why custom terms and topic language can dominate the result more strongly than base filler words. |
randomness |
Raises the chance of commas and non-period sentence endings. | Changes rhythm and visual variety without changing the overall paragraph-building model. |
latin_ratio |
Biases fallback picks toward the Latin list or the English list. | Lets the result feel more traditional or more modern. |
| Generation caps | Limits sentences per paragraph to 24, words per sentence to 36, and word-budget mode to at most 48 blocks. | Prevents runaway output and keeps export views readable. |
| Seed | Creates a deterministic pseudo-random sequence when supplied. | Makes layouts, screenshots, and repeat tests reproducible. |
| View | What it contains | Exports or copies |
|---|---|---|
| Main text output | The generated text in plain, HTML, Markdown, or list form. | Clipboard copy and TXT download. |
| Paragraph table | Each paragraph with sentence, word, and character counts. | CSV copy, CSV download, DOCX export, single-row copy. |
| Vocabulary table | Word counts and percentage share across the generated corpus. | CSV copy, CSV download, DOCX export, single-word copy. |
| Sentence length chart | One bar per generated sentence, measured in words. | PNG, WebP, JPEG, and CSV export. |
| JSON view | The active settings, summary counts, and paragraph objects. | Clipboard copy and JSON download. |
The summary headline is best read as a layout and pacing signal. Paragraph, sentence, and word counts show output size, while the reading-time estimate gives only a rough sense of density. It does not measure readability, comprehension, or editorial quality.
The paragraph table is where unevenness becomes obvious. If one paragraph is much longer than the rest, a mockup may look stable in a screenshot but still behave awkwardly once real copy arrives. Character count is especially useful when narrow cards or fixed-height panels are involved.
The vocabulary table helps you judge repetition. If custom terms dominate the top rows, that means the weighting is working, not necessarily that the generator is malfunctioning. It also shows when a subject-specific placeholder draft has become too repetitive to stand in convincingly for final prose.
The chart should be read as rhythm rather than difficulty. Tight clustering suggests uniform placeholder copy. A wider spread creates a more editorial look. If the bars vary too sharply, the layout you are testing may feel more dramatic than the finished content is likely to be.
A product team needs stable placeholder copy for several rounds of design review. They choose paragraph mode, set a seed, pick the technical tone, and add custom terms such as schema, latency, and rollout. The resulting text stays consistent from one screenshot set to the next, so layout changes remain easy to compare.
A writer wants filler that feels closer to a knowledge base article than to generic lorem ipsum. They choose Markdown wrap style, widen the sentence range slightly, and add topic words that reflect the product area. The output still behaves like placeholder text, but it occupies space in a way that better mirrors eventual documentation.
A developer suspects a grid of summary cards will clip once real marketing copy arrives. They increase sentence variation, raise randomness, and inspect the paragraph table together with the sentence-length chart. If one or two paragraphs become substantially heavier, the layout problem appears before final copy is written.
No. The seed only makes the package's pseudo-random sequence repeatable for the same settings.
Because custom vocabulary is intentionally favored ahead of the base filler pools. That weighting is what makes the result feel more tailored to the subject area you entered.
No. The package escapes paragraph text before wrapping it in paragraph tags, so inserted terms are treated as text rather than executable markup.
The vocabulary table export is usually the fastest way to review repetition, while the JSON export is best when you also want to preserve the exact settings that produced it.