"Is this JSON valid?" and "is this JSON the shape I expect?" are two completely different questions, and mixing them up is a common source of confusion. Our JSON Validator answers the first one — this post is about the second, and the tool built for it: JSON Schema.
Syntax validity vs shape validity
{ "user": null }That's perfectly valid JSON — well-formed, parseable, no syntax errors. But if your code expects user to always be an object with id and name fields, this document is going to break something downstream, and no amount of syntax checking will catch it. Syntax validation confirms a document is parseable; it says nothing about whether it matches the shape your code actually needs.
What JSON Schema actually is
JSON Schema is a JSON document that describes the required structure of other JSON documents — required fields, expected types, allowed value ranges, and more. A minimal example:
{
"type": "object",
"required": ["id", "name"],
"properties": {
"id": { "type": "number" },
"name": { "type": "string" },
"email": { "type": "string", "format": "email" }
}
}A schema-validation library checks a real document against this and reports every mismatch: a missing required field, a string where a number was expected, an email field that doesn't look like an email. That's a fundamentally heavier operation than syntax checking — it needs the schema itself as an input, not just the document being checked.
Where each one actually helps
- Syntax validation — debugging a hand-edited config file that won't parse, checking an API response isn't truncated or malformed, catching a stray trailing comma before it breaks a build. Fast, no schema required, exactly what our validator does.
- Schema validation — enforcing an API contract between services, catching a breaking change in a request/response shape before it ships, validating user-submitted JSON against a form definition. Requires maintaining a schema alongside the data it describes.
A common workflow: syntax first, then schema
In practice these two checks are usually sequential, not competing — a schema validator has to parse the document first anyway, so syntax errors get caught as a side effect before schema checking even begins. If you're debugging a document that's failing schema validation with a confusing error, it's often worth running it through a plain syntax validator first to rule out a basic parsing problem before assuming the schema mismatch is the real issue.
Where to go for actual schema validation
JSON Schema validation isn't something this tool does — it's a genuinely different, heavier feature (you'd need to author and maintain a schema, then run a library like ajv against it). If a document is failing to parse at all, though, that's exactly the "is this even valid JSON" question our JSON Validator answers first — line and column of the exact break, no schema required.