Skip to content

JSON Schema Validator With Human Errors

Check a document against a JSON Schema and get errors that name the value, the expectation and the line — plus the list of keywords in your schema that were not checked.

Everything on this page runs in your browser. Nothing is uploaded, logged or sent anywhere — your input is kept in the address bar so a link reopens it, which also means anything you paste travels with the link. Do not share a link to a payload you would not publish.

Result
6 failures

Every failure below carries the path in your document, the keyword that rejected it, and the line and column in the text you pasted.

Failures

  1. must fixMissing required property "currency"line 1, column 1

    the top-level value · keyword `required` — The object has "curency" — one or two characters apart. That is a rename somewhere, not a missing value.

    {
    ^
  2. must fixDoes not match `^INV-[0-9]{6}$`line 2, column 17

    $.invoice_id · keyword `pattern` — Found "INV-4821". Note that JSON Schema `pattern` is an unanchored search: without `^` and `$` it passes as long as the expression matches somewhere inside the string.

      "invoice_id": "INV-4821",
                    ^
  3. must fixExpected number, found stringline 3, column 12

    $.total · keyword `type` — $.total is "1284.50". The value is the string "1284.50", not the number 1284.5 — the quotes are the entire difference. Models emit numbers as strings whenever the example in the prompt showed them quoted.

      "total": "1284.50",
               ^
  4. must fixNot a valid `date`line 5, column 13

    $.issued · keyword `format` — Found "12/04/2026". `format` is an annotation by default in JSON Schema — many validators do not assert it at all, so check whether yours does before relying on this.

      "issued": "12/04/2026",
                ^
  5. must fixExpected integer, found numberline 13, column 14

    $.lines[1].qty · keyword `type` — $.lines[1].qty is 0.5. 0.5 is a number but not an integer. `integer` means no fractional part, not "small".

          "qty": 0.5
                 ^
  6. must fix"curency" is not allowed hereline 4, column 14

    $.curency · keyword `additionalProperties` — The schema declares "currency", which is 1 character(s) away. Almost certainly the same field under a different name.

      "curency": "EUR",
                 ^

What was checked

Verified: additionalProperties, enum, format, items, minItems, minimum, multipleOf, pattern, properties, required, type.

Found in your schema and NOT checked: nothing. Every keyword in this schema is one this tool implements.

Never checked, by design: remote $ref (anything not starting #), $dynamicRef, $anchor, unevaluatedProperties, unevaluatedItems, contentEncoding and contentMediaType.

What this assumes: the schema is interpreted as JSON Schema 2020-12; format is asserted for the nine formats listed above and treated as an annotation otherwise, which is the specification's own default and probably not what your validator does; pattern is compiled as a JavaScript regular expression, which accepts a few things ECMA-262 does not and is unanchored unless you write ^ and $; and string lengths are counted in Unicode code points.

Why the error messages are the point

Most validators tell you that #/properties/total/type failed. That sentence contains the schema path, which you already had, and nothing about your data, which is what you needed. The messages here name the value that failed, the value that was expected, and where in the text you pasted it lives — and when the failure is a near miss, they say so: a required property that is missing while a property one character away is present is a rename, not an omission, and saying "the object has curency" ends the search immediately.

The three failures that account for most of them

A number arriving as a string, because the example in the prompt showed it quoted. An enum miss that is a capitalisation difference. And additionalProperties: false rejecting a field the model spelled differently from the schema. All three are reported here with the specific difference rather than as a type error, because the fix for each is different: the first is a prompt or a coercion step, the second is either normalisation or a looser enum, the third is a schema that is stricter than your prompt is specific.

What a pass here does not mean

It means no keyword in the supported list rejected your document. It does not mean the document is right. A schema that says type: object and nothing else accepts everything, and this page will happily report no failures — which is why the coverage box lists what your schema actually constrained. Read that list before you rely on a pass, and read the "not checked" line before you rely on it in a pipeline. If a keyword you depend on is in that list, your real validator is enforcing something this page is not.

JSON Schema Validator With Human Errors · Multigrid