JSON syntax, formatting and common errors

Formatting changes layout, not meaning

JSON represents strings, numbers, booleans, null, arrays and objects. Indentation is not required. Pretty-printing adds whitespace between structural tokens; minification removes that whitespace. Spaces inside quoted strings remain data and must not be collapsed.

UtilityPilot keeps raw string and number tokens while changing structural whitespace. That avoids a parse-to-floating-point step that could round a long numeric identifier.

Common syntax failures

{"name":"Ada","active":true}

This is valid. A comma after true is not. Single quotes around name are not JSON string syntax. Comments and undefined are also not permitted. A reported line and column points near the unexpected token; inspect the preceding punctuation as well.

A missing quote can make the parser appear to fail much later, because later text was interpreted as part of the string.

Duplicate keys and long numbers

{"id":1,"id":2}
{"id":9007199254740993}

The first example is rejected here because duplicate-key handling differs between consumers. The second is formatted without altering its number spelling. Some applications will still round that number when reading it, so use a quoted identifier when the data contract allows one.

Syntax is only the first check

A JSON object can be syntactically valid and still fail an API because a required field is missing or has the wrong type. This formatter does not validate an application schema. It also rejects input above 5 MiB or nesting deeper than 50 levels to bound processing.

For CSV-to-JSON conversion, keep strings unless the destination explicitly expects typed values. Then compare the output against that destination’s documented contract.