Random JSON Data Generator

Why generated JSON is worth having

A great deal of development happens before the data exists. A front end is built against an endpoint that is still being written. A parser needs input before the producer is finished. A schema needs checking against documents that nobody has authored yet. In each case a realistic sample unblocks the work.

The value is in the shape rather than the content. What matters is that the structure matches what the real system will produce: the right nesting, the right mix of types, a list long enough to paginate. Whether a generated name is plausible is beside the point.

The four shapes

An array of objects is the simplest useful response and the shape most list endpoints return at their core.

The API envelope wraps that array with metadata — a status field, a page number, a total count. This is closer to what production endpoints actually return, and it matters for testing because client code has to reach through the envelope to find the data. Code written against a bare array often breaks the moment the real endpoint adds pagination.

The nested tree exercises recursion. Any code that walks a JSON document — a formatter, a validator, a transformer — needs testing against something with genuine depth, because bugs in traversal do not show up on flat data.

The flat key/value map is the shape of configuration files and lookup tables, where the keys are data rather than a fixed schema.

Whitespace is the only difference

Pretty-printed and minified JSON parse to identical values. Indentation exists for human readers and is stripped for transport, where it is pure overhead — on a large response the saving is substantial, and every HTTP layer will compress it further.

Neither form is more correct. Store and transmit minified, display pretty-printed, and never let a difference in whitespace be treated as a difference in data. Comparing two JSON documents as text rather than parsing them first is a recurring source of false differences in tests.

Awkward cases worth testing

Well-formed JSON is the easy path. The problems live at the edges. Numbers are the most common: JSON has one numeric type, and a value beyond the range JavaScript can represent exactly loses precision on parse. Large integer identifiers are the usual casualty, which is why many APIs transmit them as strings.

Then there is depth. A deeply nested document can exhaust a recursive parser’s stack, which is a known denial-of-service technique against services that accept untrusted JSON. Any parser handling external input should have a depth limit.

Duplicate keys are undefined behaviour in practice — the specification permits them and implementations disagree about which one wins. Empty objects and arrays, null where an object is expected, and Unicode escape sequences all deserve a test each.

When a schema is the better starting point

If your JSON must satisfy a specific contract, generating from the schema beats generating a plausible shape and adjusting it. A schema states which fields are required, which types are allowed and what the constraints are, so data generated from it is valid by construction. The JSON Schema tools in this section handle that case; this generator is for when you need something realistic quickly and the exact field names do not matter.

Privacy

JSON is generated in your browser. Nothing is transmitted, stored or logged.

Mocking an endpoint before it exists

Generated JSON is most useful when a front end needs to be built against a backend that is not finished. Saving a generated response to a file and serving it from a local path is enough to develop the whole interface — loading state, empty state, error state and all — before the real endpoint is available.

The important discipline is to mock the shape the real endpoint will return, envelope and all, rather than the bare array that is convenient today. Code written against a simplified mock breaks on contact with the real response, and that breakage arrives at integration time when it is most expensive.

Keeping mock and reality in step

A mock that drifts from the real API is worse than no mock, because it produces confident work built on a wrong assumption. The usual remedy is to derive both from the same contract — an OpenAPI description or a JSON Schema — so that a change to the contract updates the mock automatically and a mismatch is caught by a test rather than by a user.

Where a formal contract is more machinery than the work justifies, regenerating the mock whenever the endpoint changes, and reviewing it alongside the change, achieves most of the benefit for very little effort.