By Zod 4.5 shipped in late August and most TypeScript developers missed it. Not because it was quiet — the official release notes are dense — but because the headline change doesn’t look like a headline change. It’s a one-line wrapper. What that wrapper does, though, is push compiled Zod to 47.5 million ops/sec on the Moltar parseSafe benchmark, past Typia, which needs an ahead-of-time codegen step to reach 45.3 million. Zod now beats the build-step libraries without a build step. That’s worth a second look.
What z.compile() Does
z.compile() takes any Zod schema and returns a new schema with a precompiled fast-path validator. It works by walking your schema once and generating a flat, loop-free JavaScript function, executed via new Function(). That function runs on every subsequent parse instead of the full schema traversal. The API doesn’t change — compiled schemas behave identically to uncompiled ones — and there’s no bundler plugin, no codegen script, no build step.
// Before
const UserSchema = z.object({
name: z.string(),
age: z.number().int().min(0),
});
// After — one line, same API surface
const UserSchema = z.compile(
z.object({
name: z.string(),
age: z.number().int().min(0),
})
);Compilation is lazy: it happens on the first parse call, not at module load. If you want to compile everything globally without wrapping individual schemas, add import "zod/compile" at your app entry point — or run node --import zod/compile app.js. Every schema in the process gets compiled automatically.
One honest caveat: z.compile() uses new Function(), which a strict Content Security Policy will block. In CSP-restricted environments — browser extensions, some Cloudflare Workers configs — compilation silently falls back to standard validation. No crash, just no speedup. Use z.withParser() in those environments.
The Memory Win Is Separate
Compilation gets the headline, but the memory reduction matters more for most production systems. Before 4.5, a bare z.string() schema retained about 7.5KB of heap. After 4.5, it’s 784 bytes — roughly a ninefold reduction, achieved by memoising bound methods instead of allocating them per instance.
A typical backend service with a few hundred Zod schemas for route validation, request bodies, and shared types now uses a few hundred kilobytes of heap instead of a few megabytes. For serverless functions where cold start memory footprint matters, this is not a rounding error. The same release also made safeParse() about 7.5x cheaper on invalid input by skipping stack-trace capture on failure paths — exactly where validation is doing real work under load.
z.validate(): The Boolean Shortcut
Zod 4.6 (released September 9, two weeks after 4.5) added .validate(), a boolean-only check that never constructs a ZodError. On a compiled schema, it runs up to 35x faster than .safeParse().success. On uncompiled schemas it’s about 5.9x faster.
// Express/Hono middleware — you don’t need the error, just the gate
if (!UserSchema.validate(req.body)) {
return res.status(400).send("Invalid payload");
}
// Proceed knowing the shape is correct
const user = UserSchema.parse(req.body);Use .validate() for middleware guards, pre-flight checks, and anywhere you’re making a binary decision before doing the actual parse. Don’t reach for it when you need error details to return to the caller.
When Not to Compile
Compilation adds a one-time setup cost. If you’re creating schemas dynamically per-request — building a schema inside a route handler based on input parameters — the compilation overhead negates the gains. Compile at module load, not inside request paths. And as noted, CSP environments need different handling.
The Other Additions
Zod 4.5 also restored z.deepPartial(), which v4.0 had dropped. It now recurses through arrays, tuples, unions, records, and wrappers — not just the top-level object. The companion z.exactPartial() does one level deep. z.creditCard() validates 12–19 digit card numbers with a Luhn checksum and accepts space or hyphen separators. Eight new error locales shipped alongside these helpers.
Where This Leaves the Validator Landscape
The “just use Valibot for performance” argument isn’t dead, but it now needs qualifications. Valibot is still 13x smaller in bundle size — a real advantage for client-side code. But on the parseSafe benchmark, compiled Zod at 47.5M ops/sec leaves Valibot (1.8M) and ArkType (152k) well behind. And unlike codegen-dependent validators, Zod didn’t need to become a compile-time code generator to get there.
If you’re running Zod in a Next.js API route, a tRPC router, or a Hono backend — which covers a lot of TypeScript developers — the upgrade path is one line. Add import "zod/compile" at your entry point, bump to 4.5 or later, and you’re done. The schemas don’t change. The API doesn’t change. The performance does.
