On this page

Syntax tells you whether text can be read as JSON; JSON Schema checks explicit requirements on its values. An API can therefore reject a document that passes a syntax check. Check syntax first, then validate the document against its schema. A passing result covers only the rules in that schema that the validator supports.

Check Question it answers What to review if it fails
Syntax Can both texts be parsed as JSON? The input identified in the diagnostic: document or schema.
Supported schema Can the validator understand this schema and its rules? The draft, keywords, and how they are declared.
Conformance Do the values satisfy this schema? The field and rule named in the diagnostic.
External business rules Does the order exist, and is it authorized? The data source and application checks. This example’s schema cannot answer those questions.

An order with valid syntax that fails its contract

This fictional order is syntactically valid JSON:

{
  "id": "00123",
  "quantity": "2",
  "active": true
}

Suppose the contract requires a whole-number quantity of at least one. Here is the complete schema to check it:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "id": { "type": "string", "minLength": 1 },
    "quantity": { "type": "integer", "minimum": 1 },
    "active": { "type": "boolean" }
  },
  "required": ["id", "quantity"],
  "additionalProperties": false
}

The root must be an object. properties describes its fields: id is a nonempty string, quantity is an integer greater than or equal to 1, and active, when present, is a boolean. required makes id and quantity mandatory; listing active in properties does not make it mandatory. additionalProperties: false disallows fields outside that list.

The type distinction and inclusive minimum follow JSON Schema draft-07, sections 6.1.1 and 6.2.4. Here, "2" is text. Containing a digit does not make it an integer.

Find the error and decide what to change

  1. Open the JSON Schema validator. Paste the complete schema into JSON Schema and the original order into JSON document.
  2. Choose Validate. If either input cannot be parsed, address its JSON syntax errors first.
  3. With these inputs, expect a type mismatch at /quantity, with the schema rule at /properties/quantity/type.
  4. Check the contract and source data to confirm that the value is a quantity. If it is, change "2" to 2 and choose Validate again.

The diagnostic locations are JSON Pointers, not JSONPath queries. /quantity points to the value; /properties/quantity/type points to the schema rule. Message wording may vary across languages, but the locations and keyword tell you what failed.

The corrected document is:

{
  "id": "00123",
  "quantity": 2,
  "active": true
}

The expected result is valid against this schema. id remains a string and keeps its leading zeros. Do not remove quotes from every value that looks numeric: an identifier need not be a quantity. The validator does not turn "2" into 2; deciding whether that change is justified is up to you.

Independent cases: type, minimum, and an extra field

Start from the corrected document for each row, keeping the same schema. Undo the previous change before trying the next case.

Single change Expected result What to do next
Replace "quantity": 2 with "quantity": "2" type at /quantity. Text does not satisfy the integer type. Confirm the contract before changing the value.
Replace "quantity": 2 with "quantity": 0 minimum at /quantity. The type is correct, but the minimum is 1. Check the source quantity rather than inventing one that passes.
Add "currency": "MXN" additionalProperties, property currency, root instance. The contract does not allow this field. Check whether it belongs or the schema needs updating; do not delete it blindly.
Leave the corrected document unchanged Valid against the schema. The declared rules pass; the order’s existence and authorization remain unchecked.

The root is represented by the empty JSON Pointer (""). These are separate cases, not a single output listing several errors. The tool reports only the first mismatch. Fixing it and validating again may reveal another.

When the schema itself is the problem

A schema can be valid JSON yet contain a keyword this tool does not support. Keep the corrected order and replace its schema with this deliberately unsupported example:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "format": "email"
}

Expect an unsupported schema result for format, before the data is evaluated. This does not mean that the order fails its contract or that its identifier must be an email address. Restore the order schema to continue.

This tool implements a subset of draft-07. It requires an object at the schema root and the exact $schema URI shown above. It rejects unknown or unsupported keywords, including $ref, format, combinators, and conditionals. It does not provide full draft-07 support or support for 2019-09 or 2020-12.

What a passing result proves

The corrected order satisfies this contract. That does not establish whether "00123" exists, whether enough stock is available, or whether the sender has permission to place the order. It also cannot confirm that the copied quantity matches the source. Those checks still belong to the application and the review of the original data.

Validation does not repair syntax, remove properties, or edit the input. Cancellation or an operational limit leaves the check incomplete: neither proves conformance nor a contract violation. The JSON Schema validator page documents size, depth, and operation limits, along with the rejection of numbers it cannot represent safely.

Share this guide

Article link