Fake Data Generator (Mock & Test Data)

What is fake data, and when do you need it?

Fake data is realistic-looking sample data — names, emails, addresses, dates — generated on demand instead of pulled from a real database. It solves a problem every developer runs into early: a new feature, a new test, or a new demo environment needs rows in a table, and using real customer data for that is both a privacy risk and, once a company has any real users at all, against policy. Hand-typing "Test Test test@test.com" a hundred times doesn't scale and doesn't look real enough to catch layout bugs — a name field with a ten-character value behaves differently from one with sixty.

How do I generate test data for a SQL database?

Add the columns your table needs from the field palette, choose SQL as the output format, name the table, pick the row count and hit Generate. The output is an INSERT INTO ... VALUES (...); statement per row by default, or — with the "Rows per INSERT" setting turned up — several rows batched into one statement's VALUES list, which most import pipelines round-trip faster. Every string is escaped and every identifier quoted the way the chosen dialect actually expects — PostgreSQL doubles an embedded quote and leaves backslashes alone, MySQL escapes both, SQL Server brackets its identifiers, Oracle wraps a date in TO_DATE(...). Every statement this tool writes is re-lexed with the same lexer that runs the site's SQL formatter before it is shown, so a broken escape is caught here rather than failing silently on import.

Can I get the same data again?

Yes. Every run shows a seed — a short string that determines every value the run produces. Paste that seed back into the Seed field with the same schema and row count, and you get byte-identical rows, in any browser, at any time. That makes a generated dataset reproducible the way a real bug report needs to be: "row 4,271 breaks the importer" is only useful if whoever reads it can regenerate row 4,271 exactly. No competitor measured for this tool offers a seed at all.

Are these names, cards and phone numbers real?

Every value that could collide with something real is generated from a documented safe range, not merely shaped to look plausible. Credit card numbers are the payment networks' own published test numbers — the same ones Stripe and Visa's own documentation tells developers to hard-code. US Social Security numbers use the Social Security Administration's documented never-issued ranges (area 000, 666, and 900–999 have never been assigned to anyone). US phone numbers use NANPA's dedicated fictional-use block, 555-0100 through 555-0199, and UK phone numbers use Ofcom's published drama numbers. Email addresses use RFC 2606's reserved domains (example.com and friends), which can never be a real, deliverable mailbox. Where no such reserved range exists at all — checked directly against telecom regulator documentation, not assumed — the tool says so in the safety receipt after generation, rather than implying a guarantee it cannot back up. An Aadhaar number is not offered as a field at all, because unlike a phone number or a card, there is no small reserved subspace of valid Aadhaar numbers to draw from safely.

How many rows can I generate?

There is no cap. Generation runs a row at a time in a background thread, so the main page never freezes even for a million rows — but the rendered file itself is still assembled in your browser's memory before the download starts, so the practical ceiling is your device's available RAM, not a tier we sell. The best-known competitor in this space caps its free tier at 1,000 rows per file; ask for a million rows here and it runs the same way, just for longer, until memory is genuinely the limit.

Indian, US and European data

The Locale dropdown switches the whole generator to one of six real name/place corpora: English (US), English (UK), German, French, Spanish and English (India) — names, cities, states and postcode formats all switch together, not independently. The Indian locale's surname list is real but smaller than the others; the tool shows the exact size once you select it, so a large run's repetition is a known, disclosed limit rather than a silent one.

Date and time formats

Every date- and time-bearing field — Date & time, Recent, Future, Business-hours timestamp, Date and Date of birth — shares one "Output format" option: ISO 8601, ISO with a fixed UTC offset, RFC 3339, plain SQL (2026-03-14 09:12:07), RFC 2822/HTTP dates, Unix seconds or milliseconds, or a custom pattern built from tokens like YYYY-MM-DD, DD/MM/YYYY or MMM D, YYYY h:mm A. The options panel shows a live example under the pattern box as you type, and a set of one-click presets for the most common shapes. Month and weekday names are always English, spelled out in this tool's own lookup table rather than through the browser's locale data — the same value must render identically in every browser for a given seed, and locale-formatted names can differ by ICU version.

