Inside Mock Data Lab: How It Turns a Schema Into Realistic Test Data

You're building the frontend before the backend exists — the table, the cards, the empty states — and you need data to put in them. So you do what everyone does: hand-type three rows of { name: "Test User", email: "test@test.com" }, and your UI looks perfect against data that looks nothing like reality. Then real data arrives, and the names are too long, the nulls weren't handled, and a profile with an empty bio breaks the layout. The fixtures lied. Mock Data Lab exists to make them stop lying — to turn the shape of your data into a realistic, messy, sizable sample you can actually build against. This is a look inside how it does that, entirely in your browser.

The Real Problem Isn't Fake Data — It's Realistic Data

Generating random junk is easy; generating data that exercises your UI the way production will is the actual job. A field full of "asdf" tells you nothing about how your card handles a real 32-character full name. A uniform list of tidy records never reveals that you forgot the null state. Good test data has to do two things at once: look plausible enough to validate your design, and be varied enough to surface the edge cases before your users do. Mock Data Lab is built around exactly that pair of goals — and it starts by understanding the shape you're working with.

Three Ways to Describe Your Shape

Most data generators make you build your schema by hand in their UI, field by field. Mock Data Lab inverts that: you almost always already have the shape written down somewhere, so it reads whichever form you've got. Three inputs, one internal schema:

Whichever you paste, the parser normalizes it into a single internal representation — so everything downstream works the same way no matter how you described your data. That's the small architectural decision that makes the rest of the tool simple: three front doors, one room.

A quick sample of what that inference looks like in practice:

Field name	What it generates
full_name, first_name	A real human name — “Alexandra Fitzgerald”
email	A plausible address
created_at, updated_at	An ISO 8601 datetime
price, amount	A decimal number
id	A sequential integer
status, role	A sensible enum-like value
tags (array)	A short list of string values

Generating Data That Behaves Like the Real Thing

Field detection gets each value right; a few deliberate choices get the whole dataset right:

• Nested structure, handled in place. A field that's an object gets its sub-fields filled; an array like tags: string[] becomes a short list of generated values. The records come out shaped like your real ones, not flattened.
• Reproducible when you want it. Provide an optional seed and the same seed produces the same dataset every time — so a teammate, a test run, or a screenshot can be regenerated exactly. Leave it blank and every run is fresh.
• Edge cases on purpose. This is the feature that earns its keep. You can opt into nulls, empty strings, boundary values (a max-int here, a 500-character string there), and even unicode and emoji — the exact inputs that quietly break a layout. Test your UI against the ugly data, not just the tidy data, before production does it for you.

One honest scoping note, because “realistic” has a limit worth stating: Mock Data Lab generates each record independently. It fills nested objects and arrays beautifully within a record, but it isn't a relational engine — it won't stitch foreign keys across tables or guarantee that order #42 points at a customer that exists in another set. For building and stress-testing a UI against one realistic collection at a time, that's exactly the right scope. For a full relational fixture graph, you'd reach for something heavier.

Three Ways Out: JSON, CSV, SQL

Generated data is only useful where it lands, so there are three export formats, each aimed at a different destination:

Why It Runs Entirely in Your Browser

Like the rest of the Developer Labs tools, Mock Data Lab does all of this client-side — the generation runs in your browser, nothing is uploaded, and there's no account to create. That's a privacy decision as much as a convenience one: the schema you paste might be an unreleased internal model, and it never leaves your machine. The trade-off is a sensible ceiling — up to 1,000 rows per run — which is plenty to fill a table, exercise pagination, and find the layout bugs, without pretending to be a bulk data-warehouse tool. It does one job, locally, well.