Mock Data Generator

Paste a JSON Schema or OpenAPI component schema...\n\n{\n  "type": "object",\n  "properties": {\n    "name": { "type": "string" },\n    "email": { "type": "string", "format": "email" }\n  }\n}

Free Mock Data Generator for JSON Schema

Mock data generation is an essential part of modern API development. Whether you are building a frontend prototype, writing integration tests, populating a staging database, or demonstrating an API to stakeholders, you need realistic-looking data that matches your schema's structure and constraints. Our Mock Data Generator takes any JSON Schema or OpenAPI component schema and instantly produces valid, realistic test records — entirely in your browser with no server calls.

Why Mock Data Matters for Development and Testing

Real production data is rarely available during development, and for good reason. Privacy regulations like GDPR prohibit using customer data in non-production environments without proper anonymization. Production databases contain edge cases and historical artifacts that make them unreliable for repeatable tests. And waiting for a backend team to build real endpoints before starting frontend work introduces expensive delays into the development cycle.

Mock data solves all of these problems. It lets frontend developers build and test UI components against realistic payloads before the API exists. It gives QA engineers a controlled set of test inputs that cover happy paths, edge cases, and boundary conditions. It allows database administrators to test migration performance against tables with realistic row counts and data distributions. And it eliminates the compliance risk of copying production data into development environments.

Hand-crafting test data is tedious and error-prone. When your schema changes — a new required field, a tighter constraint, a different type — every hand-written fixture needs updating. By generating mock data directly from your schema, you guarantee that test records always match the current contract. This approach eliminates the drift between test fixtures and production schemas that causes false positives in CI pipelines.

How Schema-Based Data Generation Works

Schema-based generation reads your JSON Schema definition and produces data that satisfies every constraint. The generator walks the schema tree top-down: for each property, it reads the declared type, checks for enum or const values (which are used directly), applies format-specific generators (email, date-time, UUID), respects numeric ranges (minimum through maximum), generates strings within length bounds, and recursively processes nested objects and arrays.

When composition keywords like allOf, anyOf, or oneOf are present, the generator merges or selects subschemas to produce a valid combination. For anyOf and oneOf, it picks one branch per record. For allOf, it merges all constraints into a single effective schema before generating. This ensures the output passes validation even for complex composed schemas.

The generator also extracts schemas from OpenAPI 3.x component definitions. Paste the components.schemas section of your OpenAPI spec, and the generator identifies each named schema and lets you generate data for any of them. This means you can go from an OpenAPI specification to realistic test data in seconds, without writing any code.

Realistic vs. Random Data: When to Use Each

Our generator offers two modes, and choosing the right one depends on your goal. Random mode produces data that satisfies schema constraints but makes no attempt to look like real-world data. A string field gets a random alphanumeric string; a number field gets a random value within the allowed range. This mode is ideal for fuzz testing, where you want to explore the full space of valid inputs and find edge cases your application does not handle gracefully.

Realistic mode uses heuristics based on field names to produce human-plausible data. A field named email generates sarah.chen@example.com rather than xk7mq2p. A field named price generates 29.99 rather than 847362.1. This mode is essential for UI development (realistic data reveals layout issues that random strings miss), stakeholder demos (real-looking data makes prototypes convincing), and database seeding (queries against realistic data produce realistic performance characteristics).

The realistic mode supports over 30 common field name patterns: names, emails, phone numbers, addresses, URLs, UUIDs, dates, timestamps, prices, descriptions, avatars, IP addresses, company names, job titles, colors, status values, and more. It also respects schema constraints — if your name field has a maxLength of 20, the generated name will fit within that limit.

Using Mock Data: API Testing, UI Prototyping, Database Seeding, and Load Testing

API testing. Generate JSON fixtures that match your API's request and response schemas, then use them in your test suite. Contract testing validates that your API accepts valid payloads and rejects invalid ones. Boundary testing targets constraint limits — generate strings at exactly minLength and maxLength, numbers at minimum and maximum, arrays at minItems and maxItems. Combine mock data with negative testing (deliberately invalid records) to verify both acceptance and rejection paths.

