Paste any OpenAPI 3.x or Swagger 2.0 spec (JSON or YAML), browse its endpoints visually, pick a schema structure — request body, response, path params — and validate your JSON payload against it instantly.
OpenAPI (formerly Swagger) is the industry-standard specification format for describing REST APIs. An OpenAPI document defines every resource, HTTP method, parameter, request body, and response schema in a machine-readable format (JSON or YAML). Validating a JSON payload against an OpenAPI spec means checking that a real-world request or response matches the schema the API was designed to accept or return.
This tool parses any Swagger 2.0 or OpenAPI 3.x spec, renders its endpoints in an interactive visual tree, and lets you validate JSON payloads against any schema structure in the spec — all without installing anything.
POST /users) to select it. The right panel shows the available schema structures for that operation.The tool supports both major specification versions. OpenAPI 3.x uses requestBody, components/schemas, and $ref references. Swagger 2.0 uses body parameters and definitions. Both JSON and YAML spec formats are accepted.
Most real-world specs define reusable schemas in components/schemas (OpenAPI 3.x) or definitions (Swagger 2.0) and reference them via $ref: "#/components/schemas/User". This tool resolves all internal $ref references automatically before validation.
The validator checks: required fields, property types (string, number, integer, boolean, object, array), string constraints (minLength, maxLength, pattern), numeric constraints (minimum, maximum, multipleOf), array constraints (minItems, maxItems, uniqueItems), enum values, string formats (email, uuid, date, date-time, uri), additionalProperties, and composition keywords allOf, oneOf, anyOf.
1. Paste your OpenAPI spec (YAML or JSON)
2. Click POST /users in the tree
3. Select "Request Body"
4. Paste {"name":"Alice","email":"alice@example.com"}
→ ✓ Valid — or see exact field errors1. Paste spec
2. Click the failing endpoint
3. Select "Response 4xx"
4. Paste the raw error JSON from your API logs
→ See if your error matches the defined schemaYes. The tool auto-detects the version from the openapi or swagger field at the root of your spec. Both JSON and YAML formats are accepted for both versions.
No. All parsing and validation happens entirely in your browser. Your spec and payload never leave your device. The tool works offline once loaded.
Yes. Internal $ref references (e.g., #/components/schemas/User or #/definitions/User) are resolved automatically. External $ref pointing to other files or URLs are not supported — paste the full spec as a single document.
The validator covers: type, required, properties, additionalProperties, enum, format (email, uuid, date, date-time, uri), minLength/maxLength, pattern, minimum/maximum/exclusiveMinimum/exclusiveMaximum, multipleOf, minItems/maxItems/uniqueItems, items, allOf, oneOf, anyOf.
The built-in YAML parser handles all standard OpenAPI YAML patterns: nested mappings, sequences, quoted strings, anchors are not supported. If your spec uses YAML anchors (&anchor, *alias) or multi-document streams, convert it to JSON first using a tool like the JSON Beautifier.
Yes. After selecting an operation, you can choose "Response 2xx", "Response 4xx", or "Response 5xx" to validate against the corresponding response schema. This is useful for testing that your API actually returns what it promises in the spec.
Error paths use JSONPath notation. $ is the root of the JSON object. $.user.email means the email field inside the user object. $.items[2].name means the name field of the third element in the items array. This helps you pinpoint exactly which field is invalid.
External $ref (e.g., $ref: "./schemas/user.yaml") cannot be resolved because the browser has no file-system access. Inline the referenced schemas into your spec before pasting, or use a tool like swagger-parser CLI to bundle them first: swagger-bundle --input api.yaml > api-bundled.yaml.