Generate fake data that is the thing it is labelled: card numbers with a real Luhn check digit, IBANs that pass ISO 7064 MOD 97-10, UUID v4 and v7 per RFC 9562, reserved e-mail and IP ranges, a seed so the same data comes back, and JSON, NDJSON, CSV or SQL output
Initializing in your browser…
Generate passwords from the Web Crypto generator by rejection sampling, with the entropy stated exactly from the alphabet, the cost of every rule computed, and crack times against four named attacker models
Stack CSS box shadows with any colour notation, and never write a declaration the browser will drop: a layer that will not parse is left out and flagged rather than taking every other layer down with it
Round corners in px or percent, circular or elliptical, and see the radius the browser will actually paint after the CSS overlap rule scales it down
Your frontend needs a handful of user records to build against before the API exists, and your payment form rejects anything that fails Luhn. Set the seed to demo, tick Full Name, Email, UUID v7, Credit Card and IBAN, and generate three rows: every value below comes back identically, because the seed is what produces them.
Fields and seed
fullName, email, uuidV7, creditCard, iban rows: 3 seed: demo
Generated JSON
[
{
"fullName": "William Robinson",
"email": "williamrobinson@example.net",
"uuidV7": "018bd030-aab0-7c72-a864-0806eedb5d5c",
"creditCard": "6456 8676 7861 6846",
"iban": "GB64 NJKH 1433 5173 9129 50"
},
{
"fullName": "Jessica Moore",
"email": "jessicamoore@example.com",
"uuidV7": "018bd285-2faa-707a-8532-7f2fcd844a75",
"creditCard": "5286 7398 8285 0651",
"iban": "AT67 7297 2185 7236 6169"
},
{
"fullName": "Linda Taylor",
"email": "linda87@example.com",
"uuidV7": "018bd548-e190-7a0c-a171-89b399d4c553",
"creditCard": "3054 6548 2172 86",
"iban": "ES80 8652 2240 2208 0393 6531"
}
]Each of those is checkable, and the page checks it. 6456 8676 7861 6846 is a Discover number: the 645 prefix is in the range Discover issues, it is sixteen digits, and its last digit is the Luhn check digit of the other fifteen. 3054 6548 2172 86 is fourteen digits because that is what Diners Club issues. GB64 NJKH 1433 5173 9129 50 is twenty-two characters, the length the ISO 13616 registry gives the United Kingdom, and its MOD 97-10 remainder is 1. The UUIDs are version 7, so their first six octets are a millisecond timestamp and they sort by creation order. The addresses are at example.net and example.com, which RFC 2606 reserves so they can reach nobody. Change the seed and you get a different set that is equally checkable; clear it and the page tells you the run cannot be reproduced.
Pick the fields you want and get fake records that are the thing they are labelled: card numbers that pass Luhn, IBANs that pass MOD 97-10, UUIDs with the right version bits, and a seed so the same data comes back. Export JSON, NDJSON, CSV or SQL.
Thirty field types over eight groups, and the point of the tool is that most of them have an independent decider and satisfy it. A credit card number carries the Luhn check digit of ISO/IEC 7812-1 annex B at a length and prefix the network really issues, so American Express is fifteen digits and Discover is 6011, 644 to 649 or 65. An IBAN carries the ISO 7064 MOD 97-10 check of ISO 13616 at that country's registered length. An ISBN-13 carries the GS1 modulo 10 check digit. A UUID has its version and variant in the right bits per RFC 9562, in v4 or in v7, which sorts by creation time. An address goes to a domain RFC 2606 reserves so it can reach nobody, a telephone number sits in 555-0100 to 555-0199, the block reserved for fiction, and an IP address comes from the RFC 5737 and RFC 3849 documentation ranges.
None of that was true before. Measured over 2,000 draws on 2026-09-04, the previous version produced card numbers of which 200 passed Luhn, which is exactly chance for a random last digit, and 1,178 had a prefix no network issues. Its postal codes were drawn from 10000 to 99999, so it could never produce an address in Connecticut, Maine, Massachusetts, New Hampshire, New Jersey, Rhode Island or Vermont, every one of which starts with a zero, while offering New Jersey and Massachusetts in its own state list. Thirty-nine of its telephone numbers could never be dialled. Every address it made was at a live provider.
The other change is the seed. The generator draws from a seeded stream with rejection sampling, so the same seed gives byte-identical rows and the seed travels in the shared link: a dataset can be regenerated, and a test that fails against it can be re-run against the same data. Leaving the seed empty draws from crypto.getRandomValues instead and the page says the run cannot be reproduced. Every row is internally consistent, so a city, its state and its ZIP prefix agree and the e-mail is built from that row's own name. Output is JSON, NDJSON, CSV written by RFC 4180 with the CRLF section 2.1 requires, or SQL. And after every run the page checks each value against its own definition and shows the count, so the data is demonstrably right rather than asserted to be.
Select firstName, lastName, email, date and jobTitle, set a seed, generate 100 rows and share the URL. Whoever opens it gets the identical hundred rows.
Select Credit Card and IBAN, generate 200 rows, and every one will pass the Luhn and MOD 97-10 checks your form runs, which is what makes them useful as fixtures rather than as noise.
Populate a mock API server with realistic JSON so you can demo frontend features before the backend is ready.
Export CSV to test imports, table layouts, and search results without exposing real user data.
Generate realistic rows to test table layouts, search results, and form autofill at various lengths.
Fill demo instances with believable data for client presentations and sales walkthroughs.
It is drawn by rejection sampling, so there is no modulo bias at any range, but by default it is SEEDED rather than unpredictable: the same seed gives the same rows. That is deliberate, because a dataset nobody can reproduce is a dataset nobody can check. Clear the seed to draw from crypto.getRandomValues instead.
Yes. SQL is one of the four output formats, with identifiers quoted by doubling the quote and values by doubling the apostrophe, which is the SQL-92 rule every dialect shares.
No. The lists are US and English only, so names, cities and companies look American, and the addresses, telephone numbers and postal codes follow US conventions. There is no locale selector.
They are structurally valid and belong to nobody. Each one has a real issuer prefix, the right length for that network, and a correct Luhn check digit, which is what a payment form checks before it does anything else. No account exists behind any of them, and no test in this tool has ever contacted a payment processor.
RFC 2606 section 3 reserves example.com, example.org and example.net so that a made-up address cannot reach a real person. A generator that hands out gmail.com addresses is handing out addresses that may belong to somebody, and a test harness that sends to one of them is sending real mail.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.