Introducing z.compile()
Colin McDonnell··3 min read
Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.
This can lead to dramatic speedups, especially for container types like objects, arrays, unions, and tuples.
A compiled schema like CompiledPlayer is a Zod schema like any other. There are no special rules around compiled schemas.
- Same methods:
.parse(),.safeParse(),.extend(),.optional(), etc. - Same inferred input and output types
- Same issues and error messages
Use it exactly like Player:
Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.
How it works
Take this simple Point schema:
Here is the generated snippet for it:
For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.
This is the function Zod generates for the Player schema above:
Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.
INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.On invalid input the fallback runs the uncompiled schema, so the error is the uncompiled schema's error.
Compile all the things!
If you import "zod/compile" in the entry point of your application, Zod enables compile-by-default—all schemas you declare will self-compile the first time you use them. This gives you the performance boost of compilation throughout your application with one line of code.
Then use Zod normally:
Compilation is lazy, so only the schemas you actually parse with get compiled.
It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:
Or set preload in bunfig.toml or nub.jsonc.
If new Function() is blocked by a Content Security Policy (e.g. in Cloudflare Workers environments) default-on compilation mode gracefully stands down and becomes a no-op.
Speedups
Containers like objects and tuples benefit the most, since compilation unrolls the runtime's per-key walk into flat loop-free validation logic that can be optimized by the JS engine.
The benefits scale with schema complexity. Each schema here is measured alone in a tight loop — the standard parser's best case — so the ratios run lower than in the mixed-workload chart above (benchmark).
| object | speedup |
|---|---|
| 5 keys | 1.8x |
| 10 keys | 2.2x |
| 20 keys | 5.0x |
| 50 keys | 10.2x |
| tuple | speedup |
|---|---|
| 1 item | 2.2x |
| 3 items | 2.5x |
| 5 items | 3.0x |
| 10 items | 3.7x |
Tradeoffs
The compiler trades off performance for bundle size. The compiler is a lot of code, and invoking it via z.compile() or "zod/compile" means it will be included in your bundle. It adds about 7 KB gzipped (28 KB minified): a Zod bundle with a four-key object schema goes from 24.1 KB to 31.1 KB gzipped, and a Zod Mini bundle from 4.6 KB to 13.2 KB. A bundle that never calls z.compile() or imports zod/compile pays nothing; it will be tree-shaken completely during bundling.
Try it
Then z.compile() any schemas on the hot path, or import "zod/compile" at the top of your entry point.