JSON guides
These are written by the maintainer of the formatter on this site, and they aim at the parts of JSON that surprise people rather than at restating the manual. Claims are produced by running code, and where something was not executed it is labelled as such — the gap between "documented" and "measured" is usually where the bugs live.
-
JSON number precision — why 19-digit IDs come back wrong
All integers above
2**53are silently rounded by the most common parser in the world, and the standard permits it. Measured across JavaScript, Python and Ruby — which disagree — plus the two-year-old round-trip recipe that preserves the digits. -
Why "Unexpected token '<'" means your API returned HTML
The response was an HTML error page, a login redirect or a proxy block page — not JSON. How to prove it in one request, and how to stop the real cause instead of stripping the HTML and hoping.
How these are written
Output, error strings and version-specific behaviour are produced by running the code and pasting the result, and the runtime versions are named so the reader can reproduce it. Where a claim was not executed — a setting in a language that was not on the machine — the article says so rather than presenting documentation as a measurement.
Error messages are quoted exactly as the engine prints them, so a search for the text you actually saw lands on an explanation rather than on a guess. Where the wording changed between engine versions, both forms are given, because the same underlying defect reports differently in Node 20 than it did in Node 16.
Stuck on something that is not covered here? The validator reports the line and column of any syntax error you paste into it, and you can suggest a topic — a parser message with no written-up cause, or a JSON behaviour you have not seen explained, is the most useful kind of suggestion.