A formatter can make a payload readable, but readability is not proof that the payload is acceptable to the system receiving it. JSON review works best when syntax, data-model assumptions, and the eventual consumer are checked separately.
Start with strict JSON syntax
RFC 8259 defines JSON objects, arrays, numbers, strings, and the three literal names true, false, and null. Common JavaScript conveniences are not part of JSON: comments, trailing commas, single-quoted strings, undefined, NaN, and hexadecimal numbers should fail a strict parser.
This input looks harmless in a permissive editor but is not valid JSON:
{
"job": "daily-import",
"enabled": true,
}
Remove the trailing comma before doing any other transformation. Formatting an invalid payload into a more attractive invalid payload only delays the useful error.
Check values the parser cannot judge for you
Syntax validation cannot determine whether an identifier should be a string, whether a timestamp is in the expected timezone, or whether a number exceeds the precision of the next runtime. RFC 8259 notes that interoperable number handling is safest when software does not assume unlimited range or precision. A 20-digit account identifier may therefore need to remain a quoted string.
Object member names are expected to be unique for interoperable behavior. When the same name appears twice, libraries differ: some keep the last value, some preserve every pair, and some reject the object. Treat a duplicate name as a review failure even if the current parser accepts it.
Use a repeatable review sequence
- Preserve the original payload so a transformation can be compared against it.
- Parse with a strict JSON parser and stop on the first syntax error.
- Format using a consistent indentation level; do not sort keys unless ordering is an explicit requirement.
- Inspect identifiers, timestamps, nullability, number ranges, and arrays that mix unrelated value types.
- Compare the formatted result with the original data model, not merely the text layout.
- Minify only after the reviewed version is accepted.
A small test fixture catches several mistakes
Use a fixture that contains Unicode, an empty collection, a null, a decimal, and a large identifier:
{
"requestId": "9007199254740993",
"label": "नमस्ते",
"ratio": 0.125,
"optional": null,
"items": []
}
After formatting and minifying, parse both outputs and compare their values. The request ID must still be a string, the Unicode label must be unchanged, and no field may disappear simply because it is empty or null.
What formatting does not prove
A valid JSON document can still violate an API schema, contain an expired timestamp, expose a secret, or use the wrong units. Schema validation and application-level checks belong after syntax validation. For untrusted input, also apply size, depth, and rate limits before parsing; a valid but extremely deep document can still exhaust resources.