Why Lorem Ipsum Lies to Your CMS Layouts (And What to Use Instead)

You paste five paragraphs of lorem ipsum into your CMS, the layout looks perfect, and you ship. Then the client adds an H2, a three-column table, and an image with a caption — and the whole thing falls apart. Structured dummy content is not a nice-to-have. It is the only honest way to test a content-driven layout.

The Problem With Plain Lorem Ipsum

Standard lorem ipsum generators produce one thing: walls of identical paragraphs. They are useful for checking that text renders, but they test almost nothing about how your layout handles real editorial content.

Real CMS content is structured. A WordPress post or a WYSIWYG editor field will eventually contain a mix of headings at multiple levels, ordered and unordered lists, inline bold and italic formatting, blockquotes, images with captions, tables, and code blocks. Each of these elements has different box model implications. Each one can expose spacing bugs, typography hierarchy issues, image overflow problems, or table responsiveness failures that plain lorem ipsum will never reveal.

The gap between "lorem ipsum looks fine" and "client content breaks everything" is not a client problem. It is a testing problem. You tested with content that does not resemble what real editors produce.

What Realistic Dummy Content Needs to Cover

Before reaching for any generator, it is worth being specific about what a senior frontend engineer actually needs to test:

Typography hierarchy — H1 through H6 appearing in natural sequence inside a post body. Your CSS resets and heading scale will behave differently depending on nesting depth. You need to see them together, not just in isolation in a component story.

List spacing — Unordered and ordered lists, with configurable item counts, sitting inside paragraphs. The margin between a paragraph and a following list is one of the most commonly broken spacing values in CMS themes.

Inline formatting — Bold, italic, and hyperlinked text mixed into running copy. These are the cases that expose problems in your line-height, link underline offset, and font-weight rendering.

Media and rich blocks — Placeholder images at different sizes with captions, blockquotes with attribution, definition lists, tables, and code blocks. These are the elements editors reach for in long-form content and the elements most likely to overflow, collapse, or lose their styling in a fresh theme or component library.

Generating all of this manually is tedious. Generating it by hand for every new CMS integration or theme build is the kind of work that gets skipped under deadline pressure, which is exactly when the client demo goes wrong.

DummyTxt: A Configurator Approach

dummytxt.com approaches this differently from a standard lorem ipsum generator. Rather than dumping a fixed block of Latin text, it gives you a configurator where you specify exactly what your dummy content should contain before generating it.

The configuration options map directly to the content elements described above:

Paragraph count — set via a slider, so you can generate a realistic long-form article or a short card excerpt depending on what you are testing
Heading levels — H1 through H6, inserted naturally throughout the content rather than stacked at the top
List type and item count — unordered or ordered, with a configurable number of items per list
Inline elements — toggle bold, italic, and hyperlinks on or off depending on whether your styles handle them
Rich content blocks — blockquotes, tables, definition lists, code blocks, and horizontal rules, each independently toggleable

The output comes in two formats: raw HTML and plain text. The HTML output is the more useful one for CMS and WYSIWYG work — you can paste it directly into a WordPress block editor, a Contentful rich text field, a Sanity portable text block, or any WYSIWYG editor and immediately see how the layout handles it.

The whole thing runs client-side with no login required. Generate, configure, copy, paste.

Where This Fits in a CMS or WYSIWYG Workflow

WordPress theme development is the clearest use case. When building or customising a theme, the default approach is to install the theme unit test data — a large XML import of pre-defined sample content. This works, but it is fixed. DummyTxt lets you generate targeted content for the specific edge case you are testing right now: a post with only an H3 and a table, or a page with five images and no headings, or a long-form article with every element turned on.

Paste the raw HTML output directly into the WordPress Classic Editor or use the Custom HTML block in the Block Editor. You have a realistic content page in under 30 seconds.

Headless CMS testing is the second workflow where this pays off. When building a Next.js front-end against a Contentful, Sanity, or Prismic back-end, you need rich text content in your CMS fields to verify that your serialisers and renderers handle every element type correctly. Generating dummy content with dummytxt and pasting it into your rich text field is faster than writing test articles by hand and more thorough than using a single paragraph of lorem ipsum.

Design system component testing is less obvious but equally valuable. If you are building a <PostBody> or <ArticleContent> component in a Next.js design system, you want to render it with content that represents the full range of what editors will produce. DummyTxt gives you an HTML string you can use directly as a fixture. This is more representative than anything you would write by hand and avoids the false confidence of a component story that only ever renders three clean paragraphs.

// Using dummytxt HTML output as a component test fixture
// Paste generated HTML into a constant and verify rendering
const richTextFixture = `
  <h2>Section heading</h2>
  <p>Paragraph with <strong>bold</strong> and <em>italic</em> and <a href="#">a link</a>.</p>
  <ul>
    <li>List item one</li>
    <li>List item two</li>
    <li>List item three</li>
  </ul>
  <blockquote>A blockquote pulled from the body copy.</blockquote>
  <table>
    <thead><tr><th>Column A</th><th>Column B</th></tr></thead>
    <tbody><tr><td>Value 1</td><td>Value 2</td></tr></tbody>
  </table>
`;

// Render in your test or Storybook story
export const RichContent: Story = {
  args: {
    content: richTextFixture,
  },
};

WYSIWYG editor testing across frameworks — TinyMCE, Quill, CKEditor, Trix — benefits from the same approach. When evaluating whether an editor's output is compatible with your existing styles, you need output that exercises every element the editor can produce, not just paragraphs.

The Practical Workflow

The pattern that works well:

Before starting a new CMS theme or content component, open dummytxt.com in a tab
Enable every content type you expect editors to use on this project
Generate the HTML output and save it as a fixture file in your project
Use it as your default test content for that component or template throughout development

The fixture file approach is worth emphasising. Copy-pasting from a generator every time you need test content leads to using the same minimal content repeatedly. A saved fixture file with rich, varied content becomes the permanent baseline for your visual regression tests, your Storybook stories, and your CMS demo content. It makes the "it looked fine in development" failure mode much less likely.

Key Takeaways

Plain lorem ipsum only tests paragraph rendering — it does not test the typography hierarchy, list spacing, image layout, or table behaviour that real editorial content will expose
Configure your dummy content to match what editors on your specific project will actually produce, not a generic sample
Use the raw HTML output from dummytxt.com as a fixture file, not one-time paste-and-discard content
For WordPress and headless CMS work, realistic structured dummy content is a first-class testing asset — treat it like any other fixture in your test suite

Sources & References

dummytxt.com — Browser-based configurable dummy content generator with HTML and plain text export
WordPress Theme Unit Test — Official WordPress test data for theme development
Contentful Rich Text — Contentful documentation on rich text field types and serialisation