Markdown has too many specs. CSV has one that nobody agreed to follow. JSON is supposed to be the happy ending: a grammar small enough to print on a business card, standardized twice over, and elevated to a full Internet Standard.
\nIt is, and the parsers still disagree with each other about what your file says.
\nNot about whether it’s valid. About what the values are.
\nHere is a JSON document. It is unambiguously valid by every specification.
\n{"id": 9007199254740993}\nThree parsers, on the same machine (Node 24.13.0, Python 3.13.12, jq 1.8.2), on those exact bytes:
\nnode : {"id":9007199254740992}\npython : {"id": 9007199254740993}\njq : {"id":9007199254740993}\nNode gave back a different number than the one in the file. It didn’t error, didn’t warn, didn’t round-trip. The last digit changed from 3 to 2.
\nThe reason is that JSON’s grammar allows a number to be any sequence of digits, but JavaScript represents every number as an IEEE 754 double. Above 2⁵³ the integers stop being exactly representable, and Number.MAX_SAFE_INTEGER is 9007199254740991. Our value is two past it.
This is not a JavaScript bug. Node is behaving exactly as specified. The specification simply declines to say how many digits a number may have, and every implementation answers that question with whatever its host language does.
\nThose version numbers matter, which is its own version of the problem. jq only began preserving decimal literals in 1.7, whose release notes list “use decimal number literals to preserve precision.” Run that same file through jq 1.6 and it goes through a double and hands you Node’s answer. The tool doesn’t just disagree with other parsers. It disagrees with its own past self.
If you have ever wondered why APIs send 64-bit IDs as strings, this is why. Twitter’s snowflake IDs, database primary keys, anything above 2⁵³ has to be quoted or it silently degrades in half the ecosystem.
\n{"role": "user", "role": "admin"}\nRFC 8259 says names within an object should be unique. Should, not must. And it goes on to describe what happens otherwise as varying between implementations.
\nIn practice:
\nnode : {"role":"admin"}\npython : {"role": "admin"}\njq : {"role":"admin"}\nAll three take the last one. That’s the common behavior, and it is not required.
\nThe RFC itself spells out all three possibilities:
\n\n\nWhen the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.
\n
That third option, keeping both, isn’t even representable in most languages’ object types. Nicolas Seriot tested parsers across a dozen languages against cases like this one and concluded there are “no two parsers that agree on what is wrong and what is right.”
\nPython will show you both if you ask:
\nraw pairs: [('role', 'user'), ('role', 'admin')]\nThe pairs are all there in the document. Choosing one is an interpretation layered on top of parsing.
\nNow put two parsers in one system. Apache CouchDB did, and it became CVE-2017-12635.
\nCouchDB used an Erlang parser for authentication and a JavaScript engine for the validation that runs when a document is written. The Erlang parser resolved duplicate keys to the first value. The JavaScript engine resolved them to the last. So a request like this:
\n{"roles": ["_admin"], ..., "roles": []}\nwas read by the write-time validation as an ordinary unprivileged user, because it saw the last roles key and found it empty. It was then read by the authentication layer as an administrator, because that saw the first one. Non-admin users could grant themselves admin.
CouchDB’s fix was to change the Erlang parser to take the last key, matching JavaScript. Not because last-wins is correct, but because agreeing is correct.
\nThis is the JSON version of the ZIP two-index problem from a few posts back. When a format permits two answers to the same question, the gap between two components is where the vulnerability lives.
\nJSON has no way to express not-a-number or infinity. The grammar has no room for them.
\nPython’s standard library writes them regardless:
\n>>> json.dumps({"a": float("nan"), "b": float("inf")})\n'{"a": NaN, "b": Infinity}'\nThat output is not JSON. It’s Python’s default behavior, and it produces a file that other parsers reject or mangle. Feeding those exact bytes onward:
\nnode : SyntaxError - Unexpected token 'N', "{"a": NaN, "b": "... is not valid JSON\njq : {"a":null,"b":1.7976931348623157e+308}\nNode’s response is correct and useful: this is not JSON, here’s where it broke.
\njq’s response is the one that should worry you. It accepted the invalid document and made up values. NaN became null. Infinity became 1.7976931348623157e+308, the largest finite double. No error, no warning. If that ran in the middle of a data pipeline you would get numbers out the other end, and they would be wrong in a way no downstream check is likely to catch.
The same divergence shows up with a merely-enormous exponent, which is valid JSON:
\ninput: {"v": 1e999}\n\nnode : {"v":null}\npython : {'v': inf}\njq : {"v":1E+999}\nThree parsers, one valid input, three different values. Node converts to infinity then serializes it as null because it can’t represent infinity on the way out. Python gives you a float infinity object. jq preserves the literal.
JSON’s specifications are good, and they are small. The problem is that they specify syntax, and almost every failure above is about semantics.
\nThe grammar tells you 9007199254740993 is a well-formed number. It does not tell you what number it is, because that would require committing to a numeric model, and committing to a numeric model would have meant excluding some language from implementing JSON natively. The looseness is why JSON is everywhere. It is also why the same bytes mean different things in different places.
The standards process eventually acknowledged this. RFC 7493 defines I-JSON, a restricted profile that closes these holes: no duplicate names at all, numbers that should not exceed what an IEEE 754 double holds exactly, high-precision values recommended to travel as strings, and mandatory UTF-8. Only the duplicate-name rule is a hard MUST NOT, which tells you something about how much of this was still negotiable in 2015.
I-JSON is what most people think JSON already is. It exists as a separate document precisely because JSON isn’t that.
\nallow_nan=False to be honest.JSON did not fail. It succeeded so completely that it got implemented hundreds of times by people reading a short document, and a short document leaves a lot of decisions to the reader. The format that’s easy to implement is the format that gets implemented differently everywhere.
\nThat’s the same sentence I could have written about Markdown, and about CSV. The pattern across this whole series is that a format’s ambiguities don’t stay theoretical. They become somebody’s incident.
\n\n\n", "date_published": "2026-08-20T10:00:00-05:00", "url": "https://llbbl.blog/2026/08/20/your-json-parser-disagrees-with.html", "tags": ["Programming","Json","File-formats","Parsing","Interoperability"] } ] }I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.
\n