A formatter changes the layout of a document. It should not silently change the account id inside it. That sounds obvious until an implementation parses every JSON number into a binary floating-point value and serializes the result. An output document can look perfectly valid while containing a different identifier.
This workshop takes about fifteen minutes. Its deliverable is a small fixture set that states what your transformation must preserve, what it should reject and what the next consumer must verify. Start with sample data, never real customer records.
Define the exact transformation
The JSON workspace changes whitespace while preserving original string and number tokens and object member order. It rejects duplicate decoded object keys instead of choosing one value. It does not sort keys, canonicalize JSON, validate a schema or convert a number into a more convenient representation.
That contract matters when reviewing an export. Semantic equivalence for an application, byte identity for a signature and visual readability are three different requirements. Decide which one you need before choosing the operation.
Run a precision fixture
{"id":9007199254740993,"price":0.10000000000000001,"negativeZero":-0,"scale":1e400}Format the fixture, then minify it. Each number spelling must remain exactly as supplied. The exponent is deliberately extreme: preserving its token does not promise that a database or programming language can represent its value. Copying the output into another tool may still lose precision.
Next, select /id with JSON Pointer. The selected output must still be 9007199254740993. Change the input and check that the previous output clears. A stale output left beside edited input can mislead a reviewer even when the parser is correct.
Make ambiguity fail visibly
{"id":1,"\u0069d":2}These two key spellings decode to the same name. The workspace must report a duplicate instead of returning either value. Repeat the check with a duplicate inside a nested object. This is a deliberate strict policy for the tool, not a claim that every JSON parser rejects duplicates. RFC 8259 explains the interoperability problem when names are not unique.
Check paths that are easy to misread
{"a/b":{"~key":false},"":null,"items":[0,1]}Select /a~1b/~0key and expect false. Select / and expect the null value under the empty property name. A blank pointer selects the whole document. /items/01 is rejected as an array index; an array lookup is not a free-form numeric conversion. See RFC 6901 for the pointer syntax.
Carry the checks into your own system
Keep these fixtures alongside the code that imports, transforms or exports your data. Test the boundary after the next consumer reads the result, not only immediately after formatting. If your contract uses identifiers as strings, enforce that type at the API boundary and reject accidental numeric values rather than relying on a display tool to repair them.
The workspace caps input at 200 KB, nesting at 100 levels and values at 20,000. Limits are part of a usable parser contract: a small browser utility should fail clearly on an oversized document. Passing the fixtures establishes these specific transformation behaviors; it does not certify arbitrary downstream data pipelines.