Validate API Responses
against JSON Schema

API validation in four steps

No account. No upload. No nonsense.

Related JSON tools

Common questions answered

What is API response validation?

API response validation checks that data returned by an HTTP endpoint matches the expected structure. This matters because APIs evolve: new fields appear, types change, optional fields become null, and nested objects gain new properties. Without validation, these silent changes propagate through your application and surface as confusing bugs far from their origin.

This tool lets you paste an API response and validate it against a JSON Schema or simply check that it is valid JSON. For APIs that return deeply nested data, the tree view lets you inspect every field and its type. Combined with the diff tool, you can compare two versions of an API response to see exactly which fields changed between releases.

{
  "status": 200,
  "data": {
    "users": [
      {"id": 1, "name": "Alice"},
      {"id": 2, "name": null}
    ]
  }
}

✓ Valid JSON
  Type: object (2 keys)
  Depth: 4 levels
  Fields: status, data,
    data.users (array of 2)

Get the most out of this tool

• Save a baseline API response and use the diff tool to detect structural changes after deployments.
• Validate responses from third-party APIs before caching — invalid data in your cache causes cascading failures.
• Use the tree view to visually inspect deeply nested API responses instead of scrolling through raw JSON.

How API response validation works

API response validation is the process of verifying that a response payload conforms to an expected schema — asserting that required fields are present, values have correct types, strings match expected patterns, and arrays contain properly structured elements. Unlike simple JSON syntax validation (which only checks that the JSON is parseable), schema validation checks semantic correctness: a parseable JSON response with the wrong field names or unexpected null values fails schema validation even though it passes syntax validation.

JSON Schema is the standard vocabulary for describing JSON data shapes. An API response validator uses JSON Schema to define contracts: "type": "object" asserts the response is an object, "required": ["id", "name"] asserts those fields must be present, "properties": {"id": {"type": "integer"}} asserts the type of each field. When the actual response is validated against this schema, any deviation — a missing field, a string where an integer is expected, or an extra undeclared field when additionalProperties: false is set — is reported as a validation error.

API contract testing extends schema validation across API versions. By validating responses against a schema that reflects the published API contract, teams can detect breaking changes automatically. A field that was previously a string and is now a number, a required field that was removed, or a new required field added without a default — all are detected as schema violations. Consumer-driven contract testing (CDCT) using tools like Pact takes this further by capturing consumer expectations and verifying them against the provider.

OpenAPI 3.0 specifications include response schema definitions using JSON Schema-compatible syntax. API validators can use the response schemas from an OpenAPI spec directly, validating live responses against the specification. This "spec-first validation" approach ensures that the API implementation matches its documentation, preventing documentation drift where the spec and implementation diverge over time. Tools like Dredd and Prism perform this spec-to-implementation validation automatically.

Validation of paginated API responses requires validating both the envelope structure and the item structure. A paginated response typically has a top-level object with data, total, page, and pageSize fields, where data is an array of items. The JSON Schema for this response uses "items" to define the schema for each element in the data array, enabling validation of both the pagination envelope and each individual item independently.

Error response validation is as important as success response validation. A well-designed API returns consistent error shapes — typically an object with error, message, and code fields. Validating that 4xx and 5xx responses conform to the error schema ensures that error handling code in clients can rely on a consistent structure rather than defensively handling many possible error formats. Schema validation of error responses is often overlooked in API testing.

Auto-generating JSON Schema from sample API responses accelerates the validation setup. Rather than writing schema definitions from scratch — a tedious and error-prone process for complex responses — the schema generator analyzes a sample response and produces an initial schema that can be refined. Required fields must be added manually (the generator can only observe presence, not requirement), and optional fields must be marked appropriately, but the generated schema provides a 70-80% complete starting point that dramatically reduces manual work.

Real-world API response validation scenarios

API response validation pitfalls

• Not validating error responses: Teams focus validation effort on successful (2xx) responses but neglect to validate error (4xx, 5xx) responses. Inconsistent error schemas are a major source of client-side bugs. Define and validate error response schemas with the same rigor as success schemas.
• Using additionalProperties: false prematurely: Setting additionalProperties: false in your schema rejects responses with any field not declared in the schema. This is too strict for API consumer validation — add a new field to the API response, and all consumers fail validation. Use it for producer-side validation but allow additional properties on the consumer side.
• Forgetting nullable fields: Many APIs return null for optional fields rather than omitting them. A schema that declares "type": "string" without "nullable": true (OpenAPI) or ["string", "null"] (JSON Schema) will reject null values that the API legitimately returns. Always check for nullable fields in your sample responses.
• Validating only the happy path: APIs behave differently under load, after rate limiting, or during partial outages. Validate responses from timeout scenarios, rate-limited requests (429), and server error responses (503) to ensure your error handling code has schemas to work with for all failure modes.

Additional frequently asked questions