Generate mock data from a schema
Fixture rows that look real — unicode names, boundary dates, nulls only where the schema allows them, never in a required field.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your prompt
Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.
Why this prompt works
- →Explicitly requiring unicode names and boundary dates targets exactly the edge cases synthetic data usually skips, which is where a real system's validation or encoding bugs hide.
- →Forbidding a null in a required field stops the model from generating a fixture set that would fail the very schema it was built from the moment you loaded it.
- →Asking about unclear nullability instead of guessing prevents the dataset from silently encoding a wrong assumption about your schema that later gets mistaken for real data.
Part by part
- look real, not obviously synthetic
- Rules out the default output of every name being John Smith and every email being user1@example.com, which exercises none of the cases real data does.
- Include a few edge-case rows on purpose
- The instruction that makes this test data rather than filler. Uniform rows pass every validation and prove nothing.
- a name with an apostrophe, accent, or non-Latin script
- Three specific encoding traps. Apostrophes break naive escaping, accents break byte-length assumptions, and non-Latin scripts break anything assuming ASCII.
- Never put a null in a field the schema marks required
- The one hard constraint. Edge-case data that violates the schema tests your importer rather than your application.
- ask instead of guessing
- Nullability is the field a schema most often leaves implicit, and guessing it wrong produces a dataset that is subtly invalid throughout.
Common mistakes
Generate 100 rows of test data for this table.Produces uniform, well-formed rows with ASCII names and no nulls. Every one passes validation, so the dataset confirms the happy path and tests nothing that will actually break in production.
Generate realistic test data.Realistic is read as plausible-looking rather than awkward, so you get believable names and no boundary values. The edge cases have to be requested explicitly or they do not appear.
Generate test data with lots of edge cases.Without the required-field constraint, nulls appear where the schema forbids them and the import fails before the application sees anything. The data has to be invalid in interesting ways, not broken ones.
Questions
Why insist on non-ASCII names?
Because they find real bugs. An apostrophe breaks naive string escaping, an accent breaks code that confuses character count with byte length, and a non-Latin script breaks anything assuming a single-byte encoding — all of which pass testing with ASCII-only data.
Is generated data safe to use in staging?
Safer than a copy of production, which is the alternative it usually replaces. It carries no real personal information, which means no obligation to protect it and no incident if the environment is exposed.
How many rows are worth generating?
Enough to exercise pagination and sorting, so a hundred or so for interface work. For performance testing the shape matters more than the count — realistic distributions and cardinality, not just volume.
Should I use a faker library instead?
For bulk volume, yes — it is faster, repeatable with a seed, and free. This is better when you want a small set with deliberately chosen edge cases, which is fiddly to express in a faker configuration.