JSON Schema 验证器

在浏览器中即时校验 JSON 是否符合任意 JSON Schema。支持 Draft 2020-12、2019-09 与 Draft-07，错误信息精确定位到 JSON Pointer 路径。100% 隐私保护，零上传、零账号、永久免费。

无追踪浏览器中运行免费

Draft 版本:

JSON 数据

JSON Schema

请同时粘贴 JSON 数据与 schema

已对 Draft 2020-12、2019-09 与 Draft-07 的兼容性进行评审，覆盖类型胁迫边缘场景、format 词汇表、$ref 解析与 JSON Pointer 错误路径。 — Go Tools API 工具组 · 2026年5月7日

什么是 JSON Schema 验证器？

JSON Schema 验证器接收两份 JSON 文档 —— 一份数据、一份 schema —— 并报告数据是否符合 schema 的契约。Schema 用一组固定词汇（type、properties、required、items、enum、oneOf、allOf、$ref、format）声明字段类型、必需键、值范围、允许的 enum 值、正则 pattern 与结构规则。校验器并行遍历两份文档，输出零或多条错误，每条都精确定位到数据内部的 JSON Pointer 路径。

校验在运行时执行，处于不可信输入与你的代码之间的边界。TypeScript 类型在编译期就被擦除，对来自 webhook、第三方 API 或用户粘贴的 JSON 无能为力 —— 这正是 JSON Schema 要填补的空白。把它和 TypeScript（或 Python 中的 Pydantic）配合，就能在代码内部获得编译期保证、在边界获得运行时保证。

Draft 2020-12 是当前规范，2026 年新项目应当首选。早期 draft（2019-09、Draft-07、Draft-06、Draft-04）仍存活于历史代码中 —— Draft-07 在 Helm chart、VS Code settings 与旧版 Ajv 配置中仍十分常见。OpenAPI 3.1 原生使用 Draft 2020-12；OpenAPI 3.0 使用的是 Draft 4 子集。

本工具完全在浏览器中运行。你的 JSON、schema 与校验输出都不会离开你的机器 —— 可安全用于内部 API 契约与敏感 payload。内部 $ref 指针自动解析；外部 HTTP ref 出于隐私考虑被有意禁用。

配合相邻的 JSON 工具？粘贴前用 JSON 格式化工具整理 JSON；用 JSON Diff 对比比较两份 JSON；用 JSON 转 YAML 与 YAML 转 JSON 做格式互转。要看 Node、Python 与浏览器端的端到端校验示例，请阅读我们的 JSON Schema 校验指南。

// A 5-line schema that catches three real bugs
const schema = {
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id":    { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "age":   { "type": "integer", "minimum": 0, "maximum": 150 }
  },
  "required": ["id", "email"],
  "additionalProperties": false
};

// Three bugs the schema catches:
const bad = { "id": "42", "age": 200 };
//   /id   → type: expected integer, got string
//   /email → required: missing
//   /age   → maximum: 200 > 150

// In Node:        new Ajv().compile(schema)(bad)  // false; ajv.errors has the paths
// In Python:      jsonschema.validate(bad, schema)
// In the browser: this tool — same errors, same paths, no install

核心特性

多 Draft 支持

Draft 2020-12（默认）、2019-09 与 Draft-07。从 schema 的 $schema URI 自动识别 draft；未声明时使用下拉框作为回退。

路径精确的错误信息

每条错误都包含 JSON Pointer（如 /user/email/0）、失败的 keyword（type、required、pattern）与一句话说明。点击即可跳转到对应位置。

实时校验

输入时即时校验。错误实时更新，调试 schema 或数据无需反复点击 Validate 按钮。

format Keyword 全覆盖

email、uri、uuid、date、date-time、ipv4、ipv6、hostname、regex —— 全部使用经过实战检验的 pattern 校验。

100% 浏览器端

输入永不离开你的机器。零上传、不对粘贴内容做分析、不把 JSON 写入 localStorage。可安全用于内部契约与敏感 payload。

示例 schema 一键加载

可加载预设（注册表单、webhook 信封、配置文件、订单数组），五秒内进入可工作的校验状态。

示例

合法对象 — required + 类型校验

{
  "id": 42,
  "email": "alice@example.com",
  "age": 30
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id": { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "age": { "type": "integer", "minimum": 0, "maximum": 150 }
  },
  "required": ["id", "email"],
  "additionalProperties": false
}

Schema 将 id 与 email 声明为 required 并锁定类型。上方数据满足全部约束，校验通过。试着删掉 email 或把 id 改成字符串，就能看到精确路径的错误提示。

不合法 — 缺失 required + 类型错误

{
  "id": "42",
  "age": 200
}

{
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "format": "email" },
    "age": { "type": "integer", "maximum": 150 }
  },
  "required": ["id", "email"]
}

三处错误：/id 是字符串而非 integer、/email 缺失、/age（200）超过 maximum 150。每条错误都附带 JSON Pointer 路径，无需猜测就能修数据 —— 或者放宽 schema。

判别联合 — oneOf 配合 const

{
  "type": "order.created",
  "data": { "orderId": "ORD-001234", "totalUsd": 49.99 }
}

{
  "oneOf": [
    {
      "properties": {
        "type": { "const": "order.created" },
        "data": {
          "type": "object",
          "properties": {
            "orderId": { "type": "string", "pattern": "^ORD-[0-9]{6}$" },
            "totalUsd": { "type": "number", "minimum": 0 }
          },
          "required": ["orderId", "totalUsd"]
        }
      },
      "required": ["type", "data"]
    },
    {
      "properties": {
        "type": { "const": "order.refunded" },
        "data": { "type": "object", "required": ["refundId"] }
      },
      "required": ["type", "data"]
    }
  ]
}

Webhook 信封校验。第一个 oneOf 分支因 type 为 "order.created" 而命中。把 type 改为 "order.refunded" 或破坏 orderId 的 pattern，可看到 oneOf 如何按分支汇报失败。

对象数组 — items + uniqueItems

[
  { "sku": "A1", "qty": 3 },
  { "sku": "B2", "qty": 5 },
  { "sku": "A1", "qty": 3 }
]

{
  "type": "array",
  "minItems": 1,
  "uniqueItems": true,
  "items": {
    "type": "object",
    "properties": {
      "sku": { "type": "string", "pattern": "^[A-Z][0-9]+$" },
      "qty": { "type": "integer", "minimum": 1 }
    },
    "required": ["sku", "qty"]
  }
}

两条记录字节级一致，uniqueItems 触发。索引 0 与 2 重复 —— 校验器会在数组根上报告。适合捕获购物车重复行与合并冲突的发货请求。

使用方法

1

粘贴 JSON Schema

把 schema 粘贴到右栏。校验器会从 $schema URI 自动识别 draft；缺失时从工具栏选择 Draft 2020-12、2019-09 或 Draft-07。
2

粘贴 JSON 数据

把要校验的 JSON 文档粘贴到左栏。输入时实时校验；超过 200 KB 的大输入会切换到手动 Validate 按钮，保证输入流畅。
3

阅读错误列表

每条错误都有 JSON Pointer 路径、keyword 与一句话说明。点击错误跳转到数据中的对应位置，修好后看错误数量实时下降。

常见的 JSON Schema 陷阱

type：integer 与 number 之分

JSON Schema 把 1.0 视为 number 而非 integer。如果你的契约写了 integer，校验器会拒绝 1.0 —— 即便大多数语言认为它等于 1。除非真的需要 integer，否则用 number。

✗ 错误

{ "qty": 1.0 }   schema: { "type": "integer" }   → error: not an integer

✓ 正确

{ "qty": 1 }     schema: { "type": "integer" }   → valid

required 写在错误的嵌套层级

required 必须与 properties 同级，不能写在某个 property 内部。写在 property 声明里的 required 数组会被静默忽略 —— 校验器永远不会强制它。

✗ 错误

{ "properties": { "name": { "type": "string", "required": true } } }

✓ 正确

{ "properties": { "name": { "type": "string" } }, "required": ["name"] }

additionalProperties 默认是 true

不写 additionalProperties: false，schema 默认开放 —— 任何额外键都会通过。这是 schema「什么都接受」最常见的原因。

✗ 错误

{ "properties": { "id": { "type": "integer" } } }   accepts: { "id": 1, "foo": "bar", "x": null }

✓ 正确

{ "properties": { "id": { "type": "integer" } }, "additionalProperties": false }

OpenAPI 3.0 nullable 与 Draft 2020-12 type 数组

OpenAPI 3.0 用 nullable: true；Draft 2020-12 用 type: ["string", "null"]。混用会得到看起来正确、实际上从不允许 null 的 schema。

✗ 错误

{ "type": "string", "nullable": true }   in 2020-12: nullable is just an unknown keyword

✓ 正确

{ "type": ["string", "null"] }   in 2020-12: explicitly allows null

pattern 没有锚点

JSON Schema 正则默认是部分匹配 —— pattern: "^[A-Z]+$" 锚定整串，但 pattern: "[A-Z]+" 只要字符串里出现一个大写字母就会通过。

✗ 错误

pattern: "[A-Z]+"   accepts: "helloX"   (because X matches)

✓ 正确

pattern: "^[A-Z]+$"   accepts only: "HELLO"

用了 oneOf 实则想表达 anyOf

oneOf 要求恰好一个分支匹配。如果两个分支都接受同一形状，oneOf 会在 anyOf 本可通过的数据上失败 —— 错误信息也很费解（"matches more than one"）。

✗ 错误

oneOf: [ { type: "string" }, { type: "string", maxLength: 10 } ]   on: "hi"   → error: matches both

✓ 正确

anyOf: [ { type: "string" }, { type: "string", maxLength: 10 } ]   on: "hi"   → valid

常见使用场景

API 请求校验: 上线前粘贴请求体与端点 schema，提前发现测试覆盖不到的 400 响应 —— 缺失的必需字段、错误的类型、超范围的数值。
Webhook Payload 验证: 厂商发来的 payload 被你的 handler 拒绝？用你的 schema 校验实际 payload，再用厂商发布的 schema 校验一次，二者的差就是 bug 所在。
配置文件 Lint: package.json、tsconfig.json、helm values.yaml —— 每种配置文件都有公开 schema。粘贴 schema、粘贴配置、找到拼写错误，跳过反复试错。
OpenAPI 组件测试: 从 OpenAPI 3.1 文档中拿出一个 schema 组件，粘到这里校验示例 payload。比起 mock 服务器更快、确定性更高，不需要任何 SDK。
表单提交预演: 在接前端校验之前粘一份示例表单 payload。确认 schema 拒绝你预期会拒绝的、接受你预期会接受的，再把同一份 schema 部署到客户端与服务端。
数据管道契约检查: ETL 输出漂移了？粘一行示例数据与下游 schema，定位是哪个生产者改动、哪些键破坏了契约 —— 别等管道把 1 万条记录全部重试一遍。

技术细节

Draft 2020-12 兼容: 实现已发布的 Draft 2020-12 规范 —— keyword、类型系统、format 词汇表。与 Ajv 8.x 及 ajv-formats 输出交叉对比验证。
JSON Pointer 错误路径: 错误使用 RFC 6901 JSON Pointer（/user/email/0）。每条 keyword 失败都精确指向数据中唯一可解析的位置 —— 没有歧义、不需要字符串搜索。
内部 $ref 解析: 解析单文档内的 $ref 指针（#/$defs/foo、#/properties/bar）。检测并报告引用环。出于隐私考虑禁用外部 HTTP $ref。

最佳实践

始终设置 additionalProperties: false: 在输入契约（请求体、配置文件、队列消息）上，未声明的键通常都是 bug —— 拼写错误、误加字段或攻击者探测。默认拒绝它们。
用 $defs 复用子 Schema: 同一形状内联两遍，迟早会漂移。把共享定义放进 $defs，用 $ref 引用 —— 单一真相来源，一次修改全部生效。
在业务逻辑之前先校验: JSON.parse 之后立刻跑 schema 校验，再去碰解析后的结构。类型收窄、默认值填充、持久化都假设契约成立 —— 先确保它真的成立。

常见问题

什么是 JSON Schema 校验？

JSON Schema 校验用来检查一份 JSON 文档是否符合按 JSON Schema 语法编写的契约。Schema 声明字段类型、必需键、允许值与结构规则；校验器并行遍历两份文档，把所有违反契约的路径汇报出来。它运行在不可信输入（API 请求、Webhook、配置文件、表单 payload）和业务逻辑之间的边界，把数据形状错误挡在下游代码之外。完整端到端示例可看我们的 JSON Schema 校验完整指南，包含 Node、Python 与浏览器全链路。

这个校验器支持哪些 JSON Schema Draft 版本？

支持 Draft 2020-12（默认且推荐）、Draft 2019-09 与 Draft-07。校验器会从 schema 的 $schema URI 自动识别 draft 版本；缺失时回退到下拉框选择。2026 年新项目请用 Draft 2020-12 —— OpenAPI 3.1 原生采用它，Ajv 也以它为默认。Draft-07 在历史代码中仍很常见（旧版 Ajv、Helm chart、VS Code settings）。

如何用 schema 校验 JSON？

把 JSON 数据粘贴到左栏，把 JSON Schema 粘贴到右栏。输入时实时校验 —— 绿色对勾表示通过，红色列表表示错误。每条错误都带 JSON Pointer 路径（如 /user/email）、失败的 keyword（type、required、pattern、minimum 等）以及一句人类可读的说明。点击任意错误即可跳转到对应行。零上传、零注册。

JSON Schema 校验和 JSON 语法校验有什么区别？

JSON 语法校验只确认文档能否解析 —— 没有多余逗号、没有缺失大括号，JSON 格式化工具负责这一步。JSON Schema 校验在解析之后运行，检查解析后的结构是否符合契约：必需字段是否齐全、类型是否正确、值是否在范围内。两者通常配合使用 —— 先格式化确认可解析，再用 schema 做语义校验。

为什么看起来正确的 JSON 却被 schema 拒绝？

五个常见嫌疑：(1) additionalProperties: false —— 数据里多了 schema 没声明的键，多半是拼错或新加字段；(2) type: "integer" 与 "number" —— JSON Schema 把 1.0 视为 number 而非 integer；(3) format keyword（email、uri、uuid）会拒绝看起来正常但实际畸形的字符串；(4) required 写在了错误的嵌套层级 —— required 必须与 properties 同级，不能写在某个 property 内部；(5) JSON 里是字符串 "42"，而 schema 期望 integer 42。错误路径会精确告诉你是哪一种。

支持 $ref 与远程 schema 引用吗？

内部 $ref 指针（#/$defs/foo、#/properties/bar）开箱即用。指向外部 URL 的远程 $ref 被有意禁用 —— 拉取外部 schema 会把校验行为泄露给第三方，破坏隐私模型。如要校验多文件 schema，建议用 $defs 把被引用定义内联进单一文档；或者在你自己的 CI 里用 Ajv 跑校验，那里使用远程 ref 才合适。

additionalProperties: false 是做什么的？

additionalProperties: false 会拒绝任何未在 properties 中声明的键。它是收紧契约最有用的 keyword —— 不加的话，schema 默认是开放的，会静默接受拼错的或恶意的字段。输入契约（请求体、配置文件、队列消息）一律设 additionalProperties: false；只有当 schema 是更大文档的部分描述时，才让它保持 true（或省略）。

如何在 Node.js 或 Python 中用 schema 校验 JSON？

Node：安装 Ajv（npm i ajv ajv-formats），调用 new Ajv().compile(schema) 后 validate(data)。Python：安装 jsonschema（pip install jsonschema），调用 jsonschema.validate(data, schema)。TypeScript 项目可用 json-schema-to-typescript 从 schema 生成类型，让编译期与运行时保持同步。我们的 JSON Schema 校验指南提供 Node、Python、浏览器三端的可粘贴示例。

oneOf、anyOf 与 allOf 有什么区别？

allOf —— 必须满足所有子 schema（交集，常用于组合）。anyOf —— 至少满足一个（并集，快速通过）。oneOf —— 必须恰好满足一个（判别联合，更严格但更慢）。oneOf 适合按 type 标记的 webhook 事件；anyOf 适合宽松的并集；allOf 适合在基础 schema 上叠加约束。oneOf 最慢，因为要测试每个分支 —— 不强制「恰好一个」时优先用 anyOf。

支持 OpenAPI schema 吗？

OpenAPI 3.1 原生使用 Draft 2020-12，因此任何 OpenAPI 3.1 的 schema 组件可直接粘贴。OpenAPI 3.0 用的是 Draft 4 子集，大部分兼容 —— 但可能在 nullable: true（3.0 语法）上踩坑，Draft 2020-12 的等价写法是 type: ["string", "null"]。完整 OpenAPI 文档（路径、操作、安全）的校验请用 Spectral 这类专门的 OpenAPI lint 工具，本工具专注 schema 部分。

为什么校验器说我的 JSON Schema 本身不合法？

JSON Schema 首先是一份 JSON 文档，必须先是合法 JSON 才能成为合法 schema。常见原因：properties 对象里有尾随逗号、用了单引号而非双引号、$schema 指向不存在的 draft URL，或者 required 写成了字符串而不是数组。先在 JSON 格式化工具中校验语法，再粘回这里做语义校验。

工具会把我的 JSON 或 schema 发送到服务器吗？

不会。所有解析与校验都在你的浏览器本地运行。你的 JSON、你的 schema、校验结果都不会离开你的机器 —— 零上传、不会把输入存到 localStorage、不会对粘贴内容做分析埋点。可放心用于内部 API 契约、私有配置文件与敏感 payload。仅你选择的 draft 版本会持久化到 localStorage 以便刷新后保留，清除浏览器数据即可重置。

可以校验 JSON Lines（NDJSON）或多份文档吗？

本工具单次只校验一份文档。JSON Lines 请逐行校验，或在 Node 中用 Ajv 配合 JSONStream 这类流式解析器。大批量数据集校验更适合命令行 —— ajv-cli 或 check-jsonschema（Python）只编译一次 schema 就能每秒处理数千文件。

JSON Schema 验证器

什么是 JSON Schema 验证器？

核心特性

多 Draft 支持

路径精确的错误信息

实时校验

format Keyword 全覆盖

100% 浏览器端

示例 schema 一键加载

示例

合法对象 — required + 类型校验

不合法 — 缺失 required + 类型错误

判别联合 — oneOf 配合 const

对象数组 — items + uniqueItems

使用方法

粘贴 JSON Schema

粘贴 JSON 数据

阅读错误列表

常见的 JSON Schema 陷阱

type：integer 与 number 之分

required 写在错误的嵌套层级

additionalProperties 默认是 true

OpenAPI 3.0 nullable 与 Draft 2020-12 type 数组

pattern 没有锚点

用了 oneOf 实则想表达 anyOf

常见使用场景

技术细节

最佳实践

常见问题

相关工具

Base64 解码与编码工具

JSON Diff 对比

JSON 格式化与验证工具

JSON 转 YAML 转换器

二维码生成器 — URL / WiFi / vCard / Email / SMS / 位置

URL 编码解码在线工具 — 内置 URL 结构解析