Validate JSON Schema
Check a data document against the shape it must follow and see where it breaks: every problem comes with the path to the failing value and the rule it violated. An email plus an age of 36 written as a number passes cleanly. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Runs in your browser. Free, unlimited — your data never leaves this page.
A validator that just says 'invalid' is barely more useful than no validator at all — you still have to hunt through the document to find what's wrong.
Why “invalid” on its own is not enough
A checker that only answers yes or no leaves the real work to you: reading a document with dozens of nested entries to find the single one that is wrong. This one is built the other way round. The verdict is the easy part; what matters is where the document fails and why. Every problem comes back with the path to the failing value, from the top of the document down to it, and the specific rule it broke, so a developer or a support team can go straight to the fix instead of searching line by line.
What the expected shape can check, and common slips
The expected shape is itself a small document. It describes not only how your data is organised but also its limits: which entries are required, what pattern a text must follow, which range a number must stay within, which values are allowed from a fixed list and how nested objects must look. The standard behind it has been published in successive drafts since 2010, and its current version is 2020-12. The most common slip is to leave the expected shape out and assume the content was checked: without it, only whether the document is well formed is verified. The age in the example passes because it is written as a number, which is exactly what its rule asks for.
FAQ
Does it report every error or just the first one?
It reports every violation found in a single pass, not just the first, so you can fix a document in one round instead of one error at a time.
What is checked if I do not provide the expected shape?
Only whether the document is well formed, meaning it is written correctly and can be read at all. Content rules, such as required entries or the type of each value, are checked only when you supply the expected shape.
What kinds of rules can the expected shape describe?
Which entries are required, what pattern a piece of text must match, which range a number has to stay within, which values are allowed from a fixed list, and how objects nested inside other objects must look.
How do I know which value failed and why?
Each problem in the result names the exact path to the failing value, from the top of the document down to it, plus the specific rule it broke. You go straight to the fix instead of reading every nested entry by eye.
What does a passing result look like?
A valid verdict with an empty list of problems. In the example, the document contains the required email and an age of 36 stored as a number, so it passes with nothing to report.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/data/json-validate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"json":{"email":"a@b.c"}}'const res = await fetch("https://api.kit.forhosting.com/data/json-validate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"json": {
"email": "a@b.c"
}
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/data/json-validate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"json": {
"email": "a@b.c"
}
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/data/json-validate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"json":{"email":"a@b.c"}}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"json":{"email":"a@b.c"}}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/data/json-validate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"json": {
"email": "a@b.c"
}
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "data.json_validate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 25 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This endpoint validates your JSON against a schema and points straight at the offending field, its path, and why it failed.
The gap between 'valid: false' and knowing why
Plenty of validation libraries can tell you a document doesn't conform to its schema, but stop there, leaving a developer or a support engineer to eyeball a payload with forty nested fields looking for the one that's wrong. data.json_validate is built around the assumption that the answer to 'is this valid' is never the useful part — the useful part is exactly where and why it isn't, returned as a JSON Pointer path straight to the failing field along with the specific rule it violated.
Sending a document and its schema
POST both your JSON document and the schema to validate it against to /data/json-validate, and you'll get a task_id back immediately while validation runs in the background. The result — a pass/fail verdict plus a structured list of every violation, each with its exact path and the schema rule it broke — arrives through a signed webhook call or waits behind a signed link valid for 24 hours.
What JSON Schema actually checks
JSON Schema, standardized through drafts published since 2010 and now on its 2020-12 version, lets you describe not just a document's shape but its constraints — required fields, string patterns, number ranges, enum values, nested object rules — as a document written in the same JSON format it validates. That's what separates real schema validation from a shallow type check: it can catch a required field silently missing, a string that doesn't match an expected pattern, or a number outside an allowed range, none of which a basic 'is this valid JSON' parser would ever notice.
Where validation earns its keep in automation
The obvious place is at an API boundary, rejecting malformed payloads from clients before they reach business logic, but the less obvious and arguably more valuable use is inside a pipeline that processes JSON from many sources — partner feeds, LLM output, user uploads — where silently accepting a slightly wrong document causes a failure three steps downstream that's much harder to trace back. Because the task is async, priced per request and never billed on a failure that's actually the validator's own error, a pipeline can validate every document that flows through it as a matter of course rather than treating validation as an occasional manual check.
Integration use cases
API request validation before processing
A backend validates incoming JSON payloads against its API schema before they reach business logic, rejecting malformed requests with a specific error path.
LLM output verification
An automation pipeline validates structured JSON returned by a language model against an expected schema before acting on any of its fields.
Partner feed quality checks
A data platform validates each incoming partner JSON feed against a shared schema and flags any record that violates it before it enters the warehouse.
Config file correctness in CI
A CI pipeline validates JSON configuration files against a schema on every commit, catching typos and missing required fields before deployment.
Technical questions
How do I validate JSON against a schema with the API?
POST your JSON document and its JSON Schema to /data/json-validate, save the returned task_id, and receive the validation result by webhook or a signed link valid for 24 hours.
Is the JSON Schema validator API free?
No, there is no free tier or trial; it costs $0.002 per request, and a failed request due to a service-side error is never charged.
What does the error output actually contain?
For each violation, you get the exact JSON Pointer path to the failing field, the schema rule it broke, and a human-readable message explaining why.
Which JSON Schema draft does it support?
It supports modern JSON Schema drafts, including 2020-12, covering standard keywords like required, type, pattern, enum and nested object and array rules.
Can I use it to validate LLM-generated JSON?
Yes, validating structured output from a language model against an expected schema before acting on it is one of the most common uses of this endpoint.
Can I validate many documents in bulk?
Yes, submit one async task per document and collect each result by webhook as it completes, which fits pipelines validating high volumes.
Is my JSON data stored after validation?
No, submitted documents and schemas are deleted after the retention window and are never used for training.