Two different questions
{"id": "1"} is perfectly valid JSON and completely wrong if your API expects
an integer. Syntax validation cannot catch that; schema validation can. This
tool does both, in that order, because a schema check on unparseable text has
nothing to work with.
Writing a schema worth having
The smallest useful schema names the type, the required fields, and the type of each field:
{
"type": "object",
"required": ["id", "email"],
"properties": {
"id": { "type": "integer", "minimum": 1 },
"email": { "type": "string", "format": "email" }
}
}
Two additions repay themselves quickly. "additionalProperties": false catches
a typo in a key name, which is otherwise silently ignored. "minimum",
"minLength" and "enum" catch the values that are the right type and still
nonsense.
Where schemas earn their keep
- Validating a webhook payload before acting on it
- Checking a configuration file in CI, so a bad deploy fails at build rather than at runtime
- Documenting what an endpoint accepts, in a form a machine can check
Questions
What is the difference between this and the formatter?+
The formatter answers whether the text parses and makes it readable. The validator answers whether the parsed data has the right shape — that `id` is an integer, that `email` is present, that `tags` holds strings. Syntax and schema are separate questions and a document can pass one while failing the other.
Do I need a schema?+
No. Leave the schema pane empty and this checks syntax only. A schema turns it into a contract check, which is what you want before sending a payload to an API that will reject it.
Why does it list several errors at once?+
Because fixing them one at a time is slow. Validation runs with all errors collected, so one pass tells you everything wrong with the document instead of the first thing.
Which JSON Schema drafts work?+
Drafts 07, 2019-09 and 2020-12, plus the common string formats — email, uri, date, date-time, uuid, ipv4. Format checking is enabled, so `"format": "email"` actually rejects a non-email rather than being decorative.