How to debug a JSON API response without losing important data

1. Keep an untouched copy before formatting

Copy the response body into a local scratch file before changing it. Record the HTTP status and content type separately. A successful JSON parse does not establish that the HTTP request succeeded: a server can return an error object that is perfectly valid JSON.

Remove credentials and personal data from any example you plan to share. Preserve the structure and value types while replacing sensitive values. If you change a numeric ID into a quoted string during redaction, you may accidentally remove the bug you wanted to investigate.

{"orderId":"9007199254740993","items":[{"sku":"DEMO-1","quantity":2}],"paid":false}

2. Fix syntax before investigating the data model

Open JSON Validator and paste the example. It should pass. Now add a comma after false, before the closing brace, and run it again. Standard JSON rejects that trailing comma. Remove it and confirm that the same input passes.

Other common failures include single-quoted strings, comments, unquoted property names, and a response that is actually HTML. Check the beginning of the raw response when a request unexpectedly returns a login page or proxy error. Do not remove arbitrary characters until a validator becomes satisfied; find the producer responsible for the malformed response.

Invalid: {"paid":false,}
Valid:   {"paid":false}

3. Format to inspect nesting and types

In JSON Formatter, choose Format and two-space indentation. The items value is an array, each array member is an object, quantity is a number, and paid is a boolean. Read the values at the depth your application actually expects.

Compare quantity: 2 with quantity: "2", and paid: false with paid: "false". Each alternative is valid JSON, but the quoted values are strings. A syntax validator cannot tell you whether your API accepts them. Likewise, an empty array, a missing items property, and items: null are different states even if a user interface displays all three as an empty list.

4. Protect identifiers and inspect duplicate keys

The example deliberately stores orderId as a string. JavaScript numbers cannot represent every integer beyond Number.MAX_SAFE_INTEGER, which is 9007199254740991. Parsing and serializing an unquoted larger ID can change it. If the API contract represents an identifier as a string, keep it quoted throughout the workflow.

Duplicate object keys are another reason to keep the original. Parsing {"status":"new","status":"paid"} with JavaScript retains the last value; formatting then hides evidence that the producer sent the key twice. Compare the original response before using formatted output as a replacement.

Preserve exact ID: {"orderId":"9007199254740993"}
Inspect original: {"status":"new","status":"paid"}

5. Turn the diagnosis into a repeatable check

Once the document parses, compare required fields, allowed values, and types against the API schema. Create tests for a normal response, an empty collection, a missing required field, a null value, and the largest identifier your system needs to preserve.

If you compare two formatted responses with Text Difference, use the same indentation first. The comparison is textual, so changed key order can appear as a difference even when the objects represent equivalent data. JSON Formatter and JSON Validator answer syntax and readability questions; your application tests establish whether the response is usable.

Try the tools in this guide

• JSON Formatter — Make your JSON clean, readable, and easy to debug.
• JSON Validator — Check JSON syntax and find errors quickly.
• Text Difference — Compare two texts and see exactly what changed.

References

• MDN: JSON.parse and loss of number precision
• MDN: Number.MAX_SAFE_INTEGER