Random Names for Demos and Screenshots

The leak is rarely a database dump. It is almost always a picture. A support engineer screenshots a ticket to explain a workflow; the ticket has a real name and a real email in it. A designer takes a real record into Figma for realism, and the mockup is exported into a public blog post. A staging environment is refreshed from production because that is the fastest way to get realistic data, and every screenshot taken there afterwards carries real customer records.

Under the GDPR, a name paired with anything that identifies a person is personal data, and publishing it is processing that needs a lawful basis. You do not need to resolve that question at all if the environment contains no real people — which is the practical argument for generated demo data over redaction. Prevention is cheaper than a redaction policy that has to be applied perfectly, in every frame, forever.

Blurring deserves specific scepticism. Redaction applied as an image layer can be reversed if the file is exported wrong; a name blurred in the table is often still legible in the tooltip, the tab title, the URL bar or the notification that fired mid-capture; and pixelation of short text is famously recoverable. Where the underlying data is fictional, none of that matters.

The difference between a demo that looks designed and one that looks generated is consistency. If the invoice screen shows Ruby Hudson, the email preview should show Ruby Hudson, and so should the mobile screenshot taken six weeks later when the button moves. Regenerating random people per screen produces a demo that quietly contradicts itself, and reviewers notice even when they cannot say why.

Fix the cast once by pulling it from the API with a fixed seed — the same seed and parameters always return the same records — and keep the response in your repository as the demo fixture. Every environment, every re-shoot and every locale build then draws from the same file. When you need a second cast for a different market, change the country and the seed rather than the whole approach.

The same fixture is what makes localized screenshots practical. A German screenshot with English names in it looks like a translation nobody finished; regenerating the same seeded fixture with a different country gives you a matching cast for each market, with names that belong in the interface around them.

A few practical rules survive contact with real review cycles. Do not use the names of colleagues, competitors, executives or public figures, even as a joke — that joke ships, and it outlives the person who made it. Do not use a prospect's own staff names to personalise a demo unless they asked for it; it reads as surveillance rather than as effort. And check the initials and the combination, because a name that is inoffensive in one market can be a slur, a brand or a punchline in another.

Avatars are worth thinking about for the same reason. This generator never attaches a photograph to a persona: it draws a deterministic monogram or a plain silhouette from the seed and the initials. Stock photography of a real model, or a face from a generated-faces service, both put an image of a person next to invented account details — and a real face beside a fake name is a much stronger claim than a coloured circle with two letters in it.

Each persona is produced by the same seeded engine the rest of the site runs on. A seed string is hashed to a 32-bit integer, that seeds an isolated random generator, and the builders draw in a fixed order, so a given seed always yields the same person — the property that lets a demo fixture be committed and replayed rather than re-created by hand.

Names are drawn from the locale pools of the country you pick: given names and surnames as independent draws, so no combination is copied from a register of real people. The avatar is not an image lookup either; it is an SVG monogram computed from the seed and the initials, which is why it renders identically on the server and in the browser and why no photograph of a real person is ever involved.

The supporting fields around the name are built to be inert on purpose, because a demo screenshot usually shows more than a name. Email addresses use the reserved example.com, example.net and example.org domains, which publish a null MX record — a formal declaration that they accept no mail — so an address in a screenshot cannot reach anyone's inbox. United States phone numbers come from the 555-0100 to 555-0199 block that the North American numbering plan reserves for fiction. Addresses pair a real city with a postal code genuinely valid for it, while the street name and house number are both invented.

What that leaves you to check is the framing rather than the data: a screenshot of fictional people can still leak a real internal hostname, an API key in a URL, or a colleague's name in a browser tab. The generator handles the record; the capture is still yours to review.