JSON解析
JSON Parser parses a document to RFC 8259 in your browser and reports what it actually contains: how many values of each type, how deep the structure goes, and what each type becomes in your language. It also flags the integers that silently lose precision when parsed as a double.
このツールの画面は英語表記です。
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 reports an error instead of 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, and RFC 8259 places no limit on its magnitude, but almost every parser represents it as an IEEE-754 double. That gives exact integers only up to 253−1. An ID of 9007199254740993 parses without complaint and comes back as 9007199254740992, and nothing anywhere reports an error. Those literals are detected from the source text — by the time the value is parsed the precision is already gone — and listed explicitly.
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 }What it parses to
2 values · depth 1 · 2 distinct keys number 2 → number (IEEE-754 double) Precision loss: 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?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Grammar | RFC 8259 | strict | No comments, no trailing commas, no single quotes, no unquoted keys, no NaN or Infinity. A document that parses here is one an API will accept; JSON5 and JSONC are deliberately rejected. |
| Trailing content | rejected | — | 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 precision | IEEE-754 | flagged | Integers beyond 2^53-1 are listed with the value they actually become. Detected from the source text, because after parsing the original digits no longer exist anywhere. |
| Duplicate keys | last 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 depth | iterative | no limit | The 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. |
| Unicode | UTF-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 size | bytes | 8 MB | Main-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 answers whether the document parses and where it breaks if not, with a caret on the offending character and a one-click repair. This one assumes it parses and tells you what came out: type counts, depth, distinct keys, the language mapping, and any integers that lost precision. Use the validator when something is broken and this when something is valid but behaving oddly.
My ID changed value after parsing. What happened?
It exceeded 2^53-1 and was parsed as an IEEE-754 double, which cannot represent every integer above that. 9007199254740993 becomes 9007199254740992 with no error anywhere. This tool lists those literals explicitly. The fixes are to transmit large IDs as strings, or to use a parser that maps integers to a big-integer type — Python does this natively; Go, Java and C# need configuring.
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 the tab you already have open. Open the Network panel and paste one — nothing carrying it leaves, and every tool here keeps working with the network disconnected entirely.