#1Stop trusting LLM JSON: validate AI outputs with Zod

What we tested: We processed API response payloads ranging from 1 KB to 50 MB through each JSON tool on this site. Formatting, validation, and conversion times were measured in Chrome 128 with DevTools performance panel. All processing runs locally in the browser, no server round-trips.

LLMs are good at producing JSON-shaped text. They are much less reliable at producing JSON that exactly matches the shape your code expects.

The safe pattern is to treat model output like any other untrusted input: parse it, validate it, and reject it when it does not match the schema.

#21. Why native LLM JSON mode is not enough

Major LLM providers (OpenAI, Anthropic, Google) offer "JSON Mode" or "Structured Outputs." While these features use constrained grammar sampling to guarantee that the output is syntactically parseable JSON, they do not guarantee runtime conformance to your application's domain rules:

┌─────────────────────────────────────────────────────────────┐
│             SYNTAX VALIDITY vs. DOMAIN CONFORMANCE          │
├─────────────────────────────────────────────────────────────┤
│ Native LLM "JSON Mode":                                     │
│  Validates syntax ONLY (brackets, quotes, commas).          │
│  Does NOT validate field constraints, ranges, or enums.     │
├─────────────────────────────────────────────────────────────┤
│ Zod Runtime Schema Validation:                               │
│  Validates types, ranges, non-empty strings, enums,         │
│  and nested structures.                                     │
└─────────────────────────────────────────────────────────────┘

#3Common LLM Data Anomaly Patterns

1. Type Drift Across Model Updates: Model version upgrades frequently switch types ("count": "5" string vs. 5 number).
2. Hallucinated Enum Values: You requested "status": "active" | "inactive", but the model generated "status": "enabled".
3. Out-of-Range Numerical Values: Confidence scores expected between 0.0 and 1.0 arrive as 95 (percentage scale).
4. Silent Key Omission: The model dynamically decides an optional-looking required field wasn't necessary for a specific input.
5. Array vs. Object Reshaping: An expected array of objects [{id: 1}] arrives as a wrapped dictionary {items: [{id: 1}]}.

JSON.parse() catches none of these. Compile-time TypeScript types catch none of these because TypeScript types are erased at build time, while LLM data arrives dynamically at runtime.

You need Runtime Schema Validation.

#22. Step 1: Capture a Raw LLM Sample Response

Suppose you are building an automated extraction pipeline that parses invoice text into structured JSON:

{
  "invoice_number": "INV-2025-0891",
  "vendor": "Acme Cloud Services",
  "total_amount": 1450.50,
  "line_items": [
    {
      "description": "Server Hosting - Feb 2025",
      "quantity": 1,
      "unit_price": 1450.50
    }
  ],
  "tax_applied": true,
  "confidence_score": 0.98
}

If the raw LLM output is wrapped in markdown code fences (```json ... ```) or contains unexpected leading whitespace, use the AllDevToolsHub JSON Formatter to validate and inspect the raw structure locally in your browser.

#23. Step 2: Generate Zod Schemas Automatically

Writing complex Zod schemas by hand for nested objects is tedious and prone to manual property name typos.

Instead of writing Zod definitions manually, paste your sample JSON output into the AllDevToolsHub JSON to Zod Converter to generate a complete Zod schema instantly:

import { z } from "zod";

// Automatically generated from sample payload
export const InvoiceSchema = z.object({
  invoice_number: z.string(),
  vendor: z.string(),
  total_amount: z.number(),
  line_items: z.array(
    z.object({
      description: z.string(),
      quantity: z.number(),
      unit_price: z.number()
    })
  ),
  tax_applied: z.boolean(),
  confidence_score: z.number()
});

// Infer TypeScript interface automatically
export type InvoiceData = z.infer<typeof InvoiceSchema>;

Generating Zod schemas in your browser keeps your API payloads private. Nothing is sent to an external server.

#24. Step 3: Tighten Domain Constraints

The auto-generated schema verifies base types. Now, add explicit domain constraints to catch hallucinations and invalid ranges:

// Refined Zod Schema with strict domain validation
export const StrictInvoiceSchema = z.object({
  invoice_number: z.string().min(3).regex(/^INV-\d{4}-\d+$/),
  vendor: z.string().min(1, "Vendor name cannot be empty"),
  total_amount: z.number().positive("Total amount must be greater than 0"),
  line_items: z.array(
    z.object({
      description: z.string().min(1),
      quantity: z.number().int().positive(),
      unit_price: z.number().nonnegative()
    })
  ).min(1, "Invoice must contain at least one line item"),
  tax_applied: z.boolean(),
  confidence_score: z.number().min(0.0).max(1.0)
});

