JSON Validator Online: Debug API Responses and CI Gates

The JSON that breaks things is rarely the JSON you typed by hand. It arrives in a response body that returned 200 but still crashed the client, or in a fixture that passed locally and failed in CI. Checking it in the browser gives you the exact line and column while the payload, tokens and all, stays on your machine.

Use the free tool: JSON Validator - private, in-browser.

Three places JSON validation earns its keep

While debugging a response. A request succeeds, your code throws anyway. Either the body is valid JSON with a shape you did not expect, or it is not JSON at all: an HTML error page, a proxy message, or a truncated stream that a parser will reject immediately.

Before committing a fixture. Test fixtures rot. Someone hand-edits a mock response, adds a field for one test, and leaves a syntax error that only surfaces when another suite loads the file.

In a pre-commit hook or CI job. A parse gate is cheap and catches the class of mistake that wastes the most time: a file that cannot be read at all.

Step-by-step: validate a suspect API response

1. Copy the raw body, not the preview

In your browser's network panel, use "Copy response" rather than copying the parsed object shown in the preview pane. The preview can be collapsed, truncated, or rendered as a JavaScript object, which is not the same text the parser received. If you captured the response in a terminal, save it to a file and open that.

2. Paste it into the validator

Open the validator and paste the body. You do not need an account, and nothing is uploaded.

3. Read only the first error

Parsers stop at the first fatal problem. Fix that one, then re-run the check instead of hunting for every issue at once. Chasing multiple guesses in a large payload usually makes the original error harder to find.

4. Look at the reported position

When validation fails, the tool reports the line, column, and character position where parsing stopped. That position is where the parser could not continue, which is not always where the typo is. An unclosed quote or bracket earlier in the payload often surfaces much later.

5. Confirm the syntax, then inspect the shape

Once the payload validates, use the JSON Formatter to pretty-print it and read the structure. This is the step where you notice that items is an object instead of an array, or that a field you expected is missing entirely. Formatting requires valid JSON, so validation belongs first.

6. Save the corrected body as a fixture

If the response is now correct, store it as a test fixture and let your pipeline parse it on every run. That turns one manual debugging session into a permanent regression check.

Syntax validation and schema validation are different gates

A validator answers one question: can this text be parsed as JSON? That is necessary, but it is not the same as "does this data match the contract?"

| Question | Syntax check | Schema check | | --- | --- | --- | | Is the document parseable? | Yes | Assumes it already is | | Are required fields present? | No | Yes | | Are value types correct? | No | Yes | | Are unknown properties rejected? | No | Depends on the schema |

Consider a response like {"status": "ok", "items": null}. It is perfectly valid JSON. It also breaks any client that calls items.map(...) without a guard. A syntax validator is right to accept it; a schema that declares items as an array is right to reject it. Both results are correct because they test different things.

This distinction matters when a bug report says "the API returned bad JSON." Sometimes the JSON is fine and the contract changed. Validate first to rule out the parser, then check required fields, types, and nullability against what your code assumes. Schema validation needs a JSON Schema validator or contract test in your own suite; the browser tool deliberately stops at syntax.

Put a parse gate in CI and pre-commit

The browser validator is for humans investigating a specific payload. Automation should call a parser. Any of these fail the step when a file is unreadable:

# one option per file
python -m json.tool fixtures/response.json > /dev/null
jq empty fixtures/response.json
node -e 'JSON.parse(require("fs").readFileSync(process.argv[1], "utf8"))' fixtures/response.json

Wrap that in a loop over your fixtures directory and run it in CI. For pre-commit, run the same check on staged .json files so a broken fixture never reaches review. Two practical notes: a schema check is still worth adding on top, and a response with status 204 has no body, so it should not be parsed at all.

If the CI failure gives you an unhelpful message, reproduce it locally by running the same payload through the browser validator. The reported line and column are usually easier to act on than a stack trace that points at a deserialization call.

Keep production payloads off other servers

Real response bodies carry bearer tokens, session identifiers, customer records, and internal hostnames. Pasting one into a server-side validator sends all of that to a third party, often without any record of where it went. A tool that runs locally in the browser avoids the question entirely: the text is processed on your device and never transmitted. The same habit applies to bug reports, where payloads should be redacted before they land in a ticket.

A short checklist

• Copy the raw response body, not the collapsed object preview.
• Validate before formatting; formatting needs parseable input.
• Treat syntax and schema as two separate gates.
• Run a parser over fixtures in CI and in a pre-commit hook.
• Redact tokens and customer data before sharing a payload anywhere.

If you only adopt one habit, make it the first: validate the actual bytes your code received. Formatting a payload that never parsed just hides the problem behind a prettier error.

For a walkthrough of the specific syntax mistakes that cause these failures, see how to fix common JSON errors.

Related tools

• JSON Validator - check syntax with line, column, and character position.
• JSON Formatter - pretty-print, minify, or sort valid JSON.
• Browse all tools - more browser-based utilities.