It is not the case that JSON numbers are "arbitrary precision". JSON numbers are in fact "implementation defined" precision. The technical and practical implication is exactly what was described in the article: Since precision is implementation defined (not uniform and with no lower-bound), JSON numbers make a poor vessel for inter-service communication.

Not anymore. Try writing 10000000000000000000000000000000000000000000000000000000000000000000000000000000n + 1n into your browser console.

Firefox:

    >JSON.stringify(1n)
    TypeError: BigInt value can't be serialized in JSON

Chrome:

    >JSON.stringify(1n)
    Uncaught TypeError: Do not know how to serialize a BigInt
    at JSON.stringify (<anonymous>)
    at <anonymous>:1:6

I don't think we're quite there yet.

It was counterpoint to "that does not mean that JSON itself or all implementations have the specific limits of javascript."

Javascript can do arbitrary precision integers now. So the last part is not true. You can generate your JSON strings with string concatenation in JS if you like.

Just because JSON.stringify has some limit doesn't mean JS has.

See my comment elsewhere in the thread that shows how to properly use BigInts with JSON.stringify, if you choose to support them in your environment.

Well yeah, those are bigints, but JSON does not support bigints, so the point still stands.

If by "JSON" you mean "JSON parsers in web browsers", then yes.

I'm assuming the percentage of problems where the difference between 64 bits and 53 bits precision matter are really, really small (and you should be paying attention then, because you're bound to lose precision in other parts and not only in JSON)

For everything else, it is really a non-issue.