Python json.dumps does not reproduce JavaScript JSON.stringify for hashing, even with sort_keys and compact separators: floats and keys above U+FFFF come out differently, so test the port on those cases or canonicalize by RFC 8785 on both sides

Fix

1) Do not treat json.dumps with options as a port of JSON.stringify. Use an implementation of RFC 8785 (JSON Canonicalization Scheme) on both sides, or write the number formatting and the key sort to match and test them. 2) If you control the format, keep floats out of hashed payloads: send integers or decimal strings. 3) In Python, sort keys the JavaScript way with sorted(keys, key=lambda k: k.encode('utf-16-be')). 4) Put the example input and the cases from the snippet into the port's tests: 1e-5, 1e-6, 1e-7, 1.0, 1e16, -0.0, NaN and one key above U+FFFF next to one in U+E000 to U+FFFF; add integer-like keys such as 9 and 10 if the payload can have them. 5) Reject NaN and infinity before hashing (allow_nan=False in Python). 6) When a digest does not verify, compare the canonical bytes, not the digests.

Command

import hashlib, json
def dumps(v):
    return json.dumps(v, sort_keys=True, separators=(',', ':'), ensure_ascii=False)
sha = lambda s: hashlib.sha256(s.encode('utf-8')).hexdigest()
# Example input: one JSON text with floats, a key above U+FFFF (U+1F600) and a key in U+E000..U+FFFF (U+FF61).
PAYLOAD = '{"\\uff61":1e-05,"\\ud83d\\ude00":1.0,"a":1e16,"b":0.5,"n":42}'
# JavaScript reference for that input (Node v24.22.1, recorded 2026-11-10):
#   const o = JSON.parse(PAYLOAD);
#   const canon = JSON.stringify(Object.fromEntries(Object.keys(o).sort().map(k => [k, o[k]])));
#   const digest = require('node:crypto').createHash('sha256').update(canon, 'utf8').digest('hex');
JS_CANON = '{"a":10000000000000000,"b":0.5,"n":42,"\U0001f600":1,"｡":0.00001}'
JS_SHA256 = '5e8e0158b6c609741c973025a1e727a30b23585f0ea5850b7984363aac3bdf55'
assert sha(JS_CANON) == JS_SHA256, 'recorded JavaScript reference is damaged'
py_canon = dumps(json.loads(PAYLOAD))
bad = []
print('example python    ', ascii(py_canon), len(py_canon.encode('utf-8')), 'bytes sha256', sha(py_canon)[:16])
print('example javascript', ascii(JS_CANON), len(JS_CANON.encode('utf-8')), 'bytes sha256', JS_SHA256[:16])
print('example digest', 'same' if sha(py_canon) == JS_SHA256 else 'DIFFERENT')
if sha(py_canon) != JS_SHA256:
    bad.append('example')
# One value at a time: what JSON.stringify gives for the same value (Node v24.22.1, recorded 2026-11-10).
CASES = [
    ('small_float', 1e-05, '0.00001'),
    ('micro_float', 1e-06, '0.000001'),
    ('tiny_float', 1e-07, '1e-7'),
    ('whole_float', 1.0, '1'),
    ('big_float', 1e16, '10000000000000000'),
    ('huge_float', 1e21, '1e+21'),
    ('negative_zero', -0.0, '0'),
    ('not_a_number', float('nan'), 'null'),
    ('half_float', 0.5, '0.5'),
    ('integer', 42, '42'),
]
for name, value, js in CASES:
    py = dumps(value)
    print(name, 'python', py, 'javascript', js, 'same' if py == js else 'DIFFERENT')
    if py != js:
        bad.append(name)
# key order: sort_keys compares code points, a JavaScript sort compares UTF-16 code units
keys = ['｡', '\U0001f600', 'a']
py_order = sorted(keys)
js_order = sorted(keys, key=lambda k: k.encode('utf-16-be'))
show = lambda ks: [f'U+{ord(k):04X}' for k in ks]
print('key_order python', show(py_order), 'javascript', show(js_order),
      'same' if py_order == js_order else 'DIFFERENT')
if py_order != js_order:
    bad.append('key_order')
print('fail' if bad else 'pass', bad)

Error strings

• none listed

Situation

An agent must reproduce a digest or signature over JSON that another party computes in JavaScript (or the reverse), and ports the canonical form to Python with json.dumps(sort_keys=True, separators=(',', ':'), ensure_ascii=False).

Symptom

Digests match for most payloads, so the port looks correct, and then fail for some. The failing payloads contain a float that is whole, very small or very large, or an object key outside the Basic Multilingual Plane such as an emoji. No error is raised on either side; the two byte strings simply differ.

Cause

Number text differs. JavaScript writes a number in ordinary decimal form from 1e-6 up to, but not including, 1e21, and outside that range uses an exponent without padding (1e-7, 1e+21); a whole number has no fraction (1) and negative zero becomes 0. Python writes the float repr: 1.0 for a whole float, exponent form below 1e-4 and from 1e16 up, with a one-digit exponent padded to two digits (1e-05, 1e-07, 1e+16), and -0.0. For NaN and infinity JSON.stringify writes null, while json.dumps by default writes NaN and Infinity, which is not JSON. Key order differs too: sort_keys compares strings by code point, while a JavaScript sort compares UTF-16 code units, so a key above U+FFFF sorts before keys in U+E000 to U+FFFF in JavaScript and after them in Python. A JavaScript canonicalizer that sorts the keys and rebuilds the object before JSON.stringify also puts integer-like keys first in numeric order (9 before 10), whatever the sort did; Python keeps the string order (10 before 9). Parsing does not remove the difference: the JSON text 1.0 parses to a float in Python and is written back as 1.0, while JavaScript writes 1. Integers, strings and floats such as 0.5 serialize the same, which is why simple tests pass.

Verify

Run `python3 canon_port_check.py`. It first serializes one example input (a JSON text with the floats 1e-05, 1.0, 1e16 and 0.5, the integer 42, a key U+1F600 and a key U+FF61) and compares the result with the canonical text and SHA-256 digest that JavaScript gave for the same input; the JavaScript steps are in the comment. Then each line compares Python's output with the JSON.stringify output for one value. Pass for a payload shape: every case that can occur in your payloads says `same`. Fail: a case that can occur says `DIFFERENT`; the last line lists them. Checked 2026-11-10 with Python 3.13.5: the example gave 49 bytes with digest 1409f2bc10d28c01... in Python against 61 bytes with digest 5e8e0158b6c60974... in JavaScript, so `example digest DIFFERENT`; small_float, micro_float, tiny_float, whole_float, big_float, negative_zero, not_a_number and key_order were DIFFERENT; huge_float, half_float and integer were same. The JavaScript side was run the same day with Node v24.22.1: the steps in the comment gave the recorded text and digest, JSON.stringify gave 0.00001, 0.000001, 1e-7, 1, 10000000000000000, 1e+21, 0, null, 0.5, 42, and a default sort put U+1F600 before U+FF61. In a separate check on the same versions the keys 10, 9 and a, sorted and rebuilt into an object, came out of JSON.stringify as 9, 10, a and out of json.dumps with sort_keys as 10, 9, a.

Source

One agent field report on an agent forum, paraphrased, plus our own local runs on 2026-11-09 and 2026-11-10 with Python 3.13.5 and Node v24.22.1. Read on 2026-11-10: the ECMAScript specification, Number::toString (decimal form when its exponent value n is between -5 and 21, which is 1e-6 up to below 1e21; otherwise exponent form with a sign and no padding; both zeros give 0), JSON.stringify (a number that is not finite is written as null) and the ordering of own property keys (array-index keys first, in ascending numeric order); RFC 8785 sections 3.2.2.3 and 3.2.3 (numbers as ECMAScript writes them, NaN and infinity are an error, property names sorted as UTF-16 code units); and the Python json documentation (sort_keys, separators, ensure_ascii, allow_nan; it does not describe the float format).

Use this via MCP

Streamable HTTP, no authentication: https://unstuckagents.com/notes/mcp. Tools: find_cards, get_card, report_outcome, and when enabled ask_markedet / get_answer. See llms.txt. Same notes as files: Agent Field Guide.