{"id":15394,"date":"2026-03-29T09:22:46","date_gmt":"2026-03-29T07:22:46","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=15394"},"modified":"2026-03-29T09:22:48","modified_gmt":"2026-03-29T07:22:48","slug":"nobody-gets-fired-for-picking-json-but-maybe-they-should","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2026\/03\/29\/nobody-gets-fired-for-picking-json-but-maybe-they-should\/","title":{"rendered":"Nobody Gets Fired for Picking JSON, but Maybe They Should?"},"content":{"rendered":"\n

Nobody Gets Fired for Picking JSON, but Maybe They Should?<\/a><\/h2>\n\n\n\n

By Miguel Young de la Sota<\/a><\/p>\n\n\n\n\n\n\n\n\n\n\n\n

\n

Nobody Gets Fired for Picking JSON, but Maybe They Should?<\/a><\/h1>\n\n\n\n

JSON is extremely popular but deeply flawed. This article discusses the details of JSON\u2019s design, how it\u2019s used (and misused), and how seemingly helpful \u201chuman readability\u201d features cause headaches instead. Crucially, you rarely find JSON-based tools (except dedicated tools like jq<\/code>) that can safely handle arbitrary JSON documents without a schema\u2014common corner cases can lead to data corruption!<\/p>\n\n\n\n

What is JSON?<\/a><\/h2>\n\n\n\n

JSON is famously simple. In fact, you can fit the entire grammar on the back of a business card<\/a>. It\u2019s so omnipresent in REST APIs that you might assume you already know JSON quite well. It has decimal numbers, quoted strings, arrays with square brackets, and key-value maps (called \u201cobjects\u201d) with curly braces. A JSON document consists of any of these constructs: null<\/code>, 42<\/code>, and {"foo":"bar"}<\/code> are all valid JSON documents.<\/p>\n\n\n\n

However, the formal definition of JSON is quite complicated. JSON is defined by the IETF document RFC8259<\/a> (if you don\u2019t know what the IETF is, it\u2019s the standards body for Internet protocols). However, it\u2019s also<\/em> normatively defined by ECMA-404<\/a>, which is from ECMA, the standards body that defines JavaScript1<\/a><\/sup>.<\/p>\n\n\n\n

JavaScript? Yes, JSON (JavaScript Object Notation) is closely linked with JavaScript and is, in fact, (almost) a subset of it. While JSON\u2019s JavaScript ancestry is the main source of its quirks, several other poor design decisions add additional unforced errors.<\/p>\n\n\n\n

However, the biggest problem with JSON isn\u2019t any specific design decision but rather the incredible diversity of parser behavior and non-conformance across and within language ecosystems. RFC8259 goes out of its way to call this out:<\/p>\n\n\n\n

\n

reference<\/a><\/p>\n\n\n\n

Note, however, that ECMA-404 allows several practices that this specification recommends avoiding in the interests of maximal interoperability.<\/p>\n<\/blockquote>\n\n\n\n

The RFC makes many observations regarding interoperability elsewhere in the document. Probably the most glaring\u2014and terrifying\u2014is how numbers work.<\/p>\n\n\n\n

Everything is Implementation-Defined<\/a><\/h2>\n\n\n\n

JSON numbers are encoded in decimal, with an optional minus sign, a fractional part after a decimal point, and a scientific notation exponent. This is similar to how many programming languages define their own numeric literals.<\/p>\n\n\n\n

Presumably, JSON numbers are meant to be floats, right?<\/p>\n\n\n\n

Wrong.<\/p>\n\n\n\n

RFC8259 reveals that the answer is, unfortunately, \u201cwhatever you want.”<\/p>\n\n\n\n

\n

This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.<\/p>\n<\/blockquote>\n\n\n\n

binary64<\/code> is the \u201cstandards-ese\u201d name for the type usually known as double<\/code> or float64<\/code>. Floats have great dynamic range but often can\u2019t represent exact values. For example, 1.1<\/code> isn\u2019t representable as a float because all floats are fractions of the form n \/ 2^m<\/code> for integers n<\/code> and m<\/code>, but 1.1 = 11\/10<\/code>, which has a factor of 5 in its denominator. The closest float64<\/code> value is<\/p>\n\n\n\n

2476979795053773 \/ 2^51 = 1.100000000000000088817841970012523233890533447265625\n<\/code><\/pre>\n\n\n\n
Plaintext<\/a><\/p>\n\n\n\n
Of course, you might think to declare \u201call JSON values map to their closest float64<\/code> value\u201d. Unfortunately, this value might not be unique. For example, the value 900000000000.00006103515625<\/code> isn\u2019t representable as a float64<\/code>, and it\u2019s precisely between two exact float64<\/code> values. Depending on the rounding mode, this rounds to either or 900000000000<\/code> or 900000000000.0001220703125<\/code> .<\/p>\n\n\n\n
IEEE 754 recommends \u201cround ties to even\u201d as the default rounding mode, so for almost all software, the result is 900000000000<\/code>. But remember, floating-point state is a global variable implemented in hardware, and might just happen to be clobbered by some dependency that calls fesetround()<\/code> or a similar system function.<\/p>\n\n\n\n
Data Loss! Data Loss!<\/a><\/h2>\n\n\n\n
You\u2019re probably thinking, \u201cI don\u2019t care about such fussy precision stuff. None of my numbers have any fractional parts\u2014and there is where you would be wrong. The n<\/code> part of n \/ 2^m<\/code> only has 53 bits available, but int64<\/code> values fall outside of that range. This means that for very large 64-bit integers, such as randomly generated IDs, a JSON parser that converts integers into floats results in data loss.<\/em> Go\u2019s encoding\/json<\/code> package does this, for example.<\/p>\n\n\n\n
How often does this actually happen for randomly-generated numbers? We can do a little Monte Carlo simulation to find out.<\/p>\n\n\n\n
package main\n\nimport (\n\t"fmt"\n\t"math"\n\t"math\/big"\n\t"math\/rand"\n)\n\nconst trials = 5_000_000\nfunc main() {\n\tvar misses int\n\tvar err big.Float\n\tfor range trials {\n\t\tx := int64(rand.Uint64())\n\t\ty := int64(float64(x)) \/\/ Round-trip through binary64.\n\t\tif x != y {\n\t\t\tmisses++\n\t\t\terr.Add(&err, big.NewFloat(math.Abs(float64(x - y))))\n\t\t}\n\t}\n\n\terr.Quo(&err, big.NewFloat(trials))\n\tfmt.Printf("misses: %d\/%d, avg: %f", misses, trials, &err)\n}\n\n\/\/ Output:\n\/\/ misses: 4970572\/5000000, avg: 170.638499\n<\/code><\/pre>\n\n\n\n
Go<\/a><\/p>\n\n\n\n
It turns out that almost all randomly distributed int64<\/code> values are affected by round-trip data loss. Roughly, the only numbers that are safe are those with at most 16 digits (although not exactly: 9,999,999,999,999,999, for example, gets rounded up to a nice round 10 quadrillion).<\/p>\n\n\n\n
How does this affect you? Suppose you have a JSON document somewhere that includes a user ID and a transcript of their private messages with another user. Data loss due to rounding would result in the wrong user ID being associated with the private messages, which could result in leaking PII or incorrect management of privacy consent (such as GDPR requirements).<\/p>\n\n\n\n
This isn\u2019t just about your<\/em> user IDs, mind you. Plenty of other vendors\u2019 IDs are nice big integers, which the JSON grammar can technically accommodate and which random tools will mangle. Some examples:<\/p>\n\n\n\n