Search DevTools

Jump to any tool or page

JSON Schema Visualizer

Paste a JSON Schema to see it as a diagram with nodes and edges. Each property, object, and array becomes a node.

Schema Input

paste a JSON Schema

Schema Diagram

The diagram appears here as you type.

Data Transformation

About JSON Schema Visualizer

Render a JSON Schema as a navigable tree, showing required fields, types, constraints, and how definitions reference one another. Schemas become hard to read long before they become large, because $ref indirection and combinators like allOf scatter a single object's real shape across parts of the document that never appear adjacent.

Related Data Transformation tools

JSON FormatterImage to JSONPII RedactorSheet to JSONJSON to CSV/XLSX

Frequently asked questions

How do $ref and $defs actually resolve, and what breaks?
A $ref is a URI reference resolved against the current base URI, which $id can change partway through a document — so the same pointer string can resolve differently depending on where it sits. Internal pointers use JSON Pointer syntax like #/$defs/Address, where ~0 and ~1 escape literal tilde and slash characters in key names. Two failures dominate: a pointer to a path that does not exist, and a recursive reference that a naive resolver expands until it exhausts the stack.
What is the difference between allOf, anyOf, and oneOf in practice?
allOf requires the instance to validate against every subschema, which is how composition and inheritance are expressed. anyOf requires at least one match and stops caring after that. oneOf requires exactly one, which is stricter and a frequent source of confusion — if two branches both accept an instance, oneOf fails even though the data looks fine. That happens easily when branches are distinguished only by an optional field, so oneOf usually needs a discriminating required property to work as intended.
Why does additionalProperties not behave as I expect with allOf?
Because additionalProperties: false only sees properties declared in the same schema object, not those contributed by sibling subschemas. Combine a base type under allOf with a branch that closes the object, and the branch rejects every property the base declared, since from its own perspective they are additional. This is the single most reported surprise in JSON Schema. The usual remedies are unevaluatedProperties, which does account for sibling keywords, or simply not closing composed objects.
Which draft am I on, and does it matter?
Considerably. Draft-04 used an exclusiveMinimum boolean alongside minimum; later drafts made it a number, so the same document means different things under different validators. Draft-07 introduced if/then/else, and 2019-09 replaced definitions with $defs and added unevaluatedProperties. Draft 2020-12 changed array handling, splitting items into prefixItems for tuples and items for the rest. Always declare $schema explicitly, because a validator guessing the wrong draft may silently ignore keywords rather than error.
Why do my format constraints not reject invalid values?
Because format is an annotation by default, not an assertion. A validator is permitted to collect format values and report them without checking anything, and many do exactly that unless format assertion is explicitly enabled. So a field marked format: email happily accepts "not-an-email" in a default configuration. If validation genuinely matters, pair format with a pattern regex or turn assertion on deliberately, and be aware that format: date-time implementations vary in how strictly they read RFC 3339.