JSON 整形 & 検証

What a JSON Schema actually checks

JSON Schema is a vocabulary for describing the shape of JSON data: which keys must exist, what type each value should be, and what range of values is acceptable. Validation answers a single question — does this document conform to those rules? — and, when it does not, tells you precisely where it broke. This validator works on a practical subset of JSON Schema Draft-07 and reports every failure with a full JSON path such as $.user.age, so a problem buried three levels deep in a nested object is pinpointed rather than vaguely flagged.

The keywords it understands fall into a few groups:

A worked example

The tool starts with a schema requiring name, age, and email, where age is a number between 0 and 120 and role must be one of admin, user, or guest. Suppose you change the data so age is "thirty" and role is "superadmin", then drop the email field. Click Validate and you get three precise errors: $.age: expected number, got string, $.role: value must be one of ["admin", "user", "guest"], got "superadmin", and $: missing required property "email". Each line names the exact path and the exact violation, which turns debugging a malformed API payload from guesswork into a checklist.

One detail worth knowing: when a value fails its type check, the validator stops drilling into that branch — there is no point applying minimum to something that is not a number — so you see one clean type error rather than a cascade of confusing follow-ups.

How nesting and recursion work

Validation is recursive. When the schema describes an object via properties, the validator descends into each matching key and validates the value against its sub-schema, extending the path as it goes ($.user.address.zip). For arrays, an items sub-schema is applied to every element, with the index baked into the path ($.tags[2]). This means a single error message can point you straight to the third tag in a list inside a user object inside the root — no manual counting required.

Genuine use cases

• API contract testing. Capture a real response from an endpoint and validate it against the schema your front end expects. If the backend quietly changes a field type, you find out before your UI breaks.
• Config-file safety. Many tools accept JSON config. A schema lets you confirm a hand-edited config has all required keys and sane ranges before deploying it.
• Form and import validation. Before importing a batch of records, check each one conforms so you reject bad rows early with a clear reason.
• Learning JSON Schema. The two-pane live setup lets you tweak a schema rule and immediately see how the verdict changes, which is the fastest way to build intuition for keywords like enum and required.

Common mistakes

• Confusing "absent" with "wrong type." required only fires when a key is missing. If a key is present but null, you need type (or to include "null" in an allowed type list) to catch it.
• Expecting unlisted properties to be rejected. Extra keys not named in properties are simply ignored here — they do not cause an error. Plan your schema knowing that unknown fields pass through.
• Off-by-one on bounds. minimum and maximum are inclusive, and minLength counts characters, not bytes — a multi-byte emoji may count differently than you expect.
• Invalid JSON in either pane. If the data or the schema itself is not parseable JSON, you get a parse error first; fix the syntax before the structural rules can even run.

How this differs from formatting your JSON

Pretty-printing or linting JSON only confirms the syntax is valid — that brackets and quotes are balanced. Schema validation goes a layer up: it confirms the semantics, that the right fields exist with the right types and values. A document can be perfectly formatted and still wildly wrong for your application; that gap is exactly what this tool closes. Everything runs locally in your browser, so your data and schema never leave your device — safe for proprietary payloads and internal API contracts.