Structured Output Schema Tester

Test OpenAI structured output JSON schemas against sample responses.

Paste a JSON schema and a sample LLM response to validate conformance. See missing required fields, type mismatches, and additionalProperties violations before you ship structured output to production. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What does OpenAI structured output require?

When you use strict structured outputs, every object must list all of its properties in required, and additionalProperties must be false. This tool checks those constraints and flags any field present in the response but absent from the schema, which is a common cause of strict-mode validation failures.

Catch structured-output failures before production

OpenAI’s strict structured outputs enforce a precise contract: every property must be declared, all of them must be in required, and additionalProperties must be false. A response that looks fine to the eye can still fail validation because of one undeclared field or one missing required key. This tool compares your schema against a sample response and reports every mismatch with its exact path.

How it works

Paste your JSON Schema and a sample response object. The tool parses both, then walks the schema recursively against the data. At each level it checks the declared type, confirms every required field is present, recurses into nested objects and array items, and — when additionalProperties is false — flags any property in the data that the schema does not declare. Each problem is reported with a dotted path like data.address.zip so you can pinpoint it instantly.

The four failure modes it catches

Structured output validation fails in predictable ways. The conformance report flags each of these specifically:

  1. Missing required field — the schema declares a field as required but the model response omits it entirely. Common with optional-looking fields (e.g. "middle_name") that you forgot to either remove from required or guarantee in the prompt.
  2. Type mismatch — the schema says "type": "integer" but the model returned "3" (a string). Strict mode rejects this even though the value looks numeric.
  3. Undeclared property — the model added a field ("confidence": 0.9) that exists in the response but is not in the schema’s properties. With additionalProperties: false, this causes a hard rejection.
  4. Nested object violations — the three problems above can occur at any depth. A path like result.address.zip in the report tells you the violation is three levels deep.

Worked example

Suppose your schema requires a user object with name (string) and age (integer), and the model returns:

{ "user": { "name": "Alice", "age": "30", "nickname": "Ali" } }

The report would show two problems: user.age has a type mismatch (expected integer, got string) and user.nickname is an undeclared property. Fix the prompt to force a numeric age and remove any instruction that suggests a nickname, then re-run the test until the report shows zero violations.

Tips for strict-mode schemas

  • Set "additionalProperties": false on every nested object, not just the root. A missing flag deep in a nested schema is a common source of failures that look unexplained.
  • Keep "required" listing every property. In strict mode, omitting a field from required is not the same as making it optional — OpenAI’s strict mode requires all declared properties to be listed there.
  • If the model keeps hallucinating extra fields, name the undesired fields in your prompt and explicitly say not to include them, rather than leaving the schema to handle it alone.
  • Use this tool iteratively — fix one path, re-run with a fresh sample, and repeat until the report is empty before wiring the schema into your production response_format.