A practical workflow for debugging JSON API payloads

1. Preserve the original before formatting

Start with an untouched copy of the response or request body. If it came from a log, remove surrounding log prefixes without changing the JSON characters. Then run it through JSON Formatter & Validator to separate syntax errors from application-level errors.

A successful parse tells you that the text is structurally valid JSON. It does not check required properties, enum values, permissions, or whether an identifier was accidentally converted from a string to a number.

• Keep identifiers with leading zeroes or more precision than JavaScript can represent as quoted strings.
• Record the parser error line and inspect the previous line when a comma or quote is missing.
• Use minified output only for transport or a fixture; use indented output for review and diffs.

2. Query the fields that the endpoint actually consumes

When a response is large, do not review every property with equal attention. Use JSONPath Tester to check the fields used by the handler, such as $.data.items[*].id or $.meta.next_cursor. Run a few targeted expressions rather than copying the whole response into a new system.

This step is useful for finding an empty array, a renamed property, or a repeated value. It also makes the question precise: “What does the payload contain at this path?” is easier to verify than “Does this JSON look right?”

• Check a normal response, an empty result, and an error-shaped response.
• Test whether a path returns a scalar, object, array, or no match at all.
• Keep the JSONPath expression beside the test case so the check can be repeated after a change.

3. Compare revisions and inspect time fields

Put the previous and current payload into Diff Viewer to distinguish a meaningful field change from indentation noise. Then pass epoch values or ISO dates to Unix Timestamp Converter when an event appears in the wrong day or when a client and server disagree about seconds versus milliseconds.

A timestamp represents an instant; the displayed calendar date depends on the timezone used for presentation. Compare UTC with the target timezone before changing the stored value. This avoids “fixing” a display problem by corrupting the underlying event time.

• Compare the same payload shape before and after a deployment.
• Check both seconds and milliseconds when a numeric date is off by roughly three orders of magnitude.
• Use an explicit offset or UTC value in test fixtures when results must be reproducible across machines.

4. Finish with the destination contract

The final check belongs to the API contract, not the formatter. Confirm field names, types, required values, authentication scope, maximum sizes, and whether the receiver accepts unknown properties. If the payload contains secrets or personal data, redact them before placing a sample in an issue, test report, or chat transcript.

Browser-local processing reduces the number of places where a copied sample is transmitted, but it does not make the input harmless. URLs, clipboard history, screenshots, browser extensions, and downstream logs can still expose sensitive values.