Skip to main content
ToolsByUs

JSON Parser

JSON Parser checks a document against RFC 8259 in your browser and reports its type counts, structure depth and language type mappings. It also shows which original numeric tokens would change if converted to a JavaScript Number. Inspection leaves the source unchanged; value converters reject those unsafe conversions.

Local-only
JSON document
0 B1 lineLn 1, Col 1

Paste a JSON document or click ‘Try Example’ above to parse and inspect its structure.

How does JSON Parser work?

“Does it parse?” is a question the validator answers. This tool answers the next one, which is usually the more interesting one: what did it parse into? A document can be perfectly valid and still not be the thing your code is expecting, and the gap is rarely visible by reading it.

The parser is hand-written rather than a call to JSON.parse, for reasons that matter here. It is iterative, with an explicit work stack, so a deeply nested document can be inspected without overflowing the JavaScript call stack. It rejects trailing content after the root value, which JSON.parse also does but many hand-rolled parsers forget. And every key from the document is assigned as an own property through a guard, so a payload containing __proto__ becomes a real key rather than altering the prototype of the object being built — which is the standard prototype-pollution vector for anything that parses untrusted JSON.

The analysis then walks the parsed value and counts what is there: how many objects, arrays, strings, numbers, booleans and nulls, how deep the nesting goes, and how many distinct keys appear. That is often enough on its own to spot the problem — an array you expected to hold objects holding only strings, a structure three levels deeper than the schema allows, a document that is 90% nulls because an upstream join failed.

The type-mapping table addresses the mistake that causes the most real bugs. JSON has one number type. JavaScript's JSON.parse converts it to an IEEE-754 double, which represents every integer exactly only through 253−1. For example, 9007199254740993 becomes 9007199254740992without a native parsing error. This inspector checks the original numeric tokens, including decimals and exponents, and labels any changed decimal value as a conversion risk. It counts the structure without exporting rounded values. JSON Formatter and JSON Minifier retain the original tokens; value converters reject these unsafe numbers.

The same table shows the rest of the mapping, because the assumptions differ by language. Go gives you float64 for every number unless you decode into a typed struct. Python distinguishes int from float and so keeps large integers exactly. Java and C# reach for BigDecimal or decimal when configured to.

Document

{ "id": 9007199254740993, "price": 0.1 }

Structure and numeric risk

3 values · depth 1 · 2 distinct keys

number   2   →  number (IEEE-754 double)

JavaScript Number conversion risk (source unchanged):
  9007199254740993 → 9007199254740992

What does the parser say about a broken document?

A missing comma, which is the single commonest JSON error. The parser reports where the document stopped being valid, not where the typo feels like it is.

Invalid JSON

{
  "id": 42,
  "name": "Ada"
  "active": true
}

Parser output

Missing comma between object key-value pairs.

Line 4, column 3

  "active": true
  ^

The caret sits on line 4 although the comma belongs at the end of line 3: a parser can only complain once it reads something that cannot follow. Look one line above the caret.

What options and edge cases does JSON Parser support?

Parsing rules and what they catch
ParameterTypeDefaultBehaviour & edge cases
GrammarRFC 8259strictNo comments, trailing commas, single quotes, unquoted keys, NaN or Infinity. These are JSON syntax rules; an API can still impose its own schema, size or numeric limits. JSON5 and JSONC are deliberately rejected.
Trailing contentrejected—RFC 8259 §2 defines a document as exactly one value. Two concatenated objects are a common symptom of a log line that was split wrongly, and are reported rather than silently truncated at the first.
Number precisionIEEE-754flaggedOriginal numeric tokens are compared with their JavaScript Number decimal round trip. Changed integers, decimals, overflow and underflow are flagged. The source stays unchanged and no rounded document is exported.
Duplicate keyslast wins—RFC 8259 leaves this undefined; nearly every parser keeps the last occurrence, and this one matches that. Worth knowing, because it is a real attack surface when two systems in a chain disagree.
__proto__own property—Assigned via defineProperty, so it becomes a normal key rather than re-pointing the prototype. Matches JSON.parse, and is the guard most hand-rolled parsers are missing.
Nesting depthiterativeno limitThe parser uses an explicit stack, so depth is bounded by memory rather than by the call stack. A 20,000-level document is covered by a test.
UnicodeUTF-8—\uXXXX escapes are decoded, and surrogate pairs are recombined so astral characters survive. A byte-order mark before the root is reported rather than treated as content.
Input sizebytes8 MBMain-thread ceiling. Above it the parse is declined rather than attempted. Nothing is uploaded at any size.

Frequently asked questions

How is this different from the JSON Validator?

The validator focuses on JSON syntax errors and repairs. This inspector also reports type counts, depth, distinct keys, language mappings and numeric conversion risks. Valid JSON can contain numbers JavaScript cannot safely round-trip; inspection shows the original token and a labeled Number preview without changing the document.

My ID changed value after parsing. What happened?

Native JavaScript JSON.parse uses IEEE-754 numbers and can round large IDs without a syntax error: 9007199254740993 becomes 9007199254740992. This inspector shows that risk from the original token. ToolsByUs value converters reject conversions that would lose digits, while Formatter and Minifier preserve the text. For portability, transmit exact IDs as strings or use an integer-capable parser such as Python's default JSON decoder.

What happens with duplicate keys?

The last occurrence wins, which is what nearly every parser does and what RFC 8259 declines to specify. It is worth knowing about rather than ignoring: if two systems in a request chain resolve duplicates differently, a payload can be validated against one interpretation and acted on under another, which is a genuine class of security bug.

Why does it reject my JSON with comments?

Because RFC 8259 has no comments, and the point of a strict parser is to tell you what an API will accept. If your file is a config — tsconfig.json, .eslintrc.json — it is JSONC, and the JSON Formatter accepts comments and trailing commas and can strip them for you.

Is 0.1 exactly 0.1 after parsing?

No, and this is not a JSON problem — it is binary floating point. 0.1 has no exact representation as a double in any language, which is why 0.1 + 0.2 is famously not 0.3. For currency, the standard answer is to carry integer minor units (pence, cents) or a decimal string, never a float.

Is my document sent anywhere?

No. Parsing and analysis run in your browser without uploading the document. After this page and its assets have loaded, the JSON inspection itself works without a network connection.

ToolsByUs team · How we check our tools