JSON Formatter and Validator

Q: My JSON says unexpected token, what is usually wrong?

Nine times out of ten it is one of three things: a trailing comma after the last element, single quotes around a string, or a // comment. The tool reports the error column, so read one character back from that column and you will usually find it.

Q: Why does it parse fine in the browser but fails when I paste it here?

Many endpoints return JSON-ish output: JSONP wrapping, unquoted keys, or a BOM prefix. Strip the outer wrapper and the BOM first, then validate, and most false errors disappear.

Q: A big number like an order id changed after formatting, why?

JavaScript Number has only 53 bits of precision, so integers above 2^53 lose digits. If a field is a long integer id, the backend should return it as a string. This tool keeps strings verbatim and never rewrites their values.

Q: When do I use minify vs format?

Use format, with indentation, when reading a structure or debugging an API. Use minify, with all whitespace removed, when storing config, passing args on a command line, or diffing. Both only change presentation, never the data.

Pure frontend: paste JSON, pretty-print, minify or validate in one click. Nothing leaves your browser — no network call, nothing recorded.

How to use

Paste any JSON into the left box, hit Format to expand it by nesting level, hit Minify to strip all whitespace, or hit Validate to only check whether it parses, pointing at the line and column when it fails. Pick 2-space or 4-space indentation.

JSON input

Indent

Why ops people format JSON every day

You will hit single-line JSON constantly:

API debugging: a raw curl response is one long line; past three levels of nesting it is unreadable until formatted.
Config files: kubectl -o json, Prometheus config.json, and most SDK configs are easier to review when expanded by level.
Log triage: in structured (JSON line) logs a single field with the wrong type breaks the downstream parser; format first, then diff.
Tickets and docs: formatting a config before pasting it into a ticket lets the other side read it at a glance and cuts the round trips.

The three errors that cause most failures

Symptom	Root cause	Fix
`Unexpected token }` at the end	A trailing comma after the last array or object element	Delete that comma
`Unexpected token '` or unterminated string	Single quotes used; JSON accepts only double quotes	Switch to double quotes
`Unexpected token /` or `#`	A `//` or `#` comment; standard JSON has no comments	Remove the comment, then validate

The tool reports a character position from the parser. We convert that to line N, column M so you can read one character back from that column and almost always catch it.

Pitfalls worth knowing

BOM prefix: Windows Notepad saves UTF-8 with three invisible bytes (EF BB BF) at the front. Pasted JSON then starts with garbage and fails at the very first character. When "the first character is wrong" with no obvious cause, suspect a BOM and strip it with sed -i '1s/^\xEF\xBB\xBF//' or re-save as UTF-8 without BOM.

Large number precision: JSON.parse reads numbers as double-precision floats, so integers above 2^53 (about 9e15) lose precision. Order ids and snowflake ids are exactly this kind of long integer and must be returned as strings by the backend. If they arrive as numbers, the digits you see after formatting may already be wrong. This tool keeps strings verbatim and never rewrites them.

Keys must be quoted: {name: "ops"} is legal in JavaScript objects but JSON requires the key itself to be a double-quoted string, { "name": "ops" }. This is another top reason something "runs in the browser but fails validation".

Duplicate keys: JSON permits duplicate keys, but implementations disagree on whether the first or last wins. Never write duplicate keys in config; when they appear the bug is painfully hard to find.

Numbers vs strings: a port written as 8080 and a port written as "8080" mean different things to strict consumers. Be deliberate about which you intend, especially in Kubernetes and Prometheus config.

A real debugging example

Suppose you get a response compressed onto one line, impossible to read by eye:

{"code":0,"data":{"user":{"id":12345678901234567890,"name":" ops ","tags":["vip",]},"list":[{"sku":"A1","price":9.9},{"sku":"A2","price":19.9}]},"msg":"ok"}

Paste it and hit Validate: the tool immediately reports unexpected token at line 1, column 60. Read back from column 60 and you find "tags":["vip",] has a trailing comma after the last array element. Delete it, re-format, and the structure is clear; the long user.id integer is also preserved verbatim as a string instead of being silently rewritten.

That example hides two more issues: the username " ops " has stray spaces (upstream trimming missed it), and id is an integer above 2^53 (it must be a string). Formatting does not fix those business problems, but it lays the structure open so you can see at a glance where something looks off.

How this tool relates to jq

Not a replacement, a complement:

Quick browser use: when you just received a blob, are pasting config into a ticket, or are on a machine without jq, open the page and you are done. That is this tool's job.
Batch command-line work: to extract fields, filter arrays, or rewrite files in a script, jq is the better fit, e.g. jq '.data.list[] | select(.price>10)' to pull out the expensive items.
Validation in CI: run jq empty config.json before committing to catch invalid JSON in the pipeline, steadier than pasting by hand.

This tool makes things comfortable for a human; jq makes things runnable for a machine. Both belong in your toolbox.

Using it in config management

The scary part of editing config is breaking it without knowing. A safe loop:

Export the config from the cluster (kubectl get ... -o json, or Prometheus config.json).
Paste into this tool and Format, read it level by level, confirm the part you changed is structurally right.
Hit Minify, paste the compact result back into your editor or command line.
Validate once more before committing to keep trailing commas and single quotes out of production config.

Structured logs, CI artifacts, and most SDK configs follow the same pattern: format to see clearly, then touch it.

More traps people miss

Escape sequences: inside a JSON string, a double quote must be \", a newline \n, a backslash \\. When building strings from another language it is easy to forget one escape, and the error often points at a normal character inside the string while the real fault is earlier.

Unicode escapes: emoji and rare characters may be encoded as \uXXXX. Formatting leaves them alone, but if you "count length by eye" you will be fooled — the sequence takes six characters yet represents a single glyph.

Scientific notation: very small or very large numbers may render as 1e-7 or 9.9e20. Still valid numbers, but a downstream string comparison will drift. Ask the upstream to send strings when exactness matters.

null vs missing: "x": null and "field absent" are different in JSON, yet many parsers blur them. When debugging "why did this field not take effect", first confirm whether it is null or simply not sent.

Number or string: a port 8080, a version 1.0, an area code 010 — number or string changes how a strict consumer judges it. Get into the habit of quoting anything that is an identifier or code semantically, and you avoid a class of weird bugs.

OpenTelemetry unified telemetry: Trace/Metric/Log collection — field conventions and wiring for structured logs, metrics and traces; formatting is only step one
LLM service observability — how to read and debug the JSON an API returns
Self-hosting with Cloudflare tunnel — configs carry JSON blocks; format before you edit