TK TaskKit
Developer Tools

JSON Schema Validator

Validate JSON against a schema with full error paths. Draft-07 and 2020-12, format checks, all-errors mode.

Schema
Data
Validation

Could not compile schema: Code generation from strings disallowed for this context

Inputs stay on this device. Every developer tool on TaskKit runs entirely in your browser. Tokens, payloads, and pasted text are not transmitted to TaskKit servers or third parties.

What this tool does

Validates a JSON document against a JSON Schema, returning either "valid" or a list of errors with the exact instance path and schema path for each failure. Supports both Draft-07 and Draft 2020-12, auto-detected from the schema's $schema field, with manual override. Format checks (email, uri, date-time, uuid, etc.) are enabled.

When you'd use it

  • Designing a new schema and trying it against representative payloads.
  • Diagnosing why your API rejected a request — does the body really match the docs?
  • Verifying that a config file follows your team's schema before committing.
  • Migrating between Draft-07 and 2020-12 and checking nothing broke.

How it works

Under the hood this uses Ajv (the JSON Schema validator behind most JS tooling), pinned to all-errors mode so you see every problem at once instead of stopping at the first. Format checks come from ajv-formats. Both schema and data are parsed locally; nothing is sent anywhere.

Draft selection: if the schema has "$schema": "https://json-schema.org/draft/2020-12/schema" we use the 2020-12 dialect; "http://json-schema.org/draft-07/schema#" selects Draft-07. With no $schema, we default to Draft-07 because it's still the most common in the wild.

Notes

additionalProperties defaults to allowed — is that right? Yes, per the spec. If you want to forbid extra fields, set "additionalProperties": false explicitly. This is the single most common cause of "I thought my schema was strict" surprises.

What's the difference between Draft-07 and 2020-12? 2020-12 reworks references ($dynamicRef), splits items into items and prefixItems, and changes how additionalItems is handled. Most everyday schemas work in both, but if you use tuple validation, the syntax is incompatible.

Why does my regex pattern match different things in different validators? JSON Schema specifies ECMA-262 regex syntax (the JavaScript flavor). Validators in other languages translate, sometimes imperfectly. Test patterns in the Regex Tester to be sure.

Related tools