JSON VIEW PARSER

What Parsing Actually Means

A JSON document arriving over the network is not data. It is text — a sequence of characters that happens to follow a convention. The string {"id":101} is eleven characters; it has no id field, because it has no fields at all. Parsing is the step that turns those characters into a value with structure, one your language can index into and iterate over.

Two things happen during that step, and separating them explains most of the confusion around JSON tooling. First the parser checks that the text obeys JSON's grammar, rejecting it outright if not. Second, assuming it passed, the parser constructs the corresponding value in memory. Validation is therefore not a separate feature bolted onto a parser — it is an unavoidable part of parsing, because you cannot build a structure from text whose structure you cannot determine.

Parse, Validate, Format: Three Different Questions

These three operations get conflated constantly, and knowing which one you actually need saves a lot of wasted debugging.

A fourth question sits above all of them: is this data correct for my application? A document can parse perfectly and still be missing a required field or carry a string where a number belongs. Nothing in this list catches that — it is JSON Schema's territory.

How a Parser Reads Your Document

Parsers work in two passes. The first, lexical analysis, walks the characters left to right and groups them into tokens — the meaningful units of the language. Whitespace between tokens is consumed and discarded here, which is exactly why re-indenting a document cannot change its meaning.

Input:   {"id": 101, "ok": true}

Tokens:  {          punctuation, begin-object
         "id"       string
         :          punctuation, name separator
         101        number
         ,          punctuation, value separator
         "ok"       string
         :          punctuation, name separator
         true       literal
         }          punctuation, end-object

The second pass, syntactic analysis, checks that the token sequence forms a legal structure. JSON's grammar is small enough to state in a paragraph: a value is an object, array, string, number, true, false, or null; an object is a brace-delimited list of string : value pairs separated by commas; an array is a bracket-delimited list of values separated by commas. That is essentially the whole language, which is why JSON parsers are fast and why the format won.

When this pass fails, the parser reports where. That position is where the grammar was first violated — which is often after the character you actually got wrong. A missing comma is detected when the next token turns up unexpectedly, so the error points at the innocent token that followed.

Three Things That Parse Successfully and Still Ruin Your Day

Malformed JSON is the easy case: it fails loudly and you fix it. The genuinely expensive bugs come from documents that parse without complaint and still give you the wrong value.

1. Numeric precision loss

JSON's grammar places no limit on a number's magnitude or decimal places. Most parsers, however, store every number as an IEEE 754 double. Integers above 2⁵³ — roughly 9 quadrillion — cannot all be represented, so they are silently rounded to the nearest value that can be.

JSON.parse('{"id": 12345678901234567890}').id
// → 12345678901234567000     ← the last digits are gone

JSON.parse('{"total": 0.1}').total + JSON.parse('{"total": 0.2}').total
// → 0.30000000000000004      ← classic float behaviour, not a JSON bug

No error is raised. If those digits were a database ID or a payment amount, you now have corrupted data flowing through your system. The standard mitigation is to transmit large identifiers and monetary values as strings, converting them at the edge with a decimal library. Twitter hit this famously enough that its API returned both id and id_str for years.

2. Duplicate keys

The specification allows an object to repeat a key and declines to say what should happen. In practice nearly every parser keeps the last one and discards the rest, silently.

JSON.parse('{"role": "user", "role": "admin"}')
// → { role: "admin" }        ← the first value vanished without warning

Because different implementations may choose differently, a document like this can mean one thing to your frontend and another to a backend written in a different language. That gap has been used as a real attack vector against authorisation checks.

3. Prototype pollution

JSON.parse itself is safe — a key named __proto__ becomes an ordinary own property, not a prototype reference. The danger appears one step later, when parsed data is merged into an existing object by a naive deep-merge helper, which can end up writing to Object.prototype and affecting every object in the program.

// Safe on its own
const data = JSON.parse('{"__proto__": {"isAdmin": true}}');

// Dangerous if deepMerge walks keys without guarding against __proto__
deepMerge(config, data);

The fix belongs in the merge function, not the parse: skip __proto__, constructor and prototype keys, or build onto Object.create(null).

Parsing in Code

Every mainstream language ships a parser in its standard library. The one detail worth knowing in JavaScript is JSON.parse's second argument, the reviver — a function called for every key-value pair as the tree is built, letting you transform values during the parse rather than walking the result afterwards.

// Revive ISO date strings into Date objects as they are parsed
const ISO = /^\d{4}-\d{2}-\d{2}T/;

const data = JSON.parse(raw, (key, value) =>
  typeof value === "string" && ISO.test(value) ? new Date(value) : value
);

Always wrap a parse of untrusted input, because a failure throws rather than returning a sentinel:

function safeParse(text) {
  try {
    return { ok: true, value: JSON.parse(text) };
  } catch (err) {
    return { ok: false, error: err.message };
  }
}

The equivalents elsewhere: json.loads() in Python, json_decode() in PHP, ObjectMapper.readValue() in Java, and json.Unmarshal() in Go.

Reading Parser Error Messages

Error text varies by runtime, but the underlying cause is usually one of a handful. This table maps the common messages to what they actually mean:

That fourth row deserves emphasis, because it is the single most common JSON error in web development and it has nothing to do with your JSON. A response beginning with < is an HTML document — usually a 404 or 500 page, or a login redirect. Check the response status and Content-Type before blaming the parser. The JSON errors guide walks through each of these with fixes.

Using the Parser on This Site

Paste any JSON into the input panel and it parses as you type. If the document is valid you get a formatted view, an interactive tree and a statistics summary; if it is not, you get the error message and the line and column where the grammar first broke.

• It runs client-side. Parsing happens in your browser via JavaScript. Your JSON is never uploaded, logged or stored, which makes it appropriate for real API responses containing customer data.
• It reports position, not just failure. Knowing a document is invalid is far less useful than knowing that line 47 has a trailing comma.
• It repairs near-miss documents. When a document fails to parse, a Fix Common Errors action appears: it strips comments, converts single quotes and smart quotes, quotes bare keys and removes trailing commas. It leaves valid documents untouched, and if the repair still does not parse it keeps your text rather than replacing it.
• It summarises structure. The statistics view reports nesting depth, key counts and type distribution — useful for sizing up an unfamiliar payload before you write code against it.
• It works offline. Once the page has loaded you can disconnect entirely and everything still functions. That is also the simplest way to prove to yourself that nothing is being transmitted.

Frequently Asked Questions