How to format and validate JSON
Learn the difference between valid and readable JSON, decode common parser errors, and handle configuration data safely.
JSON is deliberately small and strict. That makes it dependable for exchanging data, but it also means a missing quote or trailing comma can invalidate a whole document. A good workflow validates first, formats second and reviews the data rather than trying to execute it.
Validation and formatting solve different problems
Validation asks whether text follows JSON syntax. Formatting changes the whitespace around an already valid value so people can read it more easily. A formatter cannot safely guess whether a missing comma, quote or bracket was intended, so syntax errors should be fixed deliberately.
Minification is another whitespace transformation. It removes indentation and line breaks that JSON parsers do not need. It can reduce transfer size, but it does not encrypt, hide or otherwise protect the data.
- Validate before relying on a formatted result.
- Pretty-print for review and minify for compact transport when appropriate.
- Never paste secrets into a tool unless its privacy behaviour is clear.
Know the six JSON value types
A JSON value is an object, array, string, number, boolean or null. Object property names and string values require double quotes. JavaScript conveniences such as single-quoted strings, undefined, comments and trailing commas are not part of JSON.
The document must contain one top-level value. That value is often an object or array, but a string or number can also be valid JSON. Property names should be unique even though some parsers accept duplicates; duplicate names can be interpreted inconsistently and should be corrected at the source.
Read parser errors from the reported position
A parser commonly reports the character position where it became impossible to continue. The real mistake may be just before that point. If an error says a property name was expected, inspect the preceding comma and the quotes around the next key.
Work from the first error, not the last visible oddity. One missing quote can make the remainder appear invalid. After each correction, validate again; a clear line and column makes this cycle faster.
- Unexpected end of input usually means a quote, brace or bracket was never closed.
- An unexpected token near a property often points to a missing comma or double quote.
- A trailing comma before a closing brace or bracket is invalid JSON.
- Control characters inside strings must be escaped, for example with \n or \t.
Choose formatting options intentionally
Two spaces is a common compact indentation; four spaces is roomier; tabs follow the viewer's tab-width preference. The choice changes presentation only. Sorting object keys can make two documents easier to scan, but it changes their displayed order and may create noisy diffs if another system intentionally emits a particular order.
Do not treat key order as business logic. JSON objects represent named members, and consumers should access those names rather than depending on their sequence. Arrays are different: their order is meaningful and a key sorter should never reorder array elements.
Inspect JSON as data, not code
Safe JSON tools use a parser such as JSON.parse and display the resulting structure. They do not use eval, execute property values or merge untrusted objects into application configuration. Parsed keys such as __proto__ should remain ordinary input data rather than being assigned into shared objects.
Before sharing a formatted document, scan for access tokens, passwords, email addresses and other private fields. Local formatting prevents a network upload, but copying the output into a ticket or public message can still expose its contents.
- Keep an untouched source copy before making corrections.
- Redact secrets before sharing output.
- Download with a .json extension only after validation succeeds.
Recognise what syntax validation cannot prove
Valid JSON can still be unusable for a particular API or application. Syntax validation does not confirm required property names, permitted values, date formats or relationships between fields. Those rules belong to a schema or the receiving system's contract. After the syntax passes, compare the structure with authoritative documentation and test a non-production request where appropriate.
Numbers deserve special care because JSON has one number syntax while programs use different numeric representations. Very large integers can lose precision in ordinary JavaScript, and decimal currency can acquire binary rounding artefacts. When exact identifiers or monetary quantities matter, follow the consumer's documented string or decimal format instead of assuming a successful parse preserves every digit semantically.
- Do not mistake pretty formatting for schema validation.
- Do not hand-edit a production configuration without a review and rollback copy.
- Preserve large identifiers as strings when the receiving contract requires it.
- Check escaped newlines and backslashes in paths rather than judging only the rendered view.