API Response Validator

What this tool does

Paste a JSON Schema and a JSON response. Every problem comes back with the line it is on, the JSON Pointer path to the value, and a message that says what to do about it.

Everything runs in your browser. The schema and the response are never uploaded, and no account is required.

How to use it

1. Paste your JSON Schema into the schema pane. The tool reads $schema to determine the draft, and tells you if it cannot support it.
2. Paste the response you want to check into the response pane.
3. Read the verdict. A number, then every finding with its line and path.

Click a finding and the matching line highlights. Click a marked segment in the spine down the left edge and it jumps to the first problem in that stretch of the file. On a phone, the verdict is pinned to the bottom of the screen and findings open as a sheet.

Optional and nullable are not the same thing

This is the distinction teams get wrong most often, and it is the one that produces defects nobody can explain later.

Optional means the field may be absent from the object entirely. Nullable means the field is present and its value may be null. A schema has to state which of those it permits, because they are different contracts and consumers handle them differently.

So a field has four states worth testing, not two:

Do not let development teams treat missing, empty and null as interchangeable. They arrive at a consumer as three different problems, and code written on the assumption that they are the same will fail on whichever one it did not anticipate.

Paste a response into this tool with the field absent, then again with it explicitly null, and see whether your schema treats them the same way. If it does and you did not intend that, you have found something.

additionalProperties is a governance decision, not a default

Blanket advice to set additionalProperties: false on every API is wrong. So is leaving it unset and never thinking about it. The decision should be explicit and it should differ by contract.

For stable internal and business-critical contracts, unexpected fields should normally be identified. Otherwise producer-side changes enter unnoticed, and over time consumers start depending on fields nobody agreed to. By the time that surfaces, the informal contract is load-bearing and cannot be removed.

For public or deliberately extensible APIs, strict rejection breaks forward compatibility. A producer adding a field should not be a breaking change for every consumer.

What matters is that the choice is made rather than inherited from the schema default. At minimum, your contract reports should show newly introduced fields, even where you do not reject them. Knowing what changed is the point; rejecting it is a separate decision.

This tool reports unexpected properties either way, so you can see what a producer has started sending before you decide whether you mind.

Where response validation belongs

Different depth at different points, rather than the same check everywhere:

• At the API or service boundary. This is where the contract actually lives
• Focused contract checks during pull requests or the build pipeline. Fast, narrow, blocking
• Broader integration validation after deployment to a shared environment, where real data shapes appear
• Critical production integrations through safe monitoring or synthetic checks, because the contract can break without any deployment on your side

Schema validation on its own is not enough. A complete response check also covers status codes, required headers, data types and formats, business rules, cross-field relationships, and database or downstream consistency where it matters. The schema is one layer of several, and treating it as the whole job is how a suite ends up green while the integration is broken.

When contract testing becomes theatre

A suite can be extensive, green, and worth nothing. The signs:

• Tests only verify that the response is valid JSON
• Every field is optional
• Most fields accept any data type
• Additional properties are unrestricted, without anyone having decided that
• Only happy-path responses are tested
• Error contracts are ignored entirely
• Tests run against mocked responses that no longer resemble production
• A schema passes on a response the consumer cannot actually use
• Nobody checks whether producer and consumer versions are still compatible

A green schema test does not mean the integration is safe. It means the response was shaped roughly as expected. Those are different claims.

The test has to protect the assumptions consumers actually depend on. Validate meaning, not only structure: required business fields, conditional rules, identifier formats, error responses, compatibility risks. A contract suite is useful only when it can fail for the changes that would genuinely break a consumer. If you cannot name a realistic change that would turn it red, it is not testing anything.

Two things that pass and should not

Both are reported here as warnings rather than errors, because neither breaks the schema. Calling them failures would be inaccurate. Most validators do not report them at all.

Duplicate keys. JSON permits an object to carry the same key twice. Most parsers keep the last occurrence and silently discard the rest, so a response containing a field twice validates cleanly while part of what the producer sent has already gone. No schema can catch this, because by the time the validator sees the object there is only one of that key in it.

Integers larger than 2^53. JavaScript cannot represent integers above 9007199254740991 exactly. The rounding happens inside JSON.parse, before validation runs, so the validator inspects a number that is already wrong, finds it satisfies type: "integer", and reports that everything is fine. Order identifiers, ledger references and anything derived from a 64-bit database key cross this line regularly.

Limitations, stated plainly

Drafts 4, 7, 2019-09 and 2020-12 are supported. Drafts 3 and 6 are not. If your schema declares one of those, the tool names it and stops rather than validating against the wrong rules and reporting confident nonsense.

External $ref is refused. Resolving a schema over HTTP would require a network request, which would break the guarantee that nothing leaves your browser. Inline the definition, or move it under $defs and reference it locally.

Strict JSON only. Trailing commas, comments and unquoted keys are rejected, with the line and column. Your API will reject them too, and a tool that quietly accepts what production refuses is worse than no tool.

format behaviour is stated, not assumed. From Draft 2019-09 onward it is an annotation rather than an assertion by default, so a value failing format: "email" is still valid unless the schema opts in. The tool tells you which behaviour is active, because the two produce opposite verdicts on the same data.

Built by Qortex Lab. Everything runs client side, so your schema and your data stay in the browser.