Collects the most frequently asked questions about the tools on this site and about the JSON specification, grouped by scenario, with an answer you can act on directly instead of a vague conclusion.
25 articlesIs data uploaded, how large a file works, is anything stored locally, why Chinese turns into escapes: ten questions spelling out the real boundaries of an online JSON tool.
Whether comments are allowed, why a trailing comma errors, whether keys need quotes, why 9007199254740993 changes — twelve conclusions, each checked against RFC 8259.
Whether path queries should use JSONPath or Pointer, how to choose between Patch and Merge Patch, what Schema can block, and how to pick a draft version — all explained in one pass.
Why a JSON file of tens of MB will not open, how expensive deep cloning is, how to prevent __proto__ pollution, and where XSS gets in — ten first-aid conclusions arranged by symptom.
Naming style, time formats, null semantics, enum shapes, config formats, fixture organization, and merge conflicts — twelve trade-offs that teams genuinely argue about.
RFC 8259 has no comment syntax, so // and block comments make JSON.parse throw. Use JSON5 or JSONC, a _comment field, a Schema description, or YAML instead.
Trailing commas are legal in JavaScript object literals and fatal in JSON. Here is the exact error, the RFC 8259 grammar that causes it, and three fixes that actually hold.
A UTF-8 BOM is three invisible bytes, so JSON.parse fails on the first character and reports line 1 column 1, which makes the file look empty or truncated.
JSON has only decimal number literals. JSON.stringify turns NaN and Infinity into null without warning, which is why "the number field is sometimes null" keeps showing up in production.
Integers above 2^53-1 lose precision in JSON.parse. Snowflake IDs, order numbers and database bigints all hit this, so keep them as strings end to end.
A \u4e2d\u6587 escape is legal Unicode, not an encoding failure. Real mojibake looks different, and telling them apart decides what you actually need to fix.
Strict supersets in order: JSONC adds comments; JSON5 adds single quotes, unquoted keys, trailing commas and hex numbers. Choosing wrong breaks an API, not your editor.
JSON delimits with braces and YAML with indentation: machines get JSON, humans editing config get YAML. Comments, anchors and multi-document structure do not survive.
JSON Pointer is a unique address you can store as a key; JSONPath is a query language. Using the wrong one breaks config updates or reinvents a broken JSONPath.
Schema governs structure and types, not business meaning. It stops missing fields, wrong types and out-of-range enums, while rules like amount over zero stay in code.
2020-12 is current and adds $defs, prefixItems and unevaluatedProperties, but many tools still speak draft-07 only. Choose by what your whole toolchain supports.
json-schema-to-typescript and quicktype emit a .d.ts in one command, but it is a draft: optionality, unions, additionalProperties and dates need a human pass.
Optimising in the wrong order makes every library swap useless. Measure network, parse and render separately, then cut parses, shrink payloads and stream.
JSON.parse treats __proto__ as an ordinary key; the damage happens in a recursive merge that writes to Object.prototype, so every object inherits attacker properties.
JSON never executes by itself. XSS happens at the moment you treat it as HTML — server-side string concatenation, frontend innerHTML, or inlining JSON straight into a script tag.
You do not need to read a privacy policy to find out. Open the network panel, try the page offline, and refresh to see whether anything persisted. Two minutes, three checks, no trust required.
There is no fixed limit; the constraint is your tab's memory budget. A 20MB file typically becomes 60–100MB once parsed, and the highlighted DOM can double that again.
Bare objects are clean until you need metadata; full envelopes are safe but verbose. For most projects use HTTP status for outcomes and a stable envelope for data.
Epoch numbers and ISO strings each have trade-offs, but mixing them is what actually breaks things. Use ISO 8601 with an offset, store UTC, render in the user's time zone.
`null` says the field exists with no value; omitting says the field does not exist. PATCH bodies, config merging and form prefill are where the difference bites.