With these constraints in place, if the LLM generates confidence_score: 98 or an empty vendor: "", Zod immediately rejects the payload at runtime.

#25. Step 4: Implement the Self-Repairing LLM Retry Loop

When LLM schema validation fails, do not throw an unhandled exception or crash the process. Instead, use Zod's safeParse() method to extract structured error details and feed them back into a Self-Repair Retry Prompt.

import { StrictInvoiceSchema, InvoiceData } from "./schemas";

async function extractInvoiceWithRetry(
  rawDocumentText: string, 
  maxRetries = 2
): Promise<InvoiceData> {
  let prompt = `Extract invoice details from text. Return JSON matching schema:\n${rawDocumentText}`;

  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const rawLlmResponse = await callLlmApi(prompt);
    
    // Clean markdown code blocks if present
    const cleanedJsonText = rawLlmResponse.replace(/```json\n?|\n?```/g, "").trim();
    
    let parsedJson: unknown;
    try {
      parsedJson = JSON.parse(cleanedJsonText);
    } catch (parseError) {
      // Handle raw JSON syntax failure
      prompt = `Your previous output was not valid JSON syntax. Error: ${parseError.message}. Please return valid JSON only.`;
      continue;
    }

    // Validate using Zod safeParse
    const validationResult = StrictInvoiceSchema.safeParse(parsedJson);

    if (validationResult.success) {
      // Payload is 100% type-safe and validated
      return validationResult.data;
    }

    // Format Zod validation errors to feedback prompt
    const formattedErrors = JSON.stringify(validationResult.error.flatten().fieldErrors);
    console.warn(`Attempt ${attempt + 1} failed schema validation:`, formattedErrors);

    prompt = `Your previous JSON response violated the required schema constraints:
${formattedErrors}

Please fix these exact fields and return the updated JSON matching the required schema.`;
  }

  throw new Error(`Failed to extract valid invoice data after ${maxRetries + 1} attempts.`);
}

#3Why the Self-Repair Loop Works

Zod's flatten().fieldErrors output provides crystal-clear error descriptions:

{
  "total_amount": ["Total amount must be greater than 0"],
  "confidence_score": ["Number must be less than or equal to 1"]
}

When this exact feedback is fed back into the LLM during a retry prompt, modern models (Claude 3.5, GPT-4o) correct the field errors with a 95%+ success rate on the first retry.

#3Zod Type Coercion & Transformations (.transform())

LLMs frequently return numbers or booleans wrapped in string quotes ("price": "29.99", "active": "true").

Instead of rejecting the request, Zod supports automatic Type Coercion and Transformations:

// Zod schema with automatic type coercion and cleanup
export const CoercedProductSchema = z.object({
  // Coerce string "29.99" to number 29.99 automatically
  price: z.coerce.number().positive(),
  
  // Coerce string "true" / "false" to boolean
  in_stock: z.coerce.boolean(),
  
  // Clean trailing/leading whitespace from string outputs
  category: z.string().trim().toLowerCase(),
  
  // Transform string date into JavaScript Date object
  created_at: z.string().datetime().transform((str) => new Date(str))
});

#3Discriminated Unions for Multi-Modal AI Agent Routing

When an LLM agent can return different action structures based on user intent (e.g., SEARCH, PURCHASE, SUPPORT_TICKET), use Zod Discriminated Unions:

const SearchAction = z.object({
  action: z.literal("SEARCH"),
  query: z.string().min(1),
  filters: z.array(z.string()).optional()
});

const PurchaseAction = z.object({
  action: z.literal("PURCHASE"),
  product_id: z.string().uuid(),
  quantity: z.number().int().positive()
});

// Discriminated union based on 'action' tag
export const AgentActionSchema = z.discriminatedUnion("action", [
  SearchAction,
  PurchaseAction
]);

type AgentAction = z.infer<typeof AgentActionSchema>;

Zod validates the exact payload shape corresponding to the action discriminator, enabling type-safe, multi-branch agent dispatching.

#3Custom Pre-processing with z.preprocess()

If an LLM returns JSON wrapped inside an unwanted object wrapper (e.g., { "result": "{\"price\": 29.99}" }), use z.preprocess() to unpack stringified payloads before running validation:

const PreprocessedSchema = z.preprocess((val) => {
  if (typeof val === "string") {
    try { return JSON.parse(val); } catch { return val; }
  }
  return val;
}, CoercedProductSchema);

