Sample JSON Generator
Generate a genuine JSON or JSON Lines file in seconds — seven content types, real nested structure, the classic big-integer edge case, and an exact target file size. No flattened fakes. Runs entirely in your browser.
{
"field_1": "Sample Value 1",
"field_2": 13.7,
"field_3": "furniture"
}Quick Tips for the Right Test File
Features
A Format That Actually Has a Standard
Sample CSV spends most of its interface on format mechanics because CSV never really had one agreed shape. JSON is the opposite case entirely: RFC 8259 defines exactly how a string gets escaped, exactly what a number can look like, exactly what counts as valid — there's no delimiter to argue about, no line-ending convention to get wrong. That certainty is precisely why this generator's interesting surface area shifted from "does the format itself vary" to "does a given parser correctly handle everything the specification actually allows" — deep recursion, numbers at the edge of what a language can represent, two equally valid ways to write the same accented character.
The Bug That's Bitten Nearly Every JSON API
JSON numbers have no upper bound in the specification — a JSON document is free to contain a 40-digit integer and remain perfectly valid. JavaScript's own Number type disagrees: past 9,007,199,254,740,991 (2⁵³ − 1), it can no longer represent every integer exactly, and critically, JSON.parse doesn't warn when this happens — it just quietly hands back the nearest representable value instead of the one actually written in the file. Number Edge Cases includes a real integer one past that limit, encoded as an honest JSON number, specifically so this can be witnessed directly rather than taken on faith.
The same file also includes that identical value encoded as a string instead, which is the standard, battle-tested workaround real systems use — database platforms with 64-bit IDs, and services issuing Snowflake-style identifiers, both routinely serialize large integers as strings specifically to survive a round trip through JavaScript unscathed.
It's worth being precise about what actually breaks here: the JSON file itself is never wrong — the raw bytes on disk faithfully preserve every digit, exactly as RFC 8259 allows. The corruption happens one step later, entirely inside whatever language or library parses the file into native values. A file from this generator can't fix that gap, but it can make it visible before it surfaces as a mysteriously off-by-a-little-bit database ID in production.
Two Correct Ways to Write the Same Character
A JSON string containing "é" can be written two genuinely different ways at the byte level and mean exactly the same thing: as the raw UTF-8 bytes for the character itself, or as the six-character escape sequence \u00e9. Every other row in Unicode & Escapes uses the first approach, the same one JSON.stringify produces by default. One row deliberately uses the second, hand-built specifically to demonstrate that a parser treating the two differently — rendering one correctly and mangling the other — has a real, specification-violating bug, not just an unusual input it happened not to expect.
Escaped control characters sit right alongside this same idea, in one of the other rows in the same file — a genuine line break or tab character inside a JSON string is illegal exactly as written and must be represented as \n or \t instead, the same escape-versus-raw-byte distinction applied to whitespace rather than accented letters.
Padding Without Anywhere to Hide It
JSON shares CSV's exact structural gap here: no comment syntax, no metadata block, nothing a parser is ever obligated to skip. Padding stays honest about that rather than pretending otherwise — a clearly labeled _padding field, added to the file's root object (or as one extra element, for the array-rooted and JSON Lines cases), holding the padding characters directly where anyone inspecting the file can see exactly what it is. Because plain ASCII characters need no JSON escaping, the bytes added land on the exact requested target, with the same small, openly-disclosed overshoot as CSV when a target sits only a few bytes above the file's natural size.
Two Shapes of Deep Nesting, Not Just One Depth Number
Deep Nesting isn't a single repeated wrapper object stacked to some depth and left at that — it's built as two genuinely different shapes, because a recursive parser can pass one and still fail the other. A long single chain, one child inside the next inside the next, tests pure recursion depth in its simplest form: does the parser or the language runtime it's built on hit a stack limit before reaching the bottom.
The second shape is a branching organization tree, where nesting still runs deep but each level fans out into multiple children rather than a single line. That catches a different class of bug entirely — a parser tuned only for the linear-chain case, or a recursive-descent implementation that allocates per-branch rather than per-level, can behave correctly on one shape and blow up or silently truncate on the other. Pushing the Nesting Level slider toward its 60-level ceiling exercises both shapes at once, which is the more realistic stress test of the two.
Who Actually Needs a Real Test JSON
Backend developers hardening an API's JSON deserialization need Deep Nesting and Number Edge Cases specifically, since stack-depth limits and integer precision are two of the most common places a JSON-handling library quietly breaks under real-world input. Data engineers building a log pipeline need JSON Lines to test against the actual format their ingestion system expects, not a large array that has to be fully buffered first. Frontend developers building a JSON viewer or diff tool benefit from working through Every Data Type and Unicode & Escapes together, since a viewer that renders flat objects correctly can still mishandle an empty array, a null, or an escaped character it wasn't built to expect.
Configuration-file tooling has a narrower but very real need here too — a linter, formatter or schema validator that only round-trips clean, machine-generated JSON has never really been tested against the messier files people actually hand-edit, with inconsistent indentation, occasional Unicode, and the odd deeply nested override block.
Where This Tool Isn't the Right Pick
If the test needs genuinely tabular, flat data rather than a hierarchical structure, Sample CSV is the more direct fit — forcing nested JSON into a spreadsheet-style test misses the point of either format. And if you already have real CSV or JSON data and need it converted rather than a new sample generated, CSV to JSON and JSON Formatter handle that directly.