Generate Mock JSON Online

How to Generate Mock JSON Online

1. Define Your Schema: Add a field for each property you want in the output JSON — for example id, firstName, email, address.city, phoneNumber, dateJoined. For each field pick a type from the dropdown (UUID, full name, email, street address, ISO date, integer, boolean, etc.). Field names map 1:1 to JSON keys in the generated objects.
2. Pick a Type for Each Field: Choose from Faker-style data types — firstName, lastName, fullName, email, address.city, address.country, phoneNumber, uuid, date, ipAddress, number, boolean. The dropdown labels mirror the @faker-js/faker namespace, so what you see is what the underlying generator produces.
3. Set Record Count (Optional): Enter how many objects you want in the output array — typically 10 for a quick sample, 100–1,000 for UI prototyping, or larger batches for load-test fixtures. Everything runs locally in your browser, so there's no server-side rate limit.
4. Generate and Download: Click "Generate" to see a formatted JSON array preview, then "Copy" to clipboard or "Download" to save as a .json file. Paste straight into a db.json for JSON Server, an MSW handler, or a Postman collection.

Why Generate Mock JSON?

Real production data is risky to ship outside a database — PII, contractual restrictions, and the simple fact that you usually don't have it yet when you're still building. Mock JSON gives you a realistic-shaped payload to wire up UIs, contract tests, and demos before any backend exists. Common scenarios:

• UI prototyping — Designers and frontend devs need a list of 50 user cards with names, avatars, cities, and join dates to lay out a dashboard. Mock JSON populates the component tree without waiting on the API team.
• API stubbing during contract-first development — Agree on a schema with backend, then mock it locally so frontend can keep moving. Drop the JSON into Mockoon, JSON Server, or Mock Service Worker (MSW) to serve it as a real HTTP endpoint.
• Load and stress testing — k6, Locust, and JMeter scripts need varied payloads. Generating 10,000 user records with realistic-looking names and emails gives the request mix enough entropy to exercise indexes, caches, and validation paths.
• Demo content for sales and screenshots — Marketing pages, App Store screenshots, and investor demos look hollow with User 1 / User 2 / User 3. Faker-quality names ("Avery Schmidt", "Lin Wei") make the product feel populated.
• Seeding dev and staging databases — Pipe the JSON through a seed script to bulk-insert a few thousand rows after a migrate reset. Re-runnable, deterministic if you set a seed, and free of any real customer data.
• Teaching and tutorials — Course material that needs a representative dataset (e.g., a React Query tutorial fetching /users) ships with self-generated mock JSON so students aren't blocked on signing up for an API key.

Need different shapes? Convert the output to JSON → CSV for spreadsheet imports, or run it through the JSON Formatter to pretty-print before pasting into a PR description. For ID-only fixtures see the UUID Generator.

Faker-Style Data Type Cheat Sheet

Type names below follow the @faker-js/faker module/method convention. The exact dropdown labels in xconvert mirror these so you can read the docs directly when you need a method this page doesn't list.

Type	Example output	Faker method
firstName	"Avery"	faker.person.firstName()
lastName	"Schmidt"	faker.person.lastName()
fullName	"Avery Schmidt"	faker.person.fullName()
email	"avery.schmidt@example.com"	faker.internet.email()
username	"avery_s84"	faker.internet.userName()
address.streetAddress	"742 Evergreen Terrace"	faker.location.streetAddress()
address.city	"Berlin"	faker.location.city()
address.country	"Germany"	faker.location.country()
address.zipCode	"10115"	faker.location.zipCode()
phoneNumber	"+1-555-128-3942"	faker.phone.number()
uuid	"f47ac10b-58cc-4372-a567-0e02b2c3d479"	faker.string.uuid()
date (ISO 8601)	"2024-11-17T08:42:11.000Z"	faker.date.past()
ipAddress (v4)	"192.0.2.146"	faker.internet.ip()
number	42	faker.number.int({ min, max })
boolean	true	faker.datatype.boolean()

The full Faker API covers ~70 namespaces (company, finance, vehicle, music, lorem, etc.) — if a type isn't in the dropdown, generate the closest match and post-process.

Mock JSON vs Real Data — When to Use Which

