WHAT IT DOES
See every contract failure at the path where it happened.
Paste a self-contained JSON Schema and the JSON value it describes. The schema is checked against the Draft 2020-12 dialect before the instance is evaluated, and failures are returned as labeled JSON Pointer paths with the responsible keyword and a readable explanation. Validation runs without code generation or network lookups, so private schemas and payloads remain inside the browser while still producing a result that can be copied into an issue or review.
Why use it?
A document can be valid JSON yet violate a contract. Use a schema to check required fields, types, bounds, and other declared rules before passing data to a consumer.
How to use this tool
- Put the schema in the schema pane and the JSON to check in the instance pane.
- Choose Validate and inspect the reported locations and failed rules.
- Correct the instance or deliberately change the contract, then validate again. The worked example below includes a failure and its expected correction.
Details and limitations
- The validator supports the Draft 2020-12 core, applicator, validation, and unevaluated vocabularies, including same-document references and dynamic anchors.
- Schema errors are separated from instance failures, so an invalid contract is never presented as though the data merely failed it.
- External references are refused instead of fetched silently; bundle dependent schemas under $defs and reference them with local fragments.
- One or two .json files can be dropped into the Schema and JSON document panes and are parsed entirely locally.
Valid JSON is not the same as valid application data
Formatting answers the syntax question
Load the formatter's example containing a numeric count and an items array. Formatting makes the structure readable without deciding whether count should be positive or whether the values make sense to your application. If you change 2 to the string "2", both documents are still valid JSON. Use the diff to make that type change visible rather than judging the documents by their indentation.
Numeric: {"count":2}
String: {"count":"2"}
Both parse; they are not the same value.Write down the rule you mean
The schema-validator example declares count as an integer with a minimum of 1 and makes it required. Its supplied instance contains the string "2". The expected result is a type error, not automatic conversion to a number. Change the instance to {"count":2} and validate again. This establishes a reproducible failure and success for your rule rather than treating a successful parse as validation.
Schema: {"type":"object","properties":{"count":{"type":"integer","minimum":1}},"required":["count"],"additionalProperties":false}
Failing instance: {"count":"2"}
Passing instance: {"count":2}Try the near misses
Test {}, {"count":0}, and {"count":2,"debug":true} against that same schema. The first is missing a required property, the second violates the minimum, and the third has an unlisted property. The additionalProperties restriction is a deliberate contract choice, not something every API needs. If new fields should be tolerated, change that rule and record the intended behavior in your application's tests.
Do not mistake an example for the whole contract
A schema or type generator can infer a useful starting shape from supplied samples. A single successful record does not tell it every valid alternative, which fields may be absent, or what numerical boundaries the application intends. Review generated requirements and test representative failures. The formatter, diff, generator, and validator answer different questions; linking their results is useful precisely because none replaces the other three.