The format you pick changes more than the text: a machine format (ISO, SQL, RFC 3339, Unix) keeps a column typed as a real DATE/TIMESTAMP in the generated SQL and CREATE TABLE statement, and as a real, sortable date cell in the .xlsx export. A custom pattern can't be guaranteed to parse back as a date on every system, so that column is emitted as plain text everywhere instead — the SQL verification receipt and the field reference both say so for the columns it affects, rather than silently promising a date type the output can't back up. Every date-bearing field can also be set after or before another column (for example, an updated_at that's always after created_at, or a subscription_started_at that's always before trial_ends_at) — both relations use the same reference-date anchor every value in the run is drawn against, so the same seed reproduces the same ordering every time.

Field options: ranges, formats and patterns

Most field types take options beyond the value itself, shown behind the ⚙ button on that field's row. A number field takes a min/max range and a decimal-place count. An auto-increment column takes a start value, a step, an optional prefix like INV-, and zero-padding so 7 becomes 000007. A list field lets you type your own values. Every date-bearing field shares the one Output-format group described above. Options are stored with the schema, so a saved schema or a share link carries the exact ranges and formats you set, not just which field types you picked.

Unique values, and when they're impossible

Any field with a meaningful ceiling on distinct values — a first-name/last-name email, a username, a SKU, a weighted list — can be marked Unique. For most of those fields the tool checks the field's real combinatorial capacity against the row count you asked for before generating, so a request for more unique values than the field can actually produce is refused with the exact numbers, never a silent run that quietly repeats values (non-negotiable #1: never show a wrong answer). Email and username are the one exception: instead of refusing, a collision gets a number suffix — priya.shah, then priya.shah2, priya.shah3 — the same thing real mail providers do, so "unique" for those two fields never runs out. Uniqueness inside a nested array (see below) is scoped to that array by default, so a SKU only has to be unique within its own order, not across the whole file.

Columns that depend on each other

Real tables have columns that must agree: a last_login_at that's never before created_at, an order total that should exceed a minimum, a customer email that matches the customer's own company. This tool calls these relations and builds them into the option panel rather than leaving them to chance. Any date-bearing field can be set after or before another column, sortable ID types (UUID v1/v6/v7, ULID, ObjectId) can have their embedded timestamp tied to a date column with timestamp from, and Email's domain option can be set to same as company so the address matches a Company field elsewhere in the same row. A hidden dependency sorter works out the right generation order automatically — you never have to declare fields in a particular sequence for a relation to work.

IDs that decode back to their own timestamp

Several identifier types embed a real creation timestamp, not just a random string: UUID v1/v6/v7, ULID, MongoDB's ObjectId and a Snowflake-shaped 64-bit integer. Point one of these at a date column with the timestamp from option and the ID's own embedded time will match that column's value — an order_id ULID that's provably from the same moment as the row's created_at, which is exactly the kind of consistency a hand-typed or naively-random fixture almost never has. Auto-increment, nanoid and nanosecond hash-shaped IDs carry no timestamp and don't offer this option, honestly, rather than pretending to.

Check digits that are actually correct

Where a real-world identifier format includes a checksum, this tool computes the real one, not a random digit that merely looks plausible: IBAN's mod-97 check, EAN-13 barcodes' own check digit, a VIN's ISO 3779 check character in position 9, and a US ABA routing number's weighted check digit. A value with a broken checksum fails validation the instant it reaches any system that actually checks — a barcode scanner, a bank's IBAN validator, an ISO-compliant VIN decoder — so a random digit there would be a silently wrong answer wearing a real-looking format. Fields shaped only, without a public checksum algorithm to verify against (a UK sort code, an Indian IFSC code, a Snowflake ID), are labelled "shaped only" rather than claiming a guarantee this tool can't back up.

Choosing an output format

