About the JSON Editor
JSON is the format almost every API, config file, and log line arrives in, and almost none of it arrives in a shape you can read. A minified API response is one 40,000-character line. A config file that fails to parse gives you "Unexpected token } in JSON at position 1847" and nothing else. A deeply nested payload hides the one field you actually care about six levels down.
This editor is a workspace for all of that. It formats and validates, but it also repairs JSON that is not quite valid, renders the same document as a collapsible tree, a flat table, or a node graph, runs JMESPath queries against it, checks it against a JSON Schema, and diffs two documents side by side. Everything happens in your browser — the JSON you paste never leaves the tab, which matters when the document is a production API response with real customer data in it.
When you'd use it
- Pretty-printing a minified API response so you can actually read the field names.
- Finding the syntax error in a package.json or tsconfig.json that your build is rejecting.
- Pulling one nested value out of a large payload without writing a script — for example every user id in a paginated response.
- Checking that a request body matches the JSON Schema an API documents before you send it.
- Comparing a staging response against a production response to see which fields drifted.
- Turning an array of objects into a table so you can scan 200 records instead of scrolling 4,000 lines.
Repairing malformed JSON
Trailing commas, single quotes, and unquoted keys are the three things hand-edited JSON gets wrong most often. Repair fixes all three in one pass.
Input (invalid)
{
name: 'Ada Lovelace',
roles: ['admin', 'engineer',],
active: true,
}After Repair
{
"name": "Ada Lovelace",
"roles": ["admin", "engineer"],
"active": true
}Extracting a field with JMESPath
JMESPath queries the parsed document rather than the text, so it works regardless of formatting or key order.
Query
users[?active].{name: name, team: team.name}Result
[
{ "name": "Ada", "team": "Platform" },
{ "name": "Grace", "team": "Compilers" }
]The four view modes, and when each one helps
The same document can be displayed four ways, and picking the right one is usually faster than scrolling.
- Code view is the raw text with syntax highlighting and folding. Use it when you need to edit, or when you care about the literal formatting.
- Tree view collapses every object and array to a single line you can expand. Use it to understand the shape of an unfamiliar payload without reading its contents.
- Table view flattens an array of objects into rows and columns. Use it when the document is a list of records — it makes missing fields and outlier values obvious at a glance.
- Graph view draws objects as connected nodes. Use it for documents with cross-references or deep nesting, where the relationships matter more than the values.
Why JSON fails to parse, and what Repair can and cannot fix
The JSON specification is much stricter than the JavaScript object literal syntax it resembles, and nearly every parse error comes from that gap. Keys must be double-quoted strings. Strings cannot use single quotes. Trailing commas are illegal. Comments are illegal. NaN and Infinity are not valid numbers, and neither is a leading + or a hex literal.
Repair handles the mechanical cases: it quotes bare keys, converts single-quoted strings to double-quoted ones wherever they appear, strips trailing commas, and removes // and /* */ comments. It reads the document character by character rather than pattern-matching over it, so a // inside a string — the second slash of every https:// URL — is treated as content rather than as the start of a comment.
It deliberately does not guess at ambiguous input. A truncated document, an unquoted value such as undefined, or a string missing its closing quote are all left alone and reported, because there is no single correct repair and silently choosing one would corrupt your data rather than fix it.
If Repair cannot produce valid JSON, the validator reports the line and column of the first failure so you can fix it by hand. That is usually more useful than a fix you did not ask for.
Querying with JMESPath
JMESPath is a query language for JSON, the same one used by the AWS CLI's --query flag. It operates on the parsed structure, so whitespace, key order, and formatting are irrelevant.
The basics cover most real use: a.b.c walks into nested objects, items[0] indexes an array, items[*].name projects a field across every element, items[?price > `100`] filters, and {alias: path} reshapes the output. Backticks denote literal values inside filter expressions, which is the one piece of syntax people trip over.
- data.items[*].id — every id in an array of objects
- data.items[?status == `active`] — only the active records
- data.items[*].{name: name, owner: owner.email} — reshape into a smaller object
- length(data.items) — count without scrolling
Validating against a JSON Schema
Switch the query bar to Schema mode and paste a JSON Schema into one panel to check the other against it. Validation reports every failure with its instance path, not just the first one, which is what you want when a request body is being rejected by an API and the error message only names one field.
This is genuinely useful before you send a request: schema violations are a large share of 400 responses, and finding them locally is faster than a round trip.
Frequently asked questions
- Is my JSON uploaded anywhere?
- No. Parsing, formatting, validating, querying, and diffing all run in JavaScript in your browser tab. Nothing is sent to a server, which is why the tool works offline once loaded. The one thing that does leave your browser is the Share URL feature, and only when you explicitly click it — it encodes the panel contents into the link itself.
- How large a document can it handle?
- Documents in the low single-digit megabytes format and validate comfortably. Above roughly 5 MB, tree and graph views get slow because they build a DOM node per value — code view and table view stay usable much longer. If you are working with something genuinely large, querying it down to the subset you need first is faster than rendering all of it.
- What is the difference between Format and Smart-format?
- Format applies standard two-space indentation with one value per line. Smart-format keeps short arrays and objects on a single line when they fit, so a document with many small coordinate pairs or key/value maps stays compact instead of exploding to ten times its height.
- Does the editor change my data?
- Formatting and sorting keys change the text, never the values. Sorting keys is safe because JSON object key order is not semantically meaningful — but note that it does change the byte output, so do not sort if you are comparing against a checksum or a signature.
- Why does my JSON with comments fail?
- Comments are not part of the JSON specification. Formats like tsconfig.json and .eslintrc use JSONC, a superset that permits them. Run Repair first to strip the comments, then format.