Take JSON from raw response to typed code
You've been handed a blob of JSON — an API response, a config file, a sample payload — and you need to trust its shape. These twelve tools take you from making it readable, through finding what's actually inside it and giving it real types, to reshaping it into whatever comes next. Everything runs in your browser, so nothing you paste is uploaded.
The short answer
To go from raw JSON to code that trusts its shape: first pretty-print and validate it so structural problems are visible, then query it with JSONPath and audit its keys to learn what's actually inside. Generate TypeScript interfaces for compile-time types or a Zod schema for runtime checking, and validate real payloads against a JSON Schema. Finally reshape it — flatten it, convert it to CSV, YAML or NDJSON — for wherever it's going next. Every step runs in your browser, so the data is never uploaded.
Make it readable
before you do anything elseRaw JSON pulled from a network tab or a log line is usually minified or inconsistently indented. You can't spot a structural problem in something you can't read, so this is always the first move.
Find what's actually in it
search and compare without eyeballing itOnce it's readable, the next problem is scale. A large or deeply nested document can't be scanned by eye for one value, or checked for a schema inconsistency buried three levels down.
Give it real types
so a typo doesn't reach productionJSON has no type system of its own. Every consumer either trusts it blindly or checks it, and only one of those survives a schema change intact.
Reshape and move it
csv, yaml, and everything betweenJSON is rarely the final destination. It gets flattened for a spreadsheet, streamed one record per line, or handed to a system that only speaks another config format.
Read it before you trust it
The JSON you're handed is almost never in a state you can reason about. Pulled from a network tab it arrives on one line; copied out of a log it's been through a stringify that escaped every quote; assembled by hand it has the indentation of whoever last touched it. None of that changes the data, but all of it hides the thing you're looking for — a bracket that closes in the wrong place, an object where you expected an array, a trailing comma that invalidates the whole document.
So the first tool is a pretty-printer. JSON Formatter re-indents the document, sorts keys if you want a stable order to diff against later, and — the part that earns its place first — gives you a specific parse error with a location when the JSON is invalid, instead of the silent failure you get from pasting it straight into your code. To go the other way, JSON Minifier strips every space and newline back out while keeping the document byte-for-byte equivalent.
Learn what's really inside
Readable is not the same as understood. A response with forty keys, or the same object repeated across two thousand array entries, is past the point where reading top to bottom tells you anything. You need to query it and audit it instead.
JSONPath Tester pulls specific values out with a JSONPath expression — wildcards, recursive descent, array slices and filter expressions — and shows the exact resolved path beside every match, so you learn how to reach a value, not just that it exists. JSON Key Extractor answers the other question: across this whole dataset, what keys appear, and how often? A key that shows up in 1,998 of 2,000 records is the one that's sometimes missing — exactly the inconsistency that types are about to make you deal with. When you're comparing two payloads — a passing fixture against a failing one, yesterday's config against today's — JSON Compare lists every added, removed and changed value by its key path, comparing objects by key and arrays by index.
- 1Assuming a sample is representative
The one API response you happened to capture may have every optional field populated. Extract keys across many records before you decide which are required — the generators below can only infer from what you show them.
- 2Reading a large array by scrolling
If you're eyeballing a 2,000-element array for the odd one out, you'll miss it. Query for the shape you expect and look at what doesn't match.
Turn shape into a contract
This is the step that changes JSON from something you hope about into something you can rely on. There are two different things people mean by "typing" a payload, and they solve different problems.
JSON to TypeScript Converter gives you interfaces: compile-time types that make your editor and your build catch a misspelled field or a wrong assumption. They cost nothing at runtime because they don't exist at runtime — which is also their limit, since a TypeScript type can't check a response that actually arrives malformed. JSON to Zod Schema Generator closes that gap. It generates a schema that runs, parsing the payload and throwing when reality doesn't match, and it infers more than shape: it detects string formats like email, URL, UUID and date-time, and it draws the distinction that trips people up most — a key that can be absent is optional, a key that's present but sometimes null is nullable. Those are not the same, and conflating them is how a null slips through a check that only tested for presence.
- Sample
- { "id": "9f2c", "email": "a@b.co", "plan": null }
- Generate
- JSON to Zod Schema Generator infers email as a string with .email() format and plan as nullable
- New payload
- { "id": "9f2c", "email": "not-an-email", "plan": "pro" }
- Result
- the schema rejects it — email fails the format check even though the JSON is perfectly valid
A pretty-printer would have called that second payload fine. The schema is what encodes the rule that it isn't.
When the contract already exists as a JSON Schema, JSON Schema Validator runs a document against it — Draft-07 specifically — and reports every violation by its JSON-pointer path: missing required keys, wrong types, out-of-range numbers, failed patterns and enums. It's the difference between "this payload is wrong somewhere" and "the value at /items/3/price is below the minimum."
Reshape it for where it's going
JSON is a transport and a source of truth, but it's rarely what the next system wants. JSON Flattener collapses a nested document into single-level keys in dot-and-bracket notation — user.roles[0] — which is what you need to map a tree onto spreadsheet columns, and it reverses cleanly back to nested JSON. JSON to CSV Converter takes an array of objects straight to CSV, flattening nested objects to dot-notation columns, taking the header as the union of every key, and quoting fields per RFC 4180 so a comma inside a value doesn't corrupt the row.
For data that streams, NDJSON Formatter & Validator handles newline-delimited JSON, where one bad line is flagged without stopping the rest — something a plain JSON parser can't do, since it fails the entire document on the first bad byte. When the destination is a config file, JSON to YAML Converter produces clean block-style YAML. The reverse tools exist too — CSV to JSON Converter, YAML to JSON Converter and JSON Editor for interactive tree edits.
Which one do I want?
Several tools here overlap. The short version:
| JSON to TypeScript vs JSON to Zod Schema | You want compile-time types that vanish at runtime — editor and build checks. | You want a schema that runs and rejects a malformed payload as it arrives. |
|---|---|---|
| JSON Schema Validator vs JSON to Zod Schema | A schema already exists and you're checking documents against it. | No schema exists yet and you're generating one from a sample. |
| JSON Compare vs JSON Key Extractor | Diffing two specific documents to see what changed between them. | Auditing which keys appear, and how often, across one whole dataset. |
| JSON Flattener vs JSON to CSV | You want one flat object with path keys, still as JSON. | You want an array of objects as spreadsheet rows and columns. |
Why this set
Formatting, querying, typing and conversion all run client-side. Nothing you paste is uploaded, which is what makes it safe to work with a real API response instead of a scrubbed one.
The same document flows through every stage — read it, audit it, type it, reshape it — without re-pasting into a different site or juggling four tabs that each do one thing.
A schema encodes the rules a pretty-printer can't check — a bad email, a missing key, a null where a value belongs — so a typo is a build error, not a production incident.
Questions
Is it safe to paste a real API response into these tools?
Yes. Every step here runs entirely in your browser — formatting, JSONPath queries, type generation and conversion all happen client-side, and nothing you paste is sent to a server. That's what makes it reasonable to work with a genuine payload rather than a sanitised sample.
What's the difference between generating TypeScript types and a Zod schema?
TypeScript interfaces are compile-time only — they help your editor and build catch mistakes but disappear at runtime, so they can't check a response that actually arrives malformed. A Zod schema runs: it parses the incoming payload and throws when the data doesn't match. Use the TypeScript converter for internal types you control, and the Zod generator at the boundary where untrusted data enters.
My JSON is valid but my code still breaks on it. Why?
Valid and correct are different questions. A formatter confirms the document parses; it says nothing about whether the shape matches what your code expects. A field can be missing, a number can be a string, or a key that's usually present can be null. Generate a schema from a known-good sample and validate the real payload against it to see exactly which rule it breaks.
What does it mean for a key to be nullable versus optional?
Optional means the key can be absent from the object entirely. Nullable means the key is present but its value can be null. They're genuinely different failure modes — a check that only tests for the key's presence passes a null right through — which is why the Zod generator marks missing keys optional and mixed-null keys nullable rather than collapsing both into one.
Can I convert NDJSON without one bad line breaking everything?
Yes — that's the point of a newline-delimited format. The NDJSON validator checks each line independently and flags a bad one without discarding the rest, unlike a standard JSON parser that fails the entire document on the first syntax error. You can pretty-print or minify every record while keeping the line structure, or convert the whole thing to and from a regular JSON array.