Generate realistic-but-fake sample data — names, emails, phones, addresses, companies, dates — as CSV, JSON, SQL or TSV. Privacy-safe, reproducible, built in your browser.
1–100,000, whole numbers. Generated entirely in your browser.
Pick the columns to emit, rename headers to match your schema, and reorder by dragging (or focus a ⠿ handle and use the arrow keys).
Decimals apply to decimal fields only (0–10). Integers use Min/Max as whole numbers.
A custom_list column picks a random value from this pool each row.
Reserved domains (RFC 2606) never reach a real mailbox.
Enabled when domain mode is set to custom.
Same seed + same settings = identical data. Leave blank for new random data on every generate.
—
This free fake data generator builds realistic-but-fake sample data for seeding databases, testing forms, building demos, and filling spreadsheets — without ever touching real customer data. Pick how many rows you want, choose your columns (names, emails, phones, addresses, companies, dates, numbers, UUIDs and more), and export as CSV, JSON, SQL INSERT, or TSV. Everything runs in your browser; nothing is uploaded.
.csv, .json, .sql, or .tsv).You need to seed a customers table with 500 test rows that pass a UNIQUE constraint on
email. Set rows = 500, format SQL INSERT, table name
customers. Add columns id (sequential, always unique), full_name,
email (toggle unique on), city, and signup_date (date,
range = last 2 years). Set a seed like qa-2026 so the same dataset regenerates byte-for-byte if a
test fails. Click Generate, then Download sample-data_500rows_….sql and run it against your test DB.
Every email is a syntactically-valid address on a reserved domain that can never deliver — safe to seed anywhere.
example.com / .net / .org, which RFC 2606 guarantees will never resolve to a real inbox. "Derive from company" and "custom domain" still build syntactically-valid addresses but a real custom domain could deliver — use it only for demos you control.(NXX) 555-0100 through (NXX) 555-0199, set aside specifically so fictional numbers never reach a real subscriber.crypto.randomUUID / crypto.getRandomValues where available — but treat them as test data, not real secrets.07001) survive in spreadsheets. Some legacy Excel locales want a semicolon delimiter or a UTF-8 BOM — re-export elsewhere if your import target misbehaves.true/false, blanks are null.INSERT INTO <table> (...) VALUES (...); per row, string literals single-quoted with ' escaped by doubling, blanks as NULL.Embeddable in one line — copy the ready-made snippet from the box below.
No. Every value is randomly assembled from token pools — resemblance to a real person is coincidental. Emails use RFC 2606 reserved domains and phones use the 555-0100–555-0199 fictional block, so neither can reach a real person.
CSV (RFC 4180, CRLF), JSON (array of objects), SQL INSERT (configurable table name), and TSV. Each download uses the correct file extension and MIME type.
Set a random seed. Same seed + same settings = byte-identical output, so failing tests are reproducible. Leave it blank for fresh data each click. The active seed is always shown so you can copy it.
Up to 100,000 rows. The cap keeps generation entirely in-browser without freezing the tab; requests above it are clamped to 100,000 with a notice, and values below 1 clamp to 1.
No. Generation runs entirely in your browser — which is exactly why it's safer than copying real customer or production data into a test environment.
No. Addresses combine plausible tokens but are not USPS-validated; a generated street + ZIP usually is not a real, deliverable address. Don't use the data for mailings or geocoding.
Built locally in your browser. Nothing you configure or generate is ever sent, logged, or stored.