Getting started in 5 minutes
StrictJSON turns a plain-language description into a strict system prompt, a JSON Schema, and matching Zod and Pydantic code. Four steps, no account, no setup. Here is the whole flow, followed by a complete example you can run.
Step 1 — Describe
Open the tool and describe, in plain words, the object you want the model to return. Name every field, its type, and what is required. Be specific about what must never be invented: if a field is missing from the source text, the model should say so, not guess. Example description: “Extract the title and the author of a book from a catalog entry. Both fields are required strings, at least one character long. Never invent a value that is not printed in the entry.”
Step 2 — Generate
Click Generate. The request runs through the server-side model chain — Gemini, then Groq, then two OpenRouter models — with automatic verification at each step. You get back four things: a system prompt to paste into your own API call, the raw JSON Schema, a Zod schema for TypeScript, and a Pydantic model for Python. The free tier allows 10 generations per day per IP; if you need more, add your own OpenRouter key — it stays in your browser only (see the FAQ).
Step 3 — Copy
Copy the pieces you need. Use the system prompt in your call to OpenAI, Claude, or Gemini — each provider accepts the JSON Schema as a constraint, so the model returns an object that matches it. Copy the Zod or Pydantic code into your project. The library holds twelve ready-made examples, including a full book / ISBN extractor, if you want to start from something tested instead of from scratch.
Step 4 — Validate
Never trust the model's output directly. Parse it, then validate it with the code you just copied — before it reaches your database or your users. If validation fails, the data is wrong, not your schema: check the values, regenerate, or tighten the description. A strict schema makes the output predictable; your own validation makes it trustworthy.
A complete mini-example
Take the description from Step 1 and feed it a catalog entry like “The Name of the Wind, by Patrick Rothfuss.” The tool generates this schema:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"title": { "type": "string", "minLength": 1 },
"author": { "type": "string", "minLength": 1 }
},
"required": ["title", "author"],
"additionalProperties": false
}
And this is all the validation code you need — Zod in TypeScript:
Zod (TypeScript)
import { z } from "zod";
const BookSchema = z
.object({
title: z.string().min(1),
author: z.string().min(1),
})
.strict();
const book = BookSchema.parse(JSON.parse(modelOutput));
Or the equivalent in Python with Pydantic v2:
from pydantic import BaseModel, Field
class Book(BaseModel):
title: str = Field(..., min_length=1)
author: str = Field(..., min_length=1)
book = Book.model_validate_json(model_output)
If the model returns {"title": "The Name of the Wind", "author": "Patrick Rothfuss"}, both validators accept it. If it invents an extra key, renames a field, or returns an empty string, both reject it — and your code finds out immediately, instead of discovering the problem three tables later. That is the whole point.
What to try next
Once the book example works, make the description stricter and watch the schema change: add an ISBN field with a pattern, or a publication year constrained to a realistic range. Then try one of the twelve tested examples in the library — the receipt parser and the meeting action-items extractor are good second steps, because they show how a schema handles lists and optional fields. Each generation costs one of your ten free daily generations, so spend them on descriptions you actually plan to use.
Next, read Why Strict JSON? to understand what a schema can and cannot guarantee, or Zod vs Pydantic vs JSON Schema to choose the validation format that fits your stack.