Use case	Mock JSON	Production data
Wiring up a new UI component	Right tool — fast iteration, no PII risk	Overkill, and usually not yet available
Contract tests between services	Right tool — pin the shape, run offline	Brittle — data churn breaks the test
Load testing for capacity planning	Right tool — generate at any volume	Hard to reproduce identical runs
Demo for sales or marketing screenshots	Right tool — handpicked, on-brand examples	Privacy / NDA risk
Analytics dashboards used for real decisions	Wrong — figures will mislead	Right tool
Bug reports that depend on a specific record	Wrong — won't reproduce	Right tool (anonymized export)
Training ML models meant to ship	Wrong — mock distributions ≠ real	Right tool

The line is roughly: anything before the product touches a real customer can use mock JSON; anything after has to use sanitized real data.

Frequently Asked Questions

Does this use Faker.js / @faker-js/faker?

The output is Faker-style — field types and value shapes match the @faker-js/faker namespace. @faker-js/faker is the community-maintained successor to the original faker npm package, which was self-sabotaged by its maintainer in January 2022. The fork moved to @faker-js/faker (scoped) and fakerjs.dev; the un-scoped faker package on npm is deprecated and you should not use it in new code.

Does it support non-English locales?

Faker itself ships with 70+ locale bundles (en_US, en_GB, de, de_CH, fr, fr_CA, es, ja, zh_CN, pt_BR, and so on). Locale coverage is uneven — some smaller locales fall back to English for namespaces they don't define (e.g., en_HK can't give you a zip code because Hong Kong doesn't use them). If a value looks "wrong for the country," switch to the en_US locale or post-process those fields.

Can I generate the same data twice with a seed?

Yes — that's exactly what faker.seed() is for. Calling faker.seed(123) before generation makes every subsequent call deterministic, so two runs with the same seed produce byte-identical JSON. This is essential for snapshot tests (Jest's toMatchSnapshot), reproducible CI fixtures, and "give me the same 100 users every time" workflows. One caveat: methods that depend on the current time (faker.date.past(), faker.date.recent(), UUID v7) also need faker.setDefaultRefDate('2020-01-01') to be fully reproducible, since the seed alone doesn't fix the date anchor.

How do I mock a REST API endpoint with this JSON?

Three common options:

• JSON Server — npm i -g json-server, save the file as db.json, run json-server db.json, and you have a REST API with GET/POST/PUT/DELETE at http://localhost:3000/users (route names come from the top-level keys). Best for quick local prototyping.
• Mockoon — Desktop app and CLI; import the JSON as a route response, add latency/error simulation, run as part of CI.
• Mock Service Worker (MSW) — Intercepts fetch/XHR at the browser or Node level via a service worker — no separate server. Drop the JSON into a handler and app.test.ts sees it as a real network response.

For a hosted "instant API" with prebuilt resources (users, products, posts, carts) check DummyJSON — it's the right pick when you don't need a custom schema.

Does this output conform to the JSON Schema standard?

The output is plain JSON — valid against any schema you choose to validate it against. If you want to go the other direction (define a JSON Schema 2020-12 document and generate matching data from it), use json-schema-faker, which combines JSON Schema 2019-09/2020-12 with Faker to emit valid sample documents straight from a schema file. Useful when your team already maintains schemas for OpenAPI / contract validation.

Can I model foreign keys or relationships between objects?

Not directly — the generator produces a flat array of objects with independent field values. To simulate a foreign key (say, orders[i].userId must exist in users[j].id), generate both arrays separately, then post-process: pick a random userId for each order from the user array. For most mock-data needs that's a one-liner; if you need referential integrity across many tables, reach for a fixture library like Snaplet, Mockaroo (paid tier supports formulas referencing other fields), or write a small seeder script.

Is "realistic-looking" mock data a privacy risk?

The data is synthetic — names, emails, phone numbers are generated from word lists and randomization. There's no guarantee a value won't accidentally collide with a real person (Faker's email uses domains like example.com and gmail.com-shaped strings by default, which can look like real addresses). Two practical guardrails: (1) for emails, configure Faker to use the IANA-reserved example.com / example.org / example.net domains, which are guaranteed not to deliver to anyone; (2) never email or SMS to generated phone numbers / email addresses without first checking against a real allow-list.

Where does the data come from — is anything sent to your servers?

Generation runs in your browser session via a Faker-compatible library bundled with the page. The JSON never leaves your device unless you explicitly download or copy it. No account is required and there's no record-count gate behind a Pro tier.