Zod 4.5

Zod

15 min read Original article ↗

Zod 4.5 is now available.

At a glance:

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–9. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiledTime per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121kBar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench.

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124kBar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

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.

nub.jsonc

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#5931)

Back in functional form after being removed as a method in Zod 4. (#5928)

The result is still a ZodObject, so .shape and .extend() keep working.

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#6065)

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#5928)

This is a no-op on schemas not containing codecs/pipes.

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#5913)

Extract a discriminated union member by discriminator value. (#5947)

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#6387, #6482)

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Heap retained by one schema instance on a shared kilobyte axis, zod 4.4.3 as a gray bar with the 4.5 size as a blue bar inside it: a 10-key object 82.0kb to 11.0kb (7.4x), a union 17.5kb to 2.13kb (8.3x), z.string().min(1) 16.7kb to 3.37kb (5.0x), a record 16.4kb to 2.64kb (6.2x), z.string().optional() 12.6kb to 1.50kb (8.4x), an array of strings 11.2kb to 1.93kb (5.8x), z.string() 7.53kb to 784b (9.8x), z.number() 4.44kb to 706b (6.4x); up to 9.8x less memory than 4.4.3Heap retained by one schema instance on a shared kilobyte axis, zod 4.4.3 as a gray bar with the 4.5 size as a blue bar inside it: a 10-key object 82.0kb to 11.0kb (7.4x), a union 17.5kb to 2.13kb (8.3x), z.string().min(1) 16.7kb to 3.37kb (5.0x), a record 16.4kb to 2.64kb (6.2x), z.string().optional() 12.6kb to 1.50kb (8.4x), an array of strings 11.2kb to 1.93kb (5.8x), z.string() 7.53kb to 784b (9.8x), z.number() 4.44kb to 706b (6.4x); up to 9.8x less memory than 4.4.3

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#6316, #6450)

Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x fasterBar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#6448)

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️ z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#6457)

To accept both forms, union the two precisions:

⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#6441)

Closes #3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#6412)

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #2200, #2573, #4017, #5663.

⚠️ __proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#6213, #6367, #6346). (#6386, #6354, #6355, #6221)

⚠️ Stricter string formats

  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#6442).
  • z.ulid() restricts the first character to 0–7; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#6024).

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @dokson, @deepshekhardas, @zirkelc, @francisjohnjohnston-web, @MerlijnW70, @codinsonn, @oimo23, @JSap0914, @zelinewang, @abhishek-chaudhary2003, @spokodev, @Mohammad-Faiz-Cloud-Engineer, @hamed-bavar, @MGPOCKY, @ChiChuRita, @dinwwwh, @thristhart, @tsmartin9, @vedanshshetti, @belicam, @frastefanini, @andersk, @musaddiq-rafi, @tachmyratsaparmyradov, @arvindfroi, @KUMachine, @spidersouris, @catdalfonso, @mneetika, @gwagjiug, @MahinAnowar, @MaksZhukov, @emmayusufu, @agcty, @devareddy05, @Vish05, @yamcodes, @mattiasahlsen, @samchungy, @ozzyfromspace, @udohjeremiah, @patrickwehbe, @gajus, @Harm-Nullix, @thwbh, @IdanGonen, @irfanfandi, @JuerGenie, @marcalexiei, @itsahmedbilal, @DucMinhNe, @meliharik.