Paste JSON that's been minified, copied out of a log line, or just typed in a hurry, and get back properly indented, readable JSON — instantly, entirely in your browser.
A JSON formatter takes JSON text and rewrites it with consistent indentation and line breaks so a human can actually read it. Json Web Viewer's Format action does exactly that, plus two variants: Smart format keeps small objects and arrays on one line so the result stays compact instead of exploding every value onto its own row, and Compact does the reverse — strips all whitespace back out for when you need the smallest possible payload. It's really three tools in one: a formatter, a validator, and — when the JSON is actually broken — a fixer, covered below.
Formatting also doubles as validation: if the text isn't valid JSON, the app tells you exactly where parsing failed rather than silently failing or producing garbled output, and it can click-to-jump straight to the error location. That makes Format the fast way to answer a common question before you go any further — paste an API response or a config file, format it, and immediately see whether it's syntactically valid JSON at all.
The three variants exist for different situations, not as three equally-good defaults:
Browsers don't agree on how they phrase a JSON parse error, and neither format is something you should
have to memorize. V8 (Chrome, Edge, Node) reports a raw character offset — … at position 12 —
while Firefox reports a line and column instead — … at line 2 column 3 of the JSON data.
Json Web Viewer reads whichever form the running browser actually produced, converts it to a single
line/column position either way, and lets you click straight to that spot in the text instead of counting
characters or lines by hand.
That matters most on a large document: a bare character offset like "position 4,812" tells you almost nothing on its own, but jumping straight to that character does. It's also why Format doubling as validation is genuinely useful rather than incidental — the same click that would format valid JSON instead locates exactly where parsing broke when it isn't.
This specific error is common enough to deserve its own explanation, because position 0 is
a different diagnosis from a mistake further into the document — it means the very first character wasn't
valid JSON at all. The most frequent real cause: something that isn't JSON got parsed as if it were. An API
endpoint that returned an HTML error page instead of a JSON response is the classic case — the response
starts with <!DOCTYPE html> or a bare <, and < at position
0 is exactly what triggers this message. A login redirect, a 404/500 page served where JSON was expected, or
an empty response can all produce the same symptom. If you hit this, the fix usually isn't in the JSON text
at all — it's checking what actually came back from wherever the "JSON" was supposed to come from.
Other parse-error messages you'll see for different mistakes: unexpected end of JSON input (the document was truncated or empty), unterminated string in JSON (a quote was never closed), and unexpected non-whitespace character after JSON (valid JSON followed by something extra, like a trailing comment or a second document concatenated on). All of them work the same way here — click straight to the reported position rather than deciphering the wording.
Formatting only works on JSON that already parses. When it doesn't, Json Web Viewer offers a separate
Repair action, powered by jsonrepair, an open-source repair engine — not a
generic tool description, but the actual library this app calls. Repair is only ever offered when its
result itself parses as valid JSON; if it can't produce something that parses, nothing is offered. Every
class below is individually covered by this app's own test suite, not just the library's documentation:
[1,2,3,] → [1,2,3].
{'a':'b'} → {"a":"b"}.
{a:1} → {"a":1}.
/* ... */) and line (// ...) comments,
which JSON's own grammar doesn't allow, stripped out cleanly. {"a":1 /* note */} →
{"a":1}.
callback({"a":1}) → {"a":1}.
{"a":1}\n{"a":2} →
[{"a":1},{"a":2}].
True, False, and None left over
from a Python print(dict) or a hand-edited json.dumps output, converted to
JSON's own true/false/null.
{"a":True,"b":None} → {"a":true,"b":null}.
NumberLong(2) and
ISODate("2012-12-19T06:01:17.171Z") wrapper syntax, exported straight from a Mongo shell or
mongoexport, unwrapped to their plain JSON values (a number, and an ISO date string).
These are the classes this app's own tests pin down explicitly. The repair engine underneath generally handles other common issues in the same spirit — missing commas, missing closing brackets, truncated JSON, and smart/curly quotes copied out of a word processor — but Repair only ever offers a result if that result actually parses. In practice, most broken JSON that shows up while debugging falls into one of the categories above: a config file hand-edited into invalid syntax, an API response copy-pasted out of a log that stripped its quoting, or an export straight from a database tool that used its own shorthand instead of plain JSON.
Honestly, not everything. If the pasted text isn't JSON at all — an HTML page, a plain sentence, a log line — Repair doesn't fail with an error. It wraps the whole thing as a single JSON string, which is technically valid JSON but rarely what you actually wanted. That's not a bug so much as an edge case worth knowing about before you rely on it: if Repair's output is just your original text sitting in quotes, that's what happened, and Undo reverses it instantly.
A few other honest limits: Repair never touches a document that already parses — there's nothing to fix, so nothing changes. It never offers a suggestion that doesn't itself validate as JSON, rather than showing you a broken result. And it deliberately doesn't fire on text that looks like a JWT or a stack of newline-delimited JSON — those get their own more useful actions (Decode as JWT and Convert to array, respectively) instead of a generic repair attempt.
Repair only ever runs against your own text, in your own browser — it isn't sent anywhere to be checked against a service, and there's no size limit beyond whatever your browser can hold in memory.
Example — this minified JSON:
{"id":1,"name":"Ada Lovelace","roles":["Engineer","Writer"],"active":true,"address":{"city":"London","country":"UK"}}becomes this after Format:
{
"id": 1,
"name": "Ada Lovelace",
"roles": [
"Engineer",
"Writer"
],
"active": true,
"address": {
"city": "London",
"country": "UK"
}
}
Open this example in the editor →
The link above pre-loads the JSON above into the editor. Once it's open, click Format in the
toolbar (or press Ctrl+I) to see it formatted.
Need to check a document's shape against a schema instead of just its syntax? See JSON Schema Generator.
No. Formatting, validating, and every other mode in Json Web Viewer runs entirely in your browser. The document you paste is never sent to a server.
Format expands every object and array onto its own indented line. Smart format keeps small objects and arrays on one line so the result stays compact and readable, while still indenting anything too large to read on one line.
Formatting alone only works on valid JSON. When the app detects common mistakes — a trailing comma, an unquoted key, a missing bracket — it offers a one-click Repair action separately from Format, described below.
Trailing commas, single quotes, unquoted keys, JavaScript-style comments, a JSONP callback wrapper,
newline-delimited JSON stacked as separate documents, Python's True/False/None, and MongoDB's
NumberLong(...)/ISODate(...) export syntax are all specifically tested and
fixed. The underlying repair engine generally handles other common slips too — missing commas, missing
closing brackets, smart quotes — but only ever applies a fix that produces valid JSON.
It doesn't fail with an error. Instead it wraps the whole thing as a single JSON string — technically valid JSON, but probably not what you wanted from a log line or an HTML page. If Repair's output is just your original text in quotes, that's what happened; Undo reverses it instantly.
No — those get their own dedicated actions instead. Text that looks like a JWT gets a Decode as JWT button in place of Repair, and newline-delimited JSON gets a Convert to array offer, both more useful than a generic repair for those specific shapes.
Right in the toolbar next to Format — there's no separate menu to hunt through. It only appears when the document doesn't already parse, and stays out of the way entirely when your JSON is already valid.