Lorem Ipsum Markdown: Filler for READMEs and Docs

Plain-text filler pasted into a README arrives as one unbroken blob you then reflow by hand. Lorem Ipsum Markdown arrives as blocks — paragraphs separated by blank lines, - bullets, 1. items — ready for the renderer. This guide covers which blocks to fill, the punctuation that silently turns into syntax, and how the result behaves when it lands in Notion or a static-site build.

#TL;DR

• Generate filler as Markdown, not plain text — you get blocks, not a blob.
• Blank lines between blocks are what CommonMark uses to split paragraphs.
• Fill every block type a real doc uses: heading, list, table, code fence.
• Classic Latin is punctuation-safe; themed banks can emit stray syntax.
• Grep your build output for filler words in CI before every release.

#How to generate Lorem Ipsum in Markdown

The mechanics are trivial. What matters is picking the output format before you copy, because reflowing a wall of text into blocks afterwards is the slow part.

#Which output format to pick

Most filler generators default to plain text, which is correct for Figma and InDesign and wrong for anything that goes through a Markdown parser. In the iKit Lorem Ipsum Generator the format dropdown offers plain text, HTML, and Markdown; Markdown gives you paragraph blocks and - / 1. list items with the blank-line separation already in place.

That separation is not cosmetic. Under the CommonMark specification — currently version 0.31.2, dated 2024-01-28 — a paragraph is a run of non-blank lines, so two "paragraphs" without a blank line between them collapse into one:

Lorem ipsum dolor sit amet.
Consectetur adipiscing elit.

renders as a single paragraph with a space in the middle. Add the blank line and you get two. Every wrapped-plain-text paste hits this.

#How many paragraphs a README draft needs

Fewer than you think. Filler exists to reveal break points, not to fill the page. A practical baseline for a README:

• Two or three paragraphs at 40–60 words each — enough to wrap on a narrow viewport.
• One bulleted list of five items — reveals marker alignment and spacing.
• One deliberately long unbroken line — reveals horizontal scroll on mobile.
• One code fence — reveals monospace overflow, which is where real READMEs break.

Anything past that costs you later. When the real copy lands, every surplus filler paragraph shows up as a deleted block in the diff, and reviewers stop reading diffs that are 80% noise.

#Checking the length before you paste

Word counts drift once you paste into a template that adds its own boilerplate. Running the draft through the iKit Word Counter takes a second and tells you whether the section is at 40 words or 400 — useful when the design brief specifies a card body of "roughly two lines."

#What Markdown filler should exercise that paragraphs don't

A README is not a page of prose. It is a heading stack, a badge row, a fenced code block, a table, and a list — and each of those breaks differently. Filling only the paragraphs tests the least fragile part of the document.

#Fill every block type, not just body text

Tables are the usual failure. GitHub, GitLab, and most static-site themes render Markdown tables at natural width with no wrapping, so a four-column table of filler is where a docs page first breaks on a phone. Tables are not in core CommonMark at all — they arrive via the GitHub Flavored Markdown Spec, version 0.29-gfm dated 2019-04-06, which adds exactly five extensions on top of CommonMark: tables, task lists, strikethrough, extended autolinks, and a tag filter. If your renderer is CommonMark-only, your filler table renders as literal pipe characters, which is itself a useful thing to discover in a draft rather than in production.

#A drop-in README skeleton

Paste this, generate filler into each slot, and you have exercised every block a README typically contains:

# Project Name

Lorem ipsum dolor sit amet, consectetur
adipiscing elit sed do eiusmod tempor.

## Installation

```sh
npm install lorem-ipsum-dolor-sit-amet
```

## Usage

- Lorem ipsum dolor sit amet
- Consectetur adipiscing elit sed
- Do eiusmod tempor incididunt ut

| Option | Type | Default |
|---|---|---|
| lorem | string | ipsum |
| dolor | number | 42 |

Note the nested fence: if the outer document is itself inside a code block, you need four backticks outside and three inside. CommonMark allows fences of three or more backticks precisely so fences can nest.

#Preview it before you commit

Filler that looks fine in the editor can render wrong — a mis-indented list item silently becomes a code block. Pasting the draft into the iKit Markdown Editor gives you a GFM-accurate live preview without a commit and a CI round-trip.

#Why underscores and asterisks in filler text break Markdown

Classic Latin filler is punctuation-safe: letters, commas, periods. Themed word banks and hand-edited placeholder text are not, and the failures are quiet — nothing errors, the text just renders differently than you wrote it.

#The characters that turn into syntax

Under CommonMark, any ASCII punctuation character can be backslash-escaped, which is the fix for all of these:

Escape these when you mean them literally:
\* \_ \[ \] \# \` \| \~ \< \>

The behaviour of * and _ differs in a way worth knowing. CommonMark deliberately forbids intraword emphasis with underscores, so snake_case_name renders literally as written. Asterisks have no such restriction: foo*bar*baz really does italicise bar. If your filler mixes in identifier-like tokens — and placeholder API docs always do — underscores are safe and asterisks are not.

#Line-start characters are the sneakier problem

Inline punctuation is easy to spot. Block-level triggers are not, because they depend on what happens to fall at the start of a line after your text wraps:

• A line beginning with # becomes a heading.
• A line beginning with 1. or - becomes a list item.
• A line indented four spaces becomes an indented code block.
• Under GFM's extended autolinks, a bare www.example.com becomes a link.

The four-space rule catches people constantly. Paste filler into an already-indented block — inside a list item, inside a YAML literal — and a stray extra level of indentation converts the whole paragraph to preformatted text.

#Normalising filler that came from somewhere else

Filler harvested from a design file or a spreadsheet often arrives with inconsistent casing or Title Case headings you now want as sentence case. The iKit Case Converter handles the bulk transform in one paste rather than a find-and-replace per line.

#Does Lorem Ipsum Markdown import into Notion cleanly?

Mostly yes, with specific gaps that matter if you draft in Markdown and review in Notion.

#What Notion's Markdown importer keeps and drops

Per Notion's import documentation, the Text & Markdown importer takes .md and .txt files and preserves plain text, standard Markdown, headings, lists, and code blocks. What it explicitly does not import: anchor links, and advanced or nonstandard Markdown extensions. So the heading stack and the bullets in your filler survive; a table-of-contents block built from #section anchors does not, and you rebuild that navigation in Notion afterwards.

Two operational limits are worth writing down before you plan a migration:

#Importing a folder of drafts as a ZIP

Notion's docs are specific that you should zip the folder, not a selection of loose files, to preserve structure — and that hidden files such as .DS_Store can cause the whole import to fail. If you are moving a docs tree full of placeholder drafts, clean the directory first:

find . -name '.DS_Store' -delete
zip -r drafts.zip ./drafts

A ZIP import also brings CSV and XLSX in as databases rather than pages, which is worth knowing if your filler tree contains sample data files alongside the Markdown.

#Front matter: filler for Hugo, Jekyll, and Astro drafts

A Markdown file destined for a static site is not just body text — the build fails or silently mis-sorts if the metadata block is wrong. Filler drafts need valid front matter too.

#YAML, TOML, and JSON delimiters

Hugo accepts three serialisation formats and identifies them by delimiter, according to the Hugo front matter documentation: --- for YAML, +++ for TOML, and a bare { … } object for JSON. Jekyll and Astro use YAML only. A stub that works everywhere YAML is accepted:

---
title: "Lorem ipsum dolor sit amet"
date: 2026-09-08
draft: true
tags: ["lorem", "ipsum", "placeholder"]
---

Keep draft: true on every filler file. It is the cheapest possible guard against a placeholder page reaching a sitemap.

#Never let filler reach production

The draft flag protects static-site builds. It does nothing for a filler string hard-coded into a component, a seed fixture, or a translation file. The durable fix is a build-time grep on the word bank, wired into CI:

# fail the build if filler reaches dist/
grep -rniE 'lorem ipsum|dolor sit amet' dist/ \
  && exit 1 || exit 0

Add the distinctive tokens from whichever themed bank you use — pancetta, kombucha, shiver me — to the same alternation. Themed filler is easier to grep for than Latin precisely because its vocabulary never overlaps with real product copy.

#Diffing the draft against the real copy

When real content finally replaces the placeholder, the review question is "did anything other than the prose change?" A structural diff answers it faster than reading both files. Paste both versions into the iKit Diff Checker and the surviving filler shows up as unchanged lines — which is exactly the signal you want before merging.

#References

• CommonMark Spec — version 0.31.2 (2024-01-28); used for paragraph/blank-line rules, backslash escapes, fenced-code nesting, and the intraword-underscore restriction.
• GitHub Flavored Markdown Spec — version 0.29-gfm (2019-04-06); used for the list of five extensions over CommonMark, including tables and extended autolinks.
• Import data into Notion — used for what the Text & Markdown importer keeps and drops, file-size caps, the ~120-files-per-12-hours rate limit, and ZIP guidance.
• Front matter — Hugo — used for the three supported front-matter formats and their delimiters.

#Related on iKit

• Start with the fundamentals of placeholder text before formatting it — how much filler a mockup actually needs, and the point at which more text stops telling you anything new.
• Do the same job in HTML instead of Markdown — Emmet abbreviations, which tags should hold filler, and the lang="zxx" detail that keeps screen readers from mispronouncing it.
• Know when filler is actively misleading your review — the case for swapping Latin for real or deliberately awkward copy before sign-off, which is the step after everything above.
• Swap the Latin word bank for a themed one — when Bacon, Cat or Hipster Ipsum gets a stakeholder to read the layout, plus the punctuation caveats that matter doubly in Markdown.
• Trace where the Latin in your README came from — Cicero, the 1500s typesetters, and why lorem is a truncated word rather than a real one.