UI prototyping. Frontend developers often need to build components before the backend API is ready. Generate realistic mock responses and use them with a mock server or directly in your component tests. Realistic data reveals layout issues that placeholder text misses — a long company name overflows a table cell, a multi-line address breaks a card layout, a price with five decimal places does not fit the price column.

Database seeding. Export generated data as CSV and import it into your development database. This gives you a populated database for manual testing and demos without copying production data. Seed different tables with consistent foreign key relationships by generating parent records first, then referencing their IDs in child records.

Load testing. Generate hundreds or thousands of records to test how your application handles realistic data volumes. Pagination components, virtual scrolling, search indexing, and database query performance all behave differently with 10 records versus 10,000. Generating large datasets from your schema is faster and more representative than duplicating a handful of hand-written fixtures.

Writing JSON Schemas That Produce Good Mock Data

The quality of generated data depends directly on the quality of your schema. A schema that says "type": "string" with no further constraints produces random strings. A schema that adds "format": "email" or "minLength": 2, "maxLength": 50 produces much more useful output. Here are guidelines for schemas that generate well:

• Use descriptive field names. The realistic mode infers generators from names like email, firstName, createdAt, and price. Generic names like field1 or value fall back to random data.
• Add format keywords. Use "format": "email", "format": "date-time", "format": "uri", and "format": "uuid" to get properly formatted values.
• Constrain numbers and strings. Set minimum/maximum for numbers and minLength/maxLength for strings to get values in realistic ranges.
• Use enum for categorical data. If a field should be one of a fixed set of values (like "status": "active" | "inactive" | "pending"), declare it as an enum. The generator will pick from the allowed values.
• Declare required properties. Required properties are always included in generated records. Optional properties are included probabilistically, giving you a mix of complete and partial records.

Locale-Aware Data Generation

Testing with only English data misses internationalization bugs. Our generator supports multiple locales — US English, UK English, European English, German, French, and Japanese — each with appropriate names, cities, postal code formats, and phone number patterns. This helps you catch encoding issues (characters outside ASCII), text overflow in narrow UI columns (German compound words are significantly longer than English equivalents), and locale-specific validation bugs (Japanese postal codes use a different format than US zip codes) before they reach production.

Deterministic Output with Seeds

Reproducible test data is critical for debugging and regression testing. Provide a seed value, and the generator produces identical output every time — same names, same emails, same numbers. This means you can reference specific test records in bug reports, share reproducible test cases with teammates, and build deterministic test suites that do not flake due to random data changes. When you need to investigate why a test failed, you can regenerate the exact data that caused the failure.

Export and Integration

Generated data can be downloaded as JSON for API test fixtures, database seeding scripts, and mock server responses, or as CSV for spreadsheet analysis, import into relational databases, and data pipeline testing. The JSON output is syntax-highlighted and copyable for quick use in test files.

Related Tools

Need to create a schema first? Use our JSON to Schema Generator to infer a schema from example data. To validate data against a schema, try our JSON Schema Validator. For detecting changes between schema versions, see our Breaking Change Detector. To learn the fundamentals, read our Complete Guide to JSON Schema.

Frequently Asked Questions

Is my schema or generated data sent to a server?

No. The generator runs entirely in your browser. Your schema and the generated data never leave your device. There is no backend processing involved.

Can I generate data from an OpenAPI specification?

Yes. Paste the components.schemas section from your OpenAPI 3.x spec and the generator will extract each named schema. You can then generate mock data for any of them. The tool handles $ref references within the components section.

How do I generate the same data every time?

Enter a seed value in the seed field. Any string works as a seed. As long as you use the same seed, schema, and settings, the generator produces identical output. This is useful for reproducible tests and shared test fixtures.

What happens with fields that have no constraints?

A field declared as "type": "string" with no format, pattern, or length constraints will generate a random alphanumeric string in random mode, or attempt to infer a generator from the field name in realistic mode. Adding constraints (format, minLength, maxLength, pattern, enum) significantly improves output quality.

Can I generate data with relationships between records?

The generator produces independent records from a single schema. For relational data with foreign keys, generate parent records first, note the generated IDs, then manually reference them in child record schemas using enum to constrain the foreign key field to valid parent IDs.