JSON Data Generator

About JSON Data Generator

Define field names and types and this generator produces up to 1,000 records as a JSON array. There are 24 types, including names, emails, phone numbers, dates, cities, companies, UUIDs, IPv4 addresses, hex colors and lorem ipsum text; integer and float accept a range, and pick accepts a list of options. With a seed, the same output comes back every time.

It is tempting to think fake data should look as real as possible. The awkward failures in test data, though, come from “fake” values that turn out to belong to a real person, a real mailbox or a real network. This page goes through what the generator actually emits, field by field, and where you need to be careful.

Emails: reserved example domains only

Emails take the form first.last(optional number)@domain, with the domain chosen from example.com, example.net and example.org. All three are reserved by RFC 2606 for documentation and examples, so nobody can register them. The same RFC also reserves the top-level domains .test, .example, .invalid and .localhost.

That means a generated address can never belong to a real person’s mailbox. The flip side: if you feed generated users into a flow that sends a welcome email or a password reset, the message goes nowhere, so you cannot see how it actually renders. For that, route outgoing mail to a capture tool such as a local SMTP catcher.

Phone numbers and IPs come from reserved ranges too

Phone numbers take the form +1-area-555-01XX. The North American Numbering Plan permanently reserves 555-0100 through 555-0199 for fiction; NANPA keeps them as fictitious numbers that do not connect in any area code. The generator picks only the area code (200–999) at random and always draws the last digits from that range. It does not generate other countries’ formats, because we could not confirm an equivalent officially reserved range for them. To test validation of a local format, type the values into a pick field.

IPv4 addresses come from the three blocks RFC 5737 reserves for documentation: 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) and 203.0.113.0/24 (TEST-NET-3); only the last octet (1–254) is random. They are not routed on the internet, so they are safe in a screenshot, a blog post or a public bug report. Because every address falls into those three blocks, they are a poor fit for tests that need varied networks, such as per-IP statistics or GeoIP lookups.

No government IDs, on purpose

There is no type for Social Security numbers, passport numbers, national IDs or card numbers. A fake identifier that passes every format and checksum rule can collide with a real one, and a leaked fixture file full of such values is a problem in its own right. When you need to exercise form validation, keep two sets: values that are deliberately invalid, and valid values from a documented source, such as the test card numbers a payment processor publishes for its sandbox.

Realistic-looking, but uniformly distributed

Every value is drawn uniformly from a list. With 25 first names, 24 last names and 20 cities, a batch of 1,000 rows repeats the same first name dozens of times, and there are only 600 possible first/last combinations. Tests for a uniqueness constraint on names will collide quickly.

Dates are spread evenly across the five years before 2024-01-01 UTC, so 2019-01-01 to 2024-01-01. They only go backwards, so sign-up and order dates are never in the future and a date used as a birthday never yields a negative age. The anchor is a fixed date rather than today (so the same seed gives the same dates), which means a “signed up in the last 30 days” view will show nothing, and birthdays all belong to young children (ages 2–7 as of 2026). If you need adult ages, generate the age directly with the integer type. Integers are uniform as well, so they do not mimic skewed real-world quantities such as ages, prices or order sizes. Keep that in mind when you use the data to judge whether a chart or a summary statistic “looks right”.

The seed covers the whole sequence, not individual fields. Random numbers are consumed field by field, row by row, so adding, removing or reordering a field changes every value after it. Same schema plus same seed gives the same output; change either and you get a different dataset.

Worked examples

How to use it

1. Add fields and set each key and type. Fill in the parameter box for types that take a range or a list.
2. Choose a row count (1 to 1,000) and indentation. Note the seed if you will need to regenerate the same data.
3. Generate, then copy or download the JSON.

Frequently asked questions