CSV is the most portable choice for spreadsheets and most import tools, with a configurable delimiter, header row and UTF-8 BOM (Excel needs the BOM to read UTF-8 correctly; most other tools don't care either way). JSON gives one array of objects, useful for a mock API response or a JS fixture file; NDJSON gives one object per line instead, the format most log pipelines and streaming JSON parsers expect. SQL generates dialect-correct INSERT statements (and, on request, a matching CREATE TABLE) for nine dialects, each one re-lexed before it's shown so a broken escape never reaches your clipboard. XML wraps each row in its own element. XLSX produces a real Excel worksheet, complete with real sortable date cells for any date column using a machine format — capped at 1,048,575 rows, which is Excel's own worksheet limit, not a limit this tool imposes.

Generating nested JSON

Add an object or array field from the buttons under the schema list, then drag a field from the palette onto it to nest that field inside — an address object holding street/city/postcode, or an items array holding one { sku, qty, unit_price } object per element, with a configurable minimum/maximum element count. Nesting can go to any depth, and person/address coherence scopes to the nearest object — each element of a contacts[] array gets its own independent person, not one shared across the whole row. Every flat format has a defined, non-lossy answer for a nested schema too, never an error: CSV, SQL and XLSX flatten an object to dotted address.city-style columns and either JSON-encode an array into one cell or "explode" it into one row per element (your choice); SQL types an array column as JSONB/JSON/text depending on dialect; XML wraps an array in a parent element with repeated child elements. The "Order with line items" preset demonstrates all of this pre-built.

Presets for common tables

Starting from a blank schema isn't always the fastest path, so the palette's Presets panel offers ready-made schemas for the tables people actually need sample data for — Users, Customers, Employees, Orders, Products, Payments, Invoices, an audit log, an API request log, Support tickets, Blog posts, Addresses and a Vehicle fleet register — each one a real, tested schema built from the same field catalog and options described on this page, not a simplified mockup. Pick one to replace your current schema (you'll be asked first if you have unsaved edits), then keep every field exactly as it is or edit any of it further. Built your own schema worth reusing? Save it under My schemas, right there in the browser, for next time.

Sharing and saving a schema

A schema you build is never lost by default. Save keeps it in this browser's own storage under My schemas, where you can rename, duplicate or delete it later, and Export writes it to a .json file you can hand to a teammate or commit alongside a project — Import reads that same file format back in. Copy shareable link encodes the whole schema — every field, option, the row count, seed, locale and date format — into the page's own URL, so pasting that link into a chat or a bug report hands someone else the exact same setup with nothing to re-build by hand. None of this uploads anything: a save writes to your browser's local storage, an export writes a file to your device, and a share link is just URL text — the schema and any values you type into it never leave your machine unless you choose to send that link yourself.

The full field reference

Every one of the {CATALOG.length} field types below is generated entirely in your browser, from the domain it belongs to, what it produces, and — where it matters — which option or coherence relation makes it more than a random string. Sample values shown are rendered from a fixed seed, so they're real output, not a mockup.

Person (12 field types)

First name e.g. Edwina

A first name only, drawn from the selected locale's real corpus (or the tiny built-in sample).

Middle name e.g. Amara

A middle name, drawn independently from the same locale corpus as the first name.

Initials e.g. EH

Initials built from the row's own first and last name, e.g. "J.S." for Jane Shah.

Suffix e.g. II

A name suffix such as Jr., Sr., II or III, drawn independently of the rest of the name.

Short bio e.g. Edwina is a engineer and coffee enthusi…

A short one-line bio sentence, generated from the text domain's own word pool.

Last name e.g. Hahn

A surname only, drawn from the selected locale's real corpus (or the tiny built-in sample).

Full name e.g. Edwina Hahn

First and last name together, kept consistent with any other person field in the same row.

Gender e.g. female

Male or female, kept consistent with the row's own first name via the coherence engine.

Title (Mr./Ms.) e.g. Ms.

A courtesy title (Mr., Ms., Dr., ...), kept consistent with the row's gender where relevant.

Date of birth e.g. 1949-07-05

A date of birth kept consistent with the row's own Age field, if one is also generated.

Age e.g. 77

An age in years, kept consistent with the row's own Date of birth field, if one is also generated.

Job title e.g. Analyst

A job title drawn from a realistic occupation list, independent of any Company fields in the row.

Address (10 field types)

City e.g. Lafayette

A city name, kept consistent with the row's own state, postcode and country via the coherence engine.

Street address e.g. 3122 Kohler Forest

A street address (number, name and suffix) shaped to look real, never a real property.

Building number e.g. 4642

A building or house number only, drawn independently of the full street address field.

State / county e.g. Indiana

A state, province or county name that agrees with the row's own city and postcode.

Postcode / PIN e.g. 85800

A postcode or PIN in the selected locale's own format, agreeing with the row's city and state.

Country e.g. United States

A country name, drawn from a fixed real-world list.

Latitude e.g. -6.438194

A latitude value in decimal degrees, drawn independently of the row's other address fields.

Longitude e.g. -12.876389

A longitude value in decimal degrees, drawn independently of the row's other address fields.

UTC offset e.g. UTC+09:00

A fixed UTC offset such as "+05:30", not a named IANA zone (see the date-format FAQ for why).

Full address e.g. 2738 Garcia Ln, Fairview, Texas 58005, …

A single formatted multi-line address string built from the row's own coherent city, state and postcode.

Internet (14 field types)

Email address e.g. edwina.hahn@example.com

An email address built from the row's own name, with a choice of local-part pattern and domain — see the field options table below.

Username e.g. edwina15h

A username derived from the row's own name, with an option to make every value unique.

IPv4 address e.g. 198.51.100.70

A random IPv4 address, optionally restricted to a private or documentation-only range.

IPv6 address e.g. 2001:db8:76d7:4614:4fed:d07a:81e8:e105

A random IPv6 address in standard colon-separated hextet form.

MAC address e.g. 76:46:4f:d0:81:e1

A random MAC address in standard colon-separated hex-octet form.

URL e.g. https://muller.example.com/about

A plausible HTTP(S) URL built from a random domain and path segment.

Domain name e.g. muller.example.com

A domain name such as "example-widgets.com", never a real registered domain.

Port e.g. 30972

A random TCP/UDP port number in the valid 0-65535 range.

HTTP status code e.g. 401

A real HTTP status code, weighted toward common ones like 200 and 404.

HTTP method e.g. PUT

A standard HTTP method: GET, POST, PUT, PATCH or DELETE.

MIME type e.g. image/png

A real IANA-registered MIME type such as "application/json" or "image/png".

Slug e.g. ea-error-repellat

A URL-safe, lowercase, hyphenated slug such as "my-example-post".

Emoji e.g. 🚀

A single random emoji character, drawn from a fixed pool.

Password e.g. )<=bddu~q@f(-mxq

A password-shaped string of mixed-case letters, digits and symbols — for filling a field, not a real credential.

Phone (5 field types)

US phone number e.g. (555) 0146

A US phone number using NANPA's reserved fictional-use block (555-0100 through 555-0199), never a real line.

UK phone number e.g. 07700 900273

A UK phone number using Ofcom's published drama-numbers range, reserved for exactly this use.

Indian phone number e.g. +91 7273757877

An Indian-shaped 10-digit mobile number. India has no reserved fictional-use range, and the tool says so plainly — see the safety receipt.

US landline (fictional area) e.g. (571) 555-0127

A US landline number shaped like a real one but drawn from the same reserved fictional-use block as US mobile numbers.

Extension e.g. x4695

A short numeric phone extension, 2-5 digits, independent of any phone number field in the row.

Company (7 field types)

Company name e.g. Muller LLC

A company name built from a name/word list, never a real registered business.

Company suffix e.g. Group

A company suffix such as Inc, LLC, Group or Ltd, independent of the company name field.

Catchphrase e.g. Seamless synergy for tomorrow

A short marketing-style catchphrase built from a fixed word bank, e.g. "Streamlined bleeding-edge synergy".

Department e.g. Finance

A department name such as Engineering, Sales or Finance, drawn from a fixed list.

Industry e.g. Healthcare

An industry label such as Retail or Healthcare, drawn from a fixed list.

Registration id (shaped) e.g. 51-3463820

A registration-number-shaped string of digits and letters — shaped only, not validated against any real registry format.

Company domain e.g. muller-llc.example.com

A domain name derived from the row's own company name, so the two stay consistent, e.g. Acme Group -> acme-group.example.com.

Commerce (9 field types)

Product name e.g. Gizmo

A product name built from an adjective/noun word pool, e.g. "Compact Titanium Widget".

Category e.g. Toys

A product category such as Electronics or Home & Garden, drawn from a fixed list.

SKU e.g. MHI-85800

A SKU-shaped alphanumeric code, optionally required to be unique within the file (or within one nested array).

EAN-13 barcode e.g. 4238580058081

A 13-digit EAN barcode with a correctly computed check digit, not just 13 random digits.

Quantity e.g. 47

A whole-number quantity within a configurable min/max range.

Currency code e.g. INR

A three-letter ISO 4217 currency code such as USD, EUR or INR.

Discount % e.g. 23

A discount percentage within a configurable min/max range.

Order status e.g. delivered

An order status such as pending, shipped or delivered, drawn from a fixed list.

Price e.g. 464.76

A decimal price within a configurable min/max range and decimal-place count.

Finance (13 field types)

Credit card number e.g. 5555555555554444

A card number from the payment networks' own published test ranges — the same ones Visa and Stripe's docs tell developers to hard-code.

US SSN e.g. 666-00-0000

A US Social Security Number using the SSA's documented never-issued ranges (area 000, 666, and 900-999), never a number that could belong to a real person.

IBAN e.g. GB98423858005808072555

An IBAN with a correctly computed mod-97 check, for a country you choose, shaped only — not drawn from a real bank's issued range.

IFSC (India, shaped) e.g. MHIV0507446

An Indian IFSC-shaped code (bank + branch), shaped only — not validated against RBI's real issued list.

Sort code (UK, shaped) e.g. 46-27-31

A UK bank sort-code-shaped 6-digit number, shaped only — not validated against a real issued range.

US routing number e.g. 464232252

A US ABA routing number with a correctly computed check digit, shaped only — not drawn from the Fed's real issued list.

Bank account number (shaped) e.g. 4642322529

A bank-account-number-shaped string of digits, shaped only — not validated against any real bank's format.

Card type e.g. Mastercard

A card network name such as Visa, Mastercard or Amex, consistent with any card number generated for the same row.

Card expiry (MM/YY) e.g. 05/28

A card expiry date in MM/YY (or MM/YYYY, YYYY-MM) form, always in the future relative to the run's anchor date.

CVV e.g. 464

A 3-digit CVV, or 4-digit for Amex when the row's own card type is Amex.

Amount e.g. 4642.32

A decimal monetary amount within a configurable min/max range, independent of the Commerce price field.

Transaction type e.g. transfer

A transaction type such as purchase, refund or transfer, drawn from a fixed list.

BIC / SWIFT e.g. MHIVFRWA

A BIC/SWIFT-shaped 8- or 11-character code, shaped only — not validated against a real bank's issued code.

Date & Time (11 field types)

Date e.g. 1997-11-08

A calendar date, with a shared Output-format option (ISO, custom pattern and more) and an optional "always after/before" relation.

Time e.g. 11:08:29

A time of day, with an hour-precision or clock-format option, independent of any date field in the row.

Date & time e.g. 1997-11-08T22:09:57.347Z

A full date and time together, sharing the same Output-format options as every other instant-shaped field.

Epoch (seconds) e.g. 879003344

A Unix timestamp in whole seconds since 1970-01-01T00:00:00Z.

Epoch (milliseconds) e.g. 879003344667

A Unix timestamp in milliseconds since 1970-01-01T00:00:00Z.

Recent (last N days) e.g. 2025-12-15T22:14:50.000Z

A timestamp within the last N days of the run's own fixed reference date, so the same seed always gives the same value.

Future (next N days) e.g. 2026-01-14T22:14:50.000Z

A timestamp within the next N days of the run's own fixed reference date, so the same seed always gives the same value.

Business-hours timestamp e.g. 1986-06-05T11:29:51.855Z

A timestamp confined to a configurable business-hours window on weekdays, e.g. 9am-6pm Monday-Friday.

Weekday name e.g. Saturday

A weekday name, spelled out or abbreviated, from this tool's own English lookup table (not the browser's locale data).

Month name e.g. June

A month name, spelled out or abbreviated, from this tool's own English lookup table (not the browser's locale data).

