Find the first error without guessing
A JSON document stops being valid at the first character the parser cannot interpret. Paste the complete response and treat its line, column, and message as a clue, not a verdict on the whole line. For example, in { order: 18, "active": true, } there are two issues: order needs quotes and the trailing comma is not allowed. Fix the reported point first, validate again, and repeat. If a message points at a closing brace, inspect the preceding value too: an unclosed quote, a literal line break inside text, or a missing comma often moves the reported position to the end of the block. Reduce a large payload to a reproducible fragment when needed. Formatting does not repair data; it confirms that what the browser received is JSON and makes each object, array, and value boundary easier to inspect.
Readable formatting and a minified version
Formatting adds indentation and line breaks so you can inspect nesting, compare responses, and find a property. Minifying removes only whitespace that JSON permits outside strings; it must not alter letters, keys, numbers, or spaces that belong to text. Keep a copy of the original before replacing it and compare the content afterwards, not just its appearance. A simple check is to paste the formatted output into a parser, copy it, minify it, and format it again: the visible structure should remain the same. The minified length helps estimate a transfer, but HTTP compression and character encoding can change the actual network size. Use synthetic data and the indented version when sharing an error example; use the representation expected by the integration for a production payload.
Large numbers and repeated keys
JSON permits numbers without distinguishing integers from decimals, but a consumer may not preserve every digit. JavaScript commonly represents numbers as IEEE 754 values and can round integers above 9007199254740991. Order identifiers, card numbers, postal codes, or references with leading zeros should be text when their exact textual form matters. Repeated keys are another trap: { "status": "new", "status": "closed" } can be syntactically valid, yet many parsers retain only the last occurrence. A formatter may show a normalized result and hide that the first value was lost; inspect the input text and set a rule in the producer. JSON validity does not prove an amount is sensible, a date exists, or a field has the meaning your application expects.
Limits and responsible data handling
This utility helps with syntax, indentation, minification, and visual reading; it does not replace schema validation, business rules, or tests in the system receiving the message. Valid JSON can omit a required field, use the wrong currency, or describe an action that a server must reject. Validate contracts with the appropriate schema and application. Do not paste secrets, tokens, passwords, cookies, personal data, or full production responses: local processing reduces network exposure, but content can still reach history, the clipboard, extensions, or a shared screen. Before copying an output, select the complete block, paste it into a safe destination, and validate it there once more. The JSON error diagnosis guide and JSON-to-CSV conversion guide extend these checks when data must be debugged or exported.
A short routine before sending
Split the check into steps another person can repeat. First validate a minimal sample and retain the parser message and position. Then format it to read the surrounding context and inspect sensitive types: text versus number, null values, empty arrays, and dates. Minify only when the destination needs it, and do not make the minified output your sole working copy. Finally, paste the result into the test client or environment that will consume it and verify the expected response. This sequence exposes differences between local syntax and an API's rules, and makes a partial copy or repeated key less likely to pass unnoticed merely because it looks like correct JSON.