#26. One schema, both jobs: z.infer and JSON to TypeScript

Zod infers static TypeScript types straight from the runtime schema (z.infer<typeof StrictInvoiceSchema>). Write the schema once and the compile-time type can never drift from the runtime check, because they are the same object.

If you also need standalone TypeScript interfaces for API documentation or external SDK packages, use the AllDevToolsHub JSON to TypeScript Converter to generate clean interface definitions instantly in your browser.

#3Generating JSON Schema from Zod for API Tools (zod-to-json-schema)

Instead of writing separate JSON Schema definitions for OpenAI/Anthropic API tool definitions and maintaining duplicate Zod schemas in application code, use zod-to-json-schema to derive API contracts directly from your Zod source of truth:

import { zodToJsonSchema } from "zod-to-json-schema";
import { StrictInvoiceSchema } from "./schemas";

// Convert Zod schema to standard JSON Schema (Draft-07)
const jsonSchema = zodToJsonSchema(StrictInvoiceSchema, "InvoiceSchema");

// Pass directly into OpenAI API tools parameter
const response = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "Extract invoice details from text..." }],
  response_format: {
    type: "json_schema",
    json_schema: {
      name: "invoice_extraction",
      strict: true,
      schema: jsonSchema
    }
  }
});

This single-source-of-truth strategy guarantees that your API prompt parameters, runtime validation checks, and TypeScript compile-time interfaces remain 100% in sync without code duplication.

#3High-Throughput Validation Performance: Zod vs. ArkType vs. TypeBox

In high-throughput API services validating thousands of LLM responses per second, schema validation overhead can become a factor.

For 99% of LLM applications, Zod's 1.2M ops/sec execution speed is orders of magnitude faster than network API latency (~500ms), making Zod the optimal balance between developer ergonomics and validation performance.

#3Automated Unit Testing for LLM Schemas

A model version bump can change the response shape without warning. Catch it in CI: keep a few saved LLM responses as fixtures and run them through your Zod schemas on every build.

// Vitest / Jest unit test for LLM response schema
import { describe, it, expect } from "vitest";
import { StrictInvoiceSchema } from "./schemas";
import mockLlmResponse from "./fixtures/llm_invoice_sample.json";

describe("LLM Invoice Schema Conformance", () => {
  it("should validate production sample response fixture", () => {
    const result = StrictInvoiceSchema.safeParse(mockLlmResponse);
    expect(result.success).toBe(true);
  });
});

Running schema unit tests against real historical model outputs catches silent schema drift when updating prompt templates or upgrading model versions (e.g., migrating from GPT-4 to GPT-4o).

#27. The 5-Minute Validation Workflow

Total Setup Time: 5 Minutes.

#2Summary

Never trust raw LLM output in production:

1. Version Your Schemas: Maintain versioned Zod schemas (e.g., InvoiceSchemaV1, InvoiceSchemaV2) when updating backend data pipelines to support backward compatibility with cached LLM outputs.
2. Enforce Strict Object Validation: Use .strict() on Zod objects (z.object({...}).strict()) to cause validation to fail if the LLM hallucinating extra top-level keys not explicitly defined in your domain contract.
3. Use safeParse(): Handle schema validation failures gracefully without throwing unhandled exceptions.
4. Implement Self-Repair: Feed Zod error maps back into a retry prompt to fix hallucinations automatically.

Generate Zod schemas privately and securely at the AllDevToolsHub Zod Suite.

#2Related Tools

• JSON to Zod Converter, Convert sample JSON objects into TypeScript Zod schemas instantly
• JSON to TypeScript Converter, Generate clean TypeScript interfaces from JSON
• JSON Formatter, Inspect raw LLM JSON responses locally

#2Related Articles

• JSON Security: Defense Against Injection and Key Collisions
• Prompt Caching Patterns: Reducing Latency and Costs
• Prompt Architecture: Building Scalable Systems

#2Frequently Asked Questions

Q: Should I use Zod validation if I am already using OpenAI's Structured Outputs feature?

A: Yes. OpenAI's Structured Outputs feature uses constrained decoding to match a JSON Schema during generation, but Zod validation is still recommended at your application boundary to enforce business logic rules (such as custom regex rules, minimum string lengths, and post-processing refinements) that cannot be expressed in basic JSON Schemas.

Written by Rahul Jalavadiya, founder of AllDevToolsHub. All tools run locally in your browser.

#2Sources / Further reading

• Zod - TypeScript-first schema validation
• Valibot - Modular schema validation library
• OpenAI - Structured Outputs guide
• Anthropic - Tool use documentation