JSON Schema validator that lists every failure

Valid and correct are different questions, and each has its own tool. Parsing decides whether the text is JSON at all; a schema decides whether the resulting value is the thing you agreed to exchange — that total is a number rather than the string "12.50", that status is one of four spellings rather than any word at all, that a line item cannot have a quantity of zero. A payload can be flawless JSON and wrong for its purpose in a dozen ways, which is exactly the gap a schema exists to close.

Draft 2020-12, the current one. Four of its changes matter in daily use: tuple validation moved out of items into prefixItems, so items now means “every remaining element” and nothing else; definitions became $defs; $ref may sit alongside other keywords instead of replacing them, which is why { "$ref": "#/$defs/Money", "minimum": 0 } now works as written; and $recursiveRef gave way to $dynamicRef. A draft-07 schema mostly runs here unchanged — an items array is accepted as tuple form with a note, and definitions resolves the same as $defs.

Because pattern is not anchored. JSON Schema borrows ECMA-262 regular expressions and applies them as a search, so "pattern": "[0-9]{3}" is satisfied by "abc123def" — the three digits are in there somewhere. Anchor it yourself with ^ and $ when you mean the whole string. The related trap is that ^ and $ match around line breaks only with the m flag, which a schema has no way to set, so a multi-line string cannot sneak past an anchored pattern.

No, and that is the specification's default rather than a shortcut. In draft 2020-12 format belongs to the format-annotation vocabulary, where it describes a value without asserting anything; asserting it is opt-in behaviour that a validator may offer and many do not. So date-time, email, uri and uuid are read and shown here, never enforced. If a format has to hold, back it with a pattern as well, and remember that the two most-requested formats — email and uri — have grammars no sane regular expression captures in full.

Because additionalProperties only sees the properties declared in the same schema object it appears in, and allOf puts them in different objects. A base schema listing three properties combined through allOf with an extension listing two more leaves each half unaware of the other's names, so additionalProperties: false in the base rejects the extension's own keys. This is the best-known sharp edge in the format, and draft 2019-09 added unevaluatedProperties precisely to solve it — a keyword this validator refuses rather than approximates, because getting it wrong would produce confidently incorrect verdicts.

No — 1.0 passes, and 1.5 fails. Since draft 6 the integer type means a number with a zero fractional part rather than a number written without a decimal point, so 1.0 and 1e2 both qualify. That is deliberate: JSON has one number type and languages disagree about how to write a whole one, so testing the value rather than the spelling is the only portable rule. Numbers are compared here as IEEE-754 doubles, the same as ajv, which means a 20-digit ID is compared as its rounded value even though the report prints the literal you supplied.

No, and a reference it cannot follow is reported as a failure rather than quietly skipped. Everything here runs in the browser with no server behind it, so there is nothing to fetch https://example.com/schemas/order.json with; only same-document JSON Pointers such as #/$defs/Address, #/definitions/Address and # itself resolve. Paste the referenced schema into $defs and repoint the $ref at it. Marking an unresolvable reference as passing would be the worst of the available answers — a document reported clean against a rule that never ran.