Duration e.g. PT28M

A duration string in ISO 8601 form, e.g. PT45M, within a configurable range.

Identifiers (11 field types)

Auto-increment ID e.g. 1

A sequential integer counter, with an optional prefix, start value, step and zero-padding.

UUID v4 e.g. 76464fd0-81e1-4303-94dd-10d305c54a8c

A random (version 4) UUID, the most common form when no ordering or timestamp is needed.

UUID v1 (timestamp) e.g. 38a84eb0-584f-11d1-9185-4fd081e10303

A version 1 UUID whose embedded timestamp can be tied to another column via "timestamp from".

UUID v6 (sortable timestamp) e.g. 1d1584f3-8a84-6eb0-9185-4fd081e10303

A version 6 UUID: sortable by creation time and, like v1, can tie its embedded timestamp to another column.

UUID v7 (sortable timestamp) e.g. 00cca8ae-9f1b-764f-9081-e1030394dd10

A version 7 UUID: the newer sortable-by-time form, increasingly the default choice for new systems.

ULID e.g. 00SJMAX7RV89TGW00JV2T0R9HJ

A ULID: sortable like a v6/v7 UUID but shorter and Crockford base32-encoded; its timestamp can tie to another column.

MongoDB ObjectId e.g. 346486d0464fd081e1039a5c

A MongoDB-shaped ObjectId (12 bytes, hex-encoded), with an embedded timestamp that can tie to another column.

nanoid e.g. dRT0g4AAl3E0BxSjlkjUt

A nanoid: a short, URL-safe random string popular as a lightweight alternative to a UUID.

Snowflake ID (shaped) e.g. 921743869169636449

A Snowflake-shaped 64-bit integer ID, shaped only — not guaranteed bit-identical to any specific platform's real algorithm.

Sequence (cycling list) e.g. a

Cycles through a fixed list of values you provide, repeating from the start once the list is exhausted.

Hash-shaped hex e.g. 744d8e009d1d0c489985bab56731faaf

A random hex string shaped like a hash digest (MD5, SHA-1 or SHA-256 length), not a real hash of any input.

Vehicle (7 field types)

Make e.g. Honda

A vehicle manufacturer name, kept consistent with the row's own Model field via the coherence engine.

Model e.g. Accord

A vehicle model name, kept consistent with the row's own Make field via the coherence engine.

Registration plate (shaped) e.g. MH38NWA

A registration-plate-shaped string, shaped only — not drawn from any real issuing authority's format rules.

VIN e.g. SKL3T6AA9W5C4A2KV

A 17-character VIN with a correctly computed check digit in the 9th position, per the real ISO 3779 algorithm.

Fuel type e.g. Electric

A fuel type such as Petrol, Diesel, Electric or Hybrid, drawn from a fixed list.

Colour e.g. Silver

A vehicle colour name drawn from a fixed list of common colours.

Year e.g. 2012

A model year within a configurable min/max range.

Text (6 field types)

Word e.g. iste

A single word drawn from a general-purpose word pool.

Words e.g. iste ea error repellat libero

Several words drawn from the same word pool, space-separated, with a configurable count.

Sentence e.g. Iste ea error repellat libero soluta ac…

A capitalized sentence of a configurable word count, ending in a period.

Paragraph e.g. Ea error repellat libero soluta accusam…

A paragraph of a configurable number of sentences.

Slug e.g. iste-ea-error

A URL-safe hyphenated slug built from random words, distinct from Internet's slug (which mimics a real post/page path).

Lorem ipsum block e.g. Error repellat libero soluta accusamus …

A larger block of several paragraphs, for filling a body-text or description field.

Custom (3 field types)

Constant

The same fixed value on every row — useful for a status flag, a tenant id, or any column that shouldn't vary.

Blank

An empty value on every row — useful for a column your schema needs to exist but not populate yet.

Weighted list e.g. A

Picks from a list of values you provide, each with its own relative weight, so common values appear more often — see Weighted lists below.

Common use cases

• Seeding a local development database without copying production data
• Populating a demo environment with realistic-looking rows before real users exist
• Generating deterministic fixtures for a test suite, reproducible from one seed
• Load-testing an import pipeline with a large CSV or NDJSON file
• Building a quick mock API response while a real backend endpoint isn't ready yet