JSON Canonicalize (RFC 8785 JCS)

Because the specification says so, and the reason is practical: UTF-16 is how strings are represented in ECMAScript, Java and .NET, and JSON escape sequences are themselves UTF-16 code units. The two orders differ only for characters outside the Basic Multilingual Plane, which sort as a surrogate pair beginning U+D800–U+DBFF — so an emoji lands before U+E000 rather than after U+FFFF. An implementation that sorts by code point is deterministic but not JCS, and its signatures will not verify against one that is.

Sorting keys gives you a readable diff; canonicalizing gives you bytes to sign. JCS also removes all whitespace, rewrites every number in ECMAScript form, fixes the escaping of every string, encodes as UTF-8, and refuses invalid input. If you only want a tidy document to commit, the key sorter is simpler and does not rewrite your numbers.

Because JSON numbers are doubles here, and the canonical form is the double, not the text. 1.0 and 1e0 both become 1; 1E30 becomes 1e+30; 0.002 stays 0.002 but 2e-3 also becomes 0.002. A literal with more precision than a double holds is rounded on the way in, so 9007199254740993 comes out as 9007199254740992. The tool flags any literal whose spelling changes.

The specification requires it. A lone surrogate is not valid Unicode, so different implementations handle it differently — some escape it, some replace it, some throw — and any disagreement means the same document produces different bytes and a signature that verifies in one place and fails in another. Stopping is the only interoperable answer.

For signing, yes. JSON.parse keeps the last of two identical names and discards the first without a word, so a document can carry a value a verifier never sees while hashing to something that looks correct. RFC 8785 sidesteps it by requiring I-JSON input, which forbids duplicates outright — so they have to be caught in the text, before parsing.