RFC 8259 separates what a text must look like from what software must do with one. These are its rules for the software.
Parsers
A parser turns JSON text into another representation. It must accept every text that conforms to the JSON grammar. It may also accept forms and extensions that are not JSON, which is how comments and trailing commas come to work in some tools.
An implementation may set limits on:
Generators
A generator produces JSON text. Its output must strictly conform to the JSON grammar.
What stays interoperable
The grammar allows some things that RFC 8259 warns will not survive every reader. To be safe, a writer should avoid:
- repeated names in an object
- depending on member order
- numbers beyond what a 64-bit float can hold
- unpaired surrogates in strings
- a byte order mark
Security
JSON is a subset of JavaScript syntax, so it is tempting to read it with JavaScript’s
eval(). RFC 8259 section 12 calls that generally an unacceptable security
risk, because the text could contain executable code along with data declarations, and
says the same applies to similar functions in any language whose syntax JSON matches. A
real JSON parser never runs anything it reads.
The same section points out that U+2028 and U+2029 are legal in JSON but not in JavaScript, as described on the strings page.