JSON formatting and validation: a practical guide for developers

JSON is the default language of the web. Almost every API returns it, most configuration systems accept it and browsers parse it natively. Because it looks simple, people often treat it casually, and that is exactly when it breaks: a trailing comma in a config file stops a deployment, a single smart quote pasted from a chat app makes an API reject a request, or a 4 MB response arrives on one line and nobody can read it.

This guide explains the rules that actually matter, how to read the error messages parsers give you, and a workflow that turns messy JSON into something you can trust.

The rules JSON really enforces

JSON is defined by RFC 8259 and ECMA-404. The specification is short, and most errors come from a handful of rules:

1. Strings and keys use double quotes. {"name": "Asha"} is valid; {'name': 'Asha'} and {name: "Asha"} are not. JavaScript object literals allow both forms, which is why code copied from a .js file often fails.
2. No trailing commas. [1, 2, 3,] is an error. Many editors and languages tolerate it, JSON does not.
3. No comments. Neither // nor /* */ is allowed. Formats such as JSONC (used by VS Code settings) and JSON5 add comments, but a strict parser will reject them.
4. A limited set of values. Objects, arrays, strings, numbers, true, false and null. There is no undefined, no NaN, no Infinity and no date type. Dates are normally sent as ISO 8601 strings such as "2026-10-12T09:30:00Z".
5. Numbers have one format. No leading zeros (007), no leading plus sign, no hexadecimal. 1e3 is fine.
6. Control characters must be escaped. A literal tab or line break inside a string is invalid; it must be written as \t or \n.

Two subtler issues catch experienced developers. First, JSON numbers have no size limit in the specification, but JavaScript stores them as 64-bit floating-point values, so integers above 9,007,199,254,740,991 (2^53 − 1) lose precision. If an API sends large IDs as numbers, ask for them as strings. Second, duplicate keys are technically allowed but behave unpredictably: most parsers keep the last value, some keep the first. Treat duplicates as a bug.

Reading parser errors

A good validator tells you where parsing failed, not just that it failed. When the JSON Validator reports an error at line 14, column 3, the real mistake is often just before that position. A missing comma at the end of line 13 only becomes a problem when the parser meets the next key on line 14. Likewise, “unexpected end of input” usually means a bracket or quote was never closed, so look for the opening character, not the end of the file.

Some common messages and what they usually mean:

Message	Typical cause
Unexpected token '	Single quotes instead of double quotes
Unexpected token }	Trailing comma before a closing brace
Unexpected token /	A comment left in the file
Unexpected end of JSON input	Unclosed bracket, brace or string; truncated download
Bad control character in string	A raw tab or newline inside a string value

If the error points into the middle of a long string, check for an unescaped double quote inside the text, for example a product name such as "12" monitor".

Pretty-print or minify?

Formatting does not change data; it only changes whitespace. The choice depends on who reads the result.

Pretty-print with two-space indentation when a human needs to read or review the data: debugging an API response, reviewing a configuration change or writing documentation. The JSON Formatter also lets you sort keys alphabetically, which makes two versions of an object far easier to compare.

Minify when the data is transmitted or stored and no one reads it directly. Removing indentation and line breaks from a typical API payload saves 10–30% of its size before compression. After gzip or Brotli the difference is smaller, because whitespace compresses very well, but it still reduces parsing work and storage. The JSON Minifier shows the size before and after so you can judge whether it is worth it.

A repeatable cleanup workflow

When you receive JSON you do not trust, such as a log export, a response copied from a browser or a file from another team, this sequence avoids most surprises:

1. Validate first. Paste it into a validator and fix syntax errors one at a time, starting from the first reported error. Later errors are often side effects of the first.
2. Format it. Once it parses, pretty-print it so the structure is visible. Collapse large arrays in a tree view to see the overall shape.
3. Check types. Look for numbers stored as strings ("price": "199"), booleans stored as "true", and inconsistent nulls. These are valid JSON but cause bugs in code that expects a specific type.
4. Compare against a known-good version. If something “suddenly” broke, a structural diff such as JSON Diff shows exactly which keys were added, removed or changed, ignoring key order and whitespace.
5. Convert only when needed. If the data is going into a spreadsheet, convert arrays of flat objects with the JSON to CSV Converter. Nested objects are flattened into dotted column names such as address.city.

Handling large files

Browser-based tools can comfortably handle files of several megabytes. A few habits keep things fast:

• Use a tree view instead of a giant text block. Rendering 200,000 lines of formatted text is slow in any editor; a collapsible tree renders only what you open.
• Validate before formatting. If the file is broken, there is no point formatting it.
• For newline-delimited JSON (NDJSON), where each line is a separate object, do not wrap the whole file in brackets by hand. Convert it with a tool built for the format so each line is parsed independently.

Privacy matters with JSON

API responses frequently contain tokens, email addresses, internal hostnames and customer records. Pasting them into a random website is a real risk if that site uploads and logs the content. Toolew’s JSON tools parse and format data entirely in your browser, so nothing you paste is sent to a server. Even so, it is good practice to remove secrets before sharing JSON with colleagues, in tickets or in screenshots.

Quick checklist

• Double quotes for every key and string
• No trailing commas, no comments
• Large integers sent as strings
• Dates as ISO 8601 strings
• Validate, then format, then compare
• Minify for transport, pretty-print for people

JSON rewards a little discipline. Once you know the handful of rules that matter and you validate before you debug, most “mysterious” failures become five-second fixes.