JSON 格式化与校验
开发者
关于此工具
使用详细的路径级错误消息验证JSON数据是否符合JSON Schema。
使用方法
- 1 将JSON数据粘贴到左侧，将JSON Schema粘贴到右侧，然后点击"验证"检查合规性。内置的纯JS验证器支持type、required、properties、字符串长度、数字范围、数组大小和enum约束。错误以完整的JSON路径（如$.user.age）报告，让您能够精确定位问题。
- 2 第1步：在左侧面板中粘贴或编辑JSON数据（已预填示例供您入门）。
- 3 第2步：在右侧面板中粘贴或编辑JSON Schema，定义预期的结构和约束。
- 4 第3步：点击"验证"按钮运行验证。
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:
| Applies to | Keyword | Meaning |
|---|---|---|
| Any value | type | Must be string, number, object, array, boolean, or null |
| Any value | enum | Must exactly match one of a fixed list of allowed values |
| Objects | required | Listed keys must be present |
| Objects | properties | Defines a sub-schema for each named key |
| Strings | minLength / maxLength | Character-count bounds |
| Numbers | minimum / maximum | Inclusive value bounds |
| Arrays | minItems / maxItems | Length bounds, with items validating each element |
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
enumandrequired.
Common mistakes
- Confusing "absent" with "wrong type."
requiredonly fires when a key is missing. If a key is present butnull, you needtype(or to include"null"in an allowed type list) to catch it. - Expecting unlisted properties to be rejected. Extra keys not named in
propertiesare simply ignored here — they do not cause an error. Plan your schema knowing that unknown fields pass through. - Off-by-one on bounds.
minimumandmaximumare inclusive, andminLengthcounts 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.