Privacy-First Lorem Ipsum: Why Filler Text Needs No Server

Open DevTools on most Lorem Ipsum sites, click "Generate", and you will watch a network request fire. Five paragraphs of 2,000-year-old Latin just made a round trip to someone else's machine. Privacy-first Lorem Ipsum treats that request as what it is — unnecessary. The word bank is a few kilobytes, the sentence model is trivial, and the whole job fits comfortably inside a browser tab.

#TL;DR

• Lorem Ipsum needs a ~200-word Latin dictionary and a sentence model — both fit in the browser.
• Server-side generators add latency, rate limits, outage risk, and request logs for zero benefit.
• Test any tool: open DevTools, go offline, click generate. Working offline proves it is client-side.
• The filler text is not the secret; the metadata and whatever you paste alongside it are.
• A client-side generator is roughly 40 lines of JavaScript, not a service.

#Why does a Lorem Ipsum generator need a server at all?

Short answer: it does not. The longer answer explains why so many of them still have one.

#What a server-side generator actually sends

A typical hosted generator serialises your options and posts them to an API:

POST /api/generate HTTP/1.1
Host: example-ipsum.test
Content-Type: application/json

{"units":"paragraphs","count":5,"startWithLorem":true}

The response comes back as JSON, the page injects it into a textarea, and you copy it. Nothing in that exchange required a server. The payload going out is your configuration; the payload coming back is deterministic pseudo-Latin. The server's only real contribution is the round trip.

What travels alongside the body is the part people forget: source IP, timestamp, Referer, User-Agent, and any cookies the domain has set. That tuple is ordinary web-server log material, and it exists whether or not the operator ever looks at it.

#The three costs: latency, availability, and logs

Every architectural choice buys something. A server-side Lorem Ipsum generator buys nothing and charges three ways.

Latency. A local generation is sub-millisecond. A round trip to a CDN-backed origin is 100–500 ms on a decent connection, and considerably worse on hotel Wi-Fi or a train. If you are iterating on a layout and regenerating filler twenty times, that adds up to dead time you feel.

Availability. Server-backed tools go down, get rate-limited, or return 429 when a Hacker News thread points at them. A client-side tool that you loaded ten minutes ago still works when the origin is unreachable, because there is nothing left to reach.

Logs. Filler text is not confidential. But the request record is real data about you, and it accumulates. The W3C's Privacy Principles frame this as data minimisation: actors should restrict what they transfer to what is actually needed to achieve the user's goal. For "give me five paragraphs of Latin", the amount needed is zero bytes.

#What the request looks like in DevTools

Open the Network panel, filter to Fetch/XHR, and click the generate button. One of two things happens. Either a request appears — in which case the text was assembled elsewhere — or nothing appears, and the work happened in your tab. There is no ambiguity and no marketing claim involved. You are reading the browser's own record.

#Is Lorem Ipsum generated on the server or in the browser?

This is the question worth asking of any "free online tool", not just filler-text generators. The answer is always observable.

#How to tell if an online tool is really client-side

Three checks, in increasing order of confidence:

• Network panel test. Open DevTools → Network, clear the log, then use the tool. Zero new requests on interaction means local computation.
• Offline test. Load the page, then set throttling to Offline in the Network panel (or turn off Wi-Fi) and use the tool again. If it still works, the logic is in the bundle. Chrome's Network features reference documents both the throttling control and log preservation across reloads.
• Source test. View the page source or the loaded JavaScript. A word bank of Latin tokens sitting in a const array is hard to fake.

The offline test is the one to trust. A tool can defer its network call, batch it, or fire it on copy rather than on generate. It cannot fake working with the network disconnected.

#The offline test that takes five seconds

Do it in this order, because loading the page first is the point:

1. Load the generator with a normal connection.
2. Open DevTools, switch the Network throttling dropdown to Offline.
3. Change the paragraph count and click generate.

If new text appears, the generator is browser-only. If you get a spinner, an empty box, or a console TypeError: Failed to fetch, it was never local. iKit's Lorem Ipsum generator passes this test, because the word list and the sentence assembler ship with the page.

#What a Content-Security-Policy tells you

A site that intends to stay local can say so at the header level. The connect-src directive controls which origins a page may open fetch, XHR, WebSocket, or EventSource connections to. Set it to 'none' and the browser itself blocks outbound data channels:

Content-Security-Policy:
  default-src 'self';
  connect-src 'none';
  img-src 'self' data:;

This is a stronger signal than a privacy policy, because it is enforced by the user agent rather than promised by the operator. Check it in the Network panel: click the document request, read the Response Headers.

#How to generate Lorem Ipsum in JavaScript without a library

Understanding how small the job is makes the server-side version harder to justify.

#The word bank and the sentence model

The canonical approach is the one lipsum.com has used for decades: a dictionary of over 200 Latin words combined with a handful of model sentence structures, so output never repeats fixed chunks. The vocabulary comes from sections 1.10.32 and 1.10.33 of Cicero's de Finibus Bonorum et Malorum, written in 45 BC, and the "standard passage" everyone recognises dates to Letraset dry-transfer sheets in 1966.

A minimal implementation is about forty lines:

const WORDS = [
  "lorem", "ipsum", "dolor", "sit", "amet",
  "consectetur", "adipiscing", "elit", "sed",
  "eiusmod", "tempor", "incididunt", "labore",
  "dolore", "magna", "aliqua", "veniam", "quis",
];

function randInt(max) {
  const buf = new Uint32Array(1);
  crypto.getRandomValues(buf);
  return buf[0] % max;
}

function sentence(min = 6, max = 14) {
  const len = min + randInt(max - min + 1);
  const out = [];
  for (let i = 0; i < len; i++) {
    out.push(WORDS[randInt(WORDS.length)]);
  }
  const s = out.join(" ");
  return s[0].toUpperCase() + s.slice(1) + ".";
}

function paragraph(count = 5) {
  return Array.from({ length: count }, () => sentence())
    .join(" ");
}

Swap in the full 200-word list and add a few sentence templates — clause, comma, clause — and the output is indistinguishable from any hosted generator. Total shipped weight: under 3 KB gzipped.

#Math.random vs crypto.getRandomValues for filler text

The snippet above uses crypto.getRandomValues(), which fills a typed array with cryptographically strong values. Per MDN, implementations use a PRNG seeded with sufficient entropy rather than a true RNG, and the method throws QuotaExceededError above 65,536 bytes per call.

For Lorem Ipsum, none of that matters. Math.random() produces perfectly good filler. The buf[0] % WORDS.length in the snippet even introduces modulo bias, which is a real defect when you are generating secrets and a rounding error when you are generating the word "dolor". The distinction matters for a password generator, where predictable output is the whole failure mode. It does not make a filler-text tool private — running locally does that.

#When to reach for Faker instead

Lorem Ipsum is the wrong tool when you need structured fake data: names, addresses, dates, IBANs, product SKUs. That is Faker's territory, and it runs in Node or in the browser without a service either. Reach for a Lorem Ipsum generator when you want neutral grey text that does not compete with the layout, and for structured records when you are seeding a database or building API fixtures.

#What privacy actually means for filler text

Let's be precise, because overclaiming here is how privacy marketing loses credibility.

#Filler text isn't secret — the context around it is

Nobody is exfiltrating Cicero. The realistic exposures are two:

1. Request metadata. IP, timestamp, referrer, and user agent, logged at the origin and often at a CDN in front of it. The referrer in particular can leak the URL of an internal staging site if the generator is opened from a link there.
2. What you paste in. Generators with a "replace this text" or word-count input get fed real content constantly — draft marketing copy, a client's product name, an unreleased feature heading — because the fastest way to size a block of filler is to paste the real thing next to it.

The second one is the underrated risk, and it applies to every text tool on the web. If you are measuring a draft before replacing it with filler, do it in a word counter that runs locally, then generate the filler locally too.

#Data minimisation as a default, not a feature

The framing that holds up is architectural rather than promissory. A tool that never opens a connection cannot log, cannot breach, cannot change its retention policy after an acquisition, and cannot be compelled to hand over records it does not have. Those are properties of the design, not commitments in a document.

This is also why "we don't store your data" is a weaker claim than "the data never left your device". The first is a policy; the second is a fact you can verify in thirty seconds with the Network panel.

#Ad tech and consent banners are a separate question

Being client-side does not automatically mean no third-party scripts. A generator can compute text locally and still load an ad network, an analytics tag, and a consent management platform — all of which make their own requests and set their own identifiers. The two properties are independent, and worth checking separately in the Network panel: filter to All rather than Fetch/XHR and look at which third-party domains appear on page load.

#Server-side vs browser-only: which should you use?

#Feature comparison

#When a server-side generator is fine

There are legitimate cases. If you need Lorem Ipsum inside a CI pipeline, a server-rendered CMS, or a scheduled content job, an API endpoint is the natural integration point — a browser tool cannot help you there. Libraries that run on your own infrastructure are better still, since you keep the round trip inside your network.

The case that does not hold up is the interactive one: a human sitting in a browser, clicking a button, waiting for text that could have been produced before the click finished registering.

#A browser-only workflow that fits your design tools

The practical sequence for mockups and drafts:

• Generate paragraphs at the length you need in a local Lorem Ipsum generator, using the paragraph/word/character mode that matches your constraint.
• Check the block against your real content budget in a word and character counter before committing to a layout.
• If you are filling a README or docs page, generate Markdown-shaped filler and preview it in a Markdown editor so heading levels and list spacing are represented honestly.

Three tools, three tabs, zero uploads. That is the whole workflow.

#References

• Lorem Ipsum - All the facts - Lipsum generator — origin of the standard passage (Letraset, 1966), the Cicero sections 1.10.32/1.10.33, and the 200-plus-word dictionary approach.
• W3C Privacy Principles — data minimisation principle used to frame why an unnecessary request is a design defect.
• Crypto: getRandomValues() method - MDN — typed-array behaviour, PRNG seeding note, and the 65,536-byte quota cited in the code section.
• CSP: connect-src - MDN — which connection types the directive governs, used for the header example.
• Network features reference - Chrome DevTools — offline throttling, request filtering, and preserve-log, used for the verification steps.
• faker-js/faker on GitHub — checked for the structured-fake-data comparison.

#Related on iKit

• Start with the practical overview of filler text in 2026 — the general guide this article's privacy argument sits inside.
• Read how a Lorem Ipsum generator actually assembles text — the word bank and sentence model described here, in full detail.
• Trace the passage back to Cicero and the 1966 Letraset sheets — the historical background behind the standard chunk.
• Work out how many words of filler a mockup actually needs — sizing filler to a layout without pasting real copy into a tool.
• See when filler text starts misleading stakeholders — the argument for swapping in real content earlier than feels comfortable.
• Understand why designers still reach for Latin in 2026 — the case for neutral text that does not compete with layout.
• Generate markup-ready filler for HTML prototypes — paragraph, list, and heading output that drops straight into a template.
• Fill a README or docs page with Markdown-shaped filler — the same local workflow applied to documentation drafts.
• Use filler text to catch i18n overflow before translation — stress-testing layouts with longer strings, entirely in the browser.
• Swap Latin for Bacon, Cat, or Hipster Ipsum when it helps — when themed filler communicates better than pseudo-Latin.