Security & devFree
Free dummy JSON generator. Create sample JSON arrays of people or products for mocking APIs and UI prototypes.
Last updated 14 October 2026
Names are assembled from a fixed pool of ten first names and ten surnames, so there are exactly a hundred combinations available and they are picked at random with replacement. Ask for a hundred people and you will not get a hundred different names. Measured on one run of a hundred rows: 63 distinct names, with the most common appearing five times.
That is fine for filling a table on a design mock-up and wrong for anything that treats the name as unique. If you are seeding a database column with a unique constraint on a person’s name, or testing a de-duplication routine, this data will not do what you want, and it will fail in a way that looks like your code is broken.
The id and email fields are not random, and that is the fix for the common case. Measured over a hundred rows, every email is exactly user<n>@example.com with n running 1 upwards, and the ids run 1 upwards too. So if you need a unique field, use the email or the id, not the name. The product type behaves the same way: measured, a hundred products gave a hundred distinct SKUs, running SKU-1000 to SKU-1099.
The example.com domain is not an accident either. RFC 2606 reserves it specifically so that it can be used in documentation and test data without anyone’s real mailbox being hit, which is what makes this data safe to put into a system that might actually try to send mail.
The randomness comes straight from the browser with no seed you can set, so you cannot reproduce a run. Measured: the same request made twice in a row produced different data both times.
That matters for tests. A fixture that changes on every generation makes a failure impossible to reproduce and makes a committed snapshot pointless. If you are using this for a test, generate once and save the output as a file in your project, rather than regenerating. Treat this as a one-off generator, not as a library you call.
It also means the data is not suitable where you need statistical properties you can rely on. The in-stock flag is meant to be true about seven times in ten; measured on one run of a hundred products it came out at 62. That is ordinary variation for a hundred coin flips, and it is the reason not to assert an exact count in a test built on this.
Whatever you ask for, you get between one and a hundred rows, and nothing on screen says so. Measured:
So this is not a bulk data generator. If you need a thousand rows, generate a hundred and repeat the array, remembering to renumber the ids and emails, or use a generator built for volume.
There are two record types and no way to change the fields. Measured, one row of each:
people { "id": 1, "name": "Ruby Diaz", "email": "[email protected]", "age": 38 }
products { "id": 1, "sku": "SKU-1000", "name": "Chair", "price": 85.24, "inStock": true }
Ages fall between 18 and 67, so there are no children and no one over retirement age: if you are testing an age-banding rule or a parental-consent path, this data will never exercise it. Prices fall between 5.00 and 100.00 with two decimal places, so there are no free items, no large values and no awkward three-decimal currencies. Product names come from a pool of eight, so they repeat heavily at any size.
Both shapes are always a JSON array at the top level, formatted with two-space indentation, and every field is always present. There are no nulls, no missing keys, no empty strings and no unicode beyond plain ASCII, which makes this data useless for testing how your code handles any of those. That is worth saying plainly, because the bugs that reach production are usually in the handling of the missing field rather than the present one.
Nothing is uploaded. The generation is a few lines of JavaScript running in your browser, and no request is made at all.
example.com is the right domain for test data: RFC 2606, Reserved Top Level DNS Names. rfc-editor.org/rfc/rfc2606Math.random. developer.mozilla.orgJSON.stringify. developer.mozilla.orgEvery behaviour and every count on this page was measured against this tool as it is published, in a browser, on 14 October 2026. The 63 distinct names and the 62 in-stock products are single observations of a random process, so your own run will differ; the pool sizes behind them will not.
Because the names are built from ten first names and ten surnames, which is a hundred possible combinations, picked at random with replacement. Measured on a hundred rows: 63 distinct names, with one appearing five times. Use the id or email field if you need something unique; both are sequential.
No, and deliberately so. They are [email protected] upwards, and example.com is reserved by RFC 2606 precisely so test data cannot reach a real mailbox. That makes this data safe to load into a system that might try to send something.
No, there is no seed. Measured: the same request twice in a row gives different data. If you need the fixture to be stable, generate once and save the output into your project as a file, rather than regenerating each time.
The count is clamped between 1 and 100 and nothing says so on screen. Measured: 500 gives 100, 0 gives 1, and an empty box gives the default 5. For bulk volumes you need a different generator.
No. There are two fixed shapes, people and products, with the fields shown above. There is no schema editor, no custom field and no nesting.
For filling a screen or a table, yes. For testing robustness, no, and this is worth being blunt about: every record is complete, flat and plain ASCII, with no nulls, no missing keys, no empty strings and no unusual characters. Those are the inputs that break production code, and this data contains none of them.
That is the range the generator uses. There are no children and no one over retirement age, so age-banding rules, parental-consent paths and pension logic will never be exercised by this data. Prices are similarly bounded, between 5.00 and 100.00 with two decimals.
No. The generation is a few lines of JavaScript in your browser and no network request is made at all.