Developer Tools · Developer
JSON Canonicalization Scheme Tester (RFC 8785/JCS)
RFC 8785 (JSON Canonicalization Scheme / JCS) online tester. Sorted keys, SHA-256/384/512 hashes for deterministic JSON hashing, JWS signatures and HMAC — in-browser, no data sent.Runs in your browser
Last updated:
How to Use
Expand how to useCollapse how to use
- 1
Enter JSON
Type or paste the JSON data you want to canonicalize into the text area.
- 2
Review Results
The canonicalized JSON (RFC 8785) and SHA-256/SHA-384/SHA-512 hashes are displayed automatically.
- 3
Copy Results
Click the copy button next to the canonicalized result or hash values to copy them to your clipboard.
JSON Input
About JSON Canonicalizer
JSON Canonicalizer lets you test your JSON against RFC 8785 (JSON Canonicalization Scheme / JCS) in the browser. It sorts object keys by UTF-16 code unit order, strips whitespace, and normalizes numbers to produce byte-identical canonical JSON — just as the RFC 8785 spec requires. SHA-256, SHA-384, and SHA-512 hashes are shown so you can debug JWS signatures, HMAC mismatches, and deterministic cache keys without switching tools. Unlike rfc-editor.org (which hosts the specification text), this tool runs the JCS algorithm interactively — paste JSON and see canonical output instantly.
Key Features
- RFC 8785 (JCS) compliant JSON canonicalization
- Object key sorting by UTF-16 code unit order
- Simultaneous SHA-256/SHA-384/SHA-512 hash generation
- JSON syntax error display with line numbers
- Individual copy buttons for canonicalized result and hash values
Use Cases
- Generate a canonical form of a JWS (JSON Web Signature) payload to verify that your signing implementation matches the RFC 8785 spec
- Debug webhook HMAC signature mismatches caused by different JSON key ordering between the sender and receiver
- Compute a deterministic SHA-256 cache key for a JSON configuration object that may be serialized with different key orders by different runtimes
- Verify that two JSON objects from different services are semantically identical by comparing their canonical hashes
- Produce canonical JSON for audit log entries that must be tamper-evident and independently verifiable
FAQ
What is RFC 8785 (JSON Canonicalization Scheme / JCS)?
RFC 8785 is the IETF standard that defines the JSON Canonicalization Scheme (JCS), a deterministic algorithm for normalizing JSON data. It specifies rules — sorted object keys (UTF-16 code unit order), whitespace stripping, and number normalization — for producing identical byte sequences from the same logical data, making it suitable for digital signatures, HMAC, and content-addressed hashing.
Is this tool compliant with the official RFC 8785 specification?
Yes. This tool implements the RFC 8785 / JSON Canonicalization Scheme (JCS) algorithm as published by the IETF on rfc-editor.org. It is not an official IETF or RFC Editor product, but is designed to produce canonical JSON that matches the spec for valid JSON inputs. For the authoritative specification text, refer to rfc-editor.org/rfc/rfc8785.
How is RFC 8785 used for deterministic JSON hashing?
Deterministic JSON hashing requires byte-identical input regardless of how a JSON object was originally serialized. RFC 8785 (JCS) produces that canonical byte form so that piping it into SHA-256/384/512 yields the same digest across services, runtimes, and languages. This is exactly how JWS detached signatures, HMAC webhook verification, and content-addressed cache keys stay reproducible — even when senders and receivers use different JSON libraries.
What is JCS (JSON Canonicalization Scheme)?
JCS stands for JSON Canonicalization Scheme, defined in RFC 8785. It specifies a deterministic algorithm for serializing JSON: object keys are sorted by UTF-16 code unit order, whitespace is removed, and numbers are normalized. The result is a canonical byte sequence that can be hashed or signed reproducibly, regardless of how the JSON was originally formatted or which runtime produced it.
Which libraries implement RFC 8785 (JavaScript, Java, Python, Go, .NET)?
RFC 8785 itself lists verified open-source implementations in Appendix G: the canonicalize package on npm (JavaScript/Node.js), erdtman/java-json-canonicalization (Java), and the cyberphone/json-canonicalization repository with Go, .NET/C#, and Python 3 ports. Paste your library's output into this tool to cross-check that both produce byte-identical canonical JSON.
How do I verify that my JCS implementation or library output is correct?
Canonicalize the same JSON here and compare the results byte for byte — or simply compare the SHA-256 hashes shown below the output. For edge cases, RFC 8785 ships test data in its appendices: the IEEE 754 number serialization table in Appendix B covers exponent formatting and zero handling, and Section 3.2.3 provides a UTF-16 key sorting example including emoji and control characters.
How does this differ from JSON.stringify()?
JSON.stringify() depends on V8's insertion order for object keys and varies whitespace based on arguments — two logically identical objects serialized by different services or runtimes will produce different byte sequences and different HMAC signatures. RFC 8785 sorts keys by UTF-16 code unit order, removes all whitespace, and normalizes number representation to guarantee byte-identical output regardless of origin.
Why only SHA-256/SHA-384/SHA-512?
Since canonical JSON hashes are used for tamper detection and digital signatures, only the cryptographically secure SHA-2 family is supported. MD5 and SHA-1 are vulnerable to collision attacks and are unsuitable for this use case.
Is my input data sent to a server?
No. Canonicalization and hashing use the browser's Web Crypto API locally. JSON payloads containing private keys, webhook secrets, or sensitive configuration are never transmitted.