Why Strict JSON?
Large language models are very good at writing text that looks like JSON. That is not the same as writing JSON your code can rely on. Ask a model for a JSON object and, sooner or later, you will get one of three failures — and each of them breaks your program in a different place.
The three ways free-form JSON breaks
1. Invented keys. You asked for email; the model returns email_address, or adds a helpful extra field like notes that your code never expected. Your parser survives, but the field you need is missing and the extra one silently pollutes your data.
2. Truncated JSON. The model runs out of tokens mid-object. The response ends with an unclosed brace, a half-written string, or a list that never closes. JSON.parse() throws, and you lose the entire answer — including the perfectly good fields that came before the cut.
3. Parsing that breaks. Trailing commas, single quotes instead of double quotes, unescaped quotes inside strings, markdown fences wrapped around the object, or a short apology sentence before the opening brace. Any one of these makes strict JSON parsers fail, and the usual fix — stripping fences with a regex — is a hack that breaks again on the next edge case.
None of this means the model is bad at the task. It means you asked for a data format using only words, and words are not a contract. A strict schema turns the request into a contract: these fields, these types, nothing else.
What strict mode changes, provider by provider
The major providers now let you attach a schema to the request itself, so the model is constrained while it generates — not corrected afterwards.
- OpenAI — Structured Outputs. Pass
response_formatwith ajson_schemaandstrict: true. The API then guarantees the output is valid JSON matching your schema — no fences, no extra keys, no missing required fields. - Claude — tool use. Define a tool with an
input_schemadescribing exactly the object you want. The model must call the tool with arguments that match the schema, which gives you the same shape guarantee through a different mechanism. - Gemini — JSON mode. Set
response_mime_typetoapplication/jsonand supply aresponse_schema. Gemini then returns JSON conforming to that schema, with no surrounding prose.
In all three cases the principle is identical: the schema moves from your prompt into the API call, where the provider can enforce it. That is exactly what StrictJSON generates for you — the system prompt, the JSON Schema, and the matching validation code in Zod, Pydantic, or plain JSON Schema, from a single plain-language description.
When strict is not enough
A strict schema guarantees shape, not truth. A model can return a perfectly valid object with a perfectly invented value: a well-formed email address that does not exist, a plausible-looking ISBN that was never printed, a date in the right format for an event that never happened. No schema can catch that, because the value obeys every rule you wrote.
That is why server-side validation is still necessary, even with strict mode on. Validate the parsed object again in your own code — with Zod, Pydantic, or a JSON Schema validator — before it touches your database. Check ranges, not just types: an age of 250 is a valid integer and a nonsense age. Check values against your own data where it matters: does this product ID exist? Is this email already registered? Re-validate on every request, because a schema constrains the model, not the network, not the client, and not a future model version.
The practical rule is simple: a strict schema makes the model's output predictable; your own validation makes it trustworthy. Use both, and the JSON that reaches your code is boring in the best possible way — the same shape, every time, with nothing to parse around and nothing to guess.