Structured Output Validator
Check model JSON output against your schema — type errors, missing fields, extras.
Supported subset: type, required, properties, items, enum, minimum, maximum. Other keywords are ignored.
5 violations (4 hard, 1 extra-field). Feed these errors back to the model for a targeted repair attempt.
- enum
priority— "Urgent" is not one of ["low","medium","high"] - type
estimate_hours— expected number, got string — looks like a stringified number ("4") - type
tags[1]— expected string, got number - missing
assignee.name— required field is missing - extra
reasoning— field not in schema
How it works
Two panes: your JSON Schema on the left, the model's output on the right. The validator checks the output against the schema instantly and locally, listing every missing required field, type mismatch, enum violation and out-of-range number with its exact path — plus extra fields the schema never asked for, behind a toggle, since whether those are errors depends on your consumer. A prefilled example shows several realistic failures on first paint.
The validator implements a deliberate subset of JSON Schema, documented honestly rather than hidden behind a "full support" claim: type, required, properties (nested to any depth), items, enum, minimum and maximum. That subset is not arbitrary — it is the part of the spec that structured-output schemas actually use, and the part where models actually fail. Conditional keywords like oneOf and $ref indirection are rare in output schemas precisely because models handle them poorly; if your schema needs them, you want a full library like Ajv in your pipeline, and this tool will have already caught the cheap failures first.
The failure taxonomy you will see most: stringified numbers, where the model emits "42" because the surrounding prose context primed quotation; dropped required fields, usually ones whose descriptions did not explain why they matter; paraphrased enums, where "high" becomes "High" or "urgent"; and hallucinated extras, often a "reasoning" or "notes" field the model added to be helpful. Each one is invisible if you trust the output and obvious if you validate — which is the entire argument for validating at every model boundary.
Use the verdict as a debugging loop while developing prompts: paste a real schema, paste real outputs, and watch which fields fail repeatedly. A field that keeps failing is rarely the model's fault alone — it is usually a schema description that does not say what the field is for, a type the surrounding prompt contradicts, or an enum whose values are not listed in the prompt text. Fix the schema and the prompt together, and re-validate until the failure rate justifies shipping.
Frequently asked questions
Which parts of JSON Schema does the validator support?
A documented, honest subset: type checking for object, array, string, number, integer, boolean and null; required field enforcement; nested properties to any depth; items for arrays; enum membership; and minimum/maximum for numbers. It does not implement allOf/anyOf/oneOf, pattern, format, additionalProperties as a schema, or $ref resolution. For most structured-output schemas — which are flat-to-two-level objects with typed fields — this subset covers everything that actually breaks.
Why do models produce schema-violating output at all?
Unless you use a provider's strict structured-output mode, the schema is a suggestion the model usually honors and sometimes does not — typical failures are numbers serialized as strings ('42' instead of 42), missing optional-looking required fields, hallucinated extra fields, enum values paraphrased ('hi' instead of 'high'), and trailing commentary wrapped around otherwise-valid JSON. Validation at the boundary turns these from silent data corruption into explicit, retryable errors.
What should my code do when validation fails?
The standard pattern is validate-and-repair: catch the failure, send the model its own output plus the specific validation errors, and ask it to fix exactly those issues — error-targeted repair succeeds far more often than blind retry. Cap repair attempts at one or two, then fall back to a default or surface the failure. Log every failure with its error list; recurring patterns tell you which schema field descriptions need clarifying.
Should extra fields be treated as errors?
It depends on your consumer, which is why it is a toggle here. If the output feeds a strict deserializer or a database insert, extra fields can break parsing or smuggle junk into storage, so flag them. If your consumer ignores unknown keys — most JSON parsers do — extra fields are cosmetic waste rather than corruption, though they cost output tokens and sometimes indicate the model misread the schema. Start strict, relax when you understand your failure modes.
Is anything I paste sent to a server?
No. The validator is implemented inline in this page's JavaScript and runs entirely in your browser — no network requests, no logging, no storage, verifiable in your devtools network tab. Model outputs frequently contain real user data and schemas encode your internal data model; neither should leave your machine for something as mechanical as a schema check.
Built by FORG — AI cost observability for agentic coding. Free tools, no signup, nothing leaves your browser.
Learn about FORG