/** @deprecated This parameter is deprecated. Use `error` instead. */ message?: string | undefined; // supported in Zod 3

If you don't provide a validation function, Zod will allow any value... You can customize the error message and other options by passing a second argument. This parameter works the same way as the params parameter of .refine. (also examples use `message: "Passwords do not match"`)

The code marks the `message` parameter as deprecated, directing users to `error`, but the docs still show `message` in `.refine()` examples (e.g. 'message: "Passwords do not match"') without any deprecation warning or migration hint. A developer following the docs would continue using deprecated API and miss the recommended `error` option.

Update the docs to replace `message` with `error` in all `.refine()` examples and add a note that `message` is deprecated, use `error` instead.

export function _cuid2<T extends schemas.$ZodCUID2>(Class: util.SchemaClass<T>, params?: string | $ZodCUID2Params | $ZodCheckCUID2Params): T

z.cuid(); z.cuid2(); z.ulid();

The docs mention `cuid2` and `ulid` in the string formats list, but `ksuid` and `xid` are completely missing from the docs. The code exposes `_ksuid` and `_xid` functions that validate KSUID and XID formats. Also, the docs list `z.cuid2()` and `z.ulid()` without dedicated sections, but that's minor. The key mismatch is the missing `ksuid` and `xid` entries.

Add `z.ksuid()` and `z.xid()` to the string formats list, and optionally add dedicated sections for them.

export function _guid<T extends schemas.$ZodGUID>(Class: util.SchemaClass<T>, params?: string | $ZodGUIDParams | $ZodCheckGUIDParams): T

(not documented)

The docs mention `guid` only in the context of UUIDs: 'To validate any UUID-like identifier: z.guid();' but the code exposes a full `_guid` function as part of the new format APIs. The string format list in the docs omits `z.guid()` entirely, which means developers won't discover this new format.

Add `z.guid()` to the string formats list, along with a short description.

export function _nanoid<T extends schemas.$ZodNanoID>(Class: util.SchemaClass<T>, params?: string | $ZodNanoIDParams | $ZodCheckNanoIDParams): T

(not documented)

The code provides a full `_nanoid` function, but the docs' string formats list omits `z.nanoid()`. Developers looking for NanoID validation won't find it in the docs.

Add `z.nanoid()` to the string formats list.

export function _base64<T extends schemas.$ZodBase64>(Class: util.SchemaClass<T>, params?: string | $ZodBase64Params | $ZodCheckBase64Params): T

z.base64(); z.base64url(); z.hex();

The docs list `base64`, `base64url`, and `hex` in the string formats list but do not provide dedicated sections or examples. The code exposes `_base64` and `_base64url` functions (and presumably `_hex` is available through `z.hex()`). This is a minor omission because they are at least mentioned, but the documentation is thinner than for other formats.

Add brief descriptions and examples for `z.base64()`, `z.base64url()`, and `z.hex()`.

export function _nativeEnum<T extends util.EnumLike>(Class: util.SchemaClass<schemas.$ZodEnum>, entries: T, params?: string | $ZodEnumParams): schemas.$ZodEnum<T>

Use `z.enum()` for externally declared TypeScript enums. The `z.nativeEnum()` API is deprecated.

The docs correctly state that `z.nativeEnum()` is deprecated, but the `z.enum()` documentation says it accepts enum-like objects and TypeScript enums, which matches the code. The mismatch is mild: the docs do not provide a migration path or indicate that `z.nativeEnum` is removed in Zod 4 (the code still exports `_nativeEnum`). It's fine, but the deprecation notice could be more prominent.

Add a deprecation notice next to `z.nativeEnum` examples, and direct users to `z.enum()` for all enum cases.

/** @deprecated */

**Deprecated** — `z.promise()` is deprecated. There are vanishingly few valid uses cases for a `Promise` schema.

The docs do warn that `z.promise()` is deprecated, but the code marks it with an explicit `@deprecated` JSDoc. The docs mention it, so it's not a missing warning, but the deprecation is not carried through to the API reference as strongly. This is a minor issue.

Consider adding a note that `z.promise()` will be removed in a future major version.

export type $ZodIPv4Params = StringFormatParams<schemas.$ZodIPv4, "pattern" | "when" | "version">;

const ipv4 = z.ipv4();
ipv4.parse("192.168.0.0"); // ✅

The docs for IP addresses only show basic usage, but the code's params include `version`, `pattern`, and `when`. The docs do not mention the `version` option for `z.ipv4()` or `z.ipv6()`. While not a complete omission, it's a minor gap that could confuse developers needing to validate specific IP versions.

Document the `version` parameter for `z.ipv4()` and `z.ipv6()` (e.g., `z.ipv4({ version: 4 })`).

export function _nativeEnum<T extends util.EnumLike>(Class: util.SchemaClass<schemas.$ZodEnum>, entries: T, params?: string | $ZodEnumParams): schemas.$ZodEnum<T>

Use `z.enum()` for externally declared TypeScript enums. The `z.nativeEnum()` API is deprecated.

The docs say `z.nativeEnum()` is deprecated but do not show any examples of `z.nativeEnum()` being used, which is fine. The code still exports it, so it's not a contradiction. However, the docs could clarify that `z.nativeEnum()` is removed in Zod 4, but it's still present, so it's a minor mismatch.

If `z.nativeEnum()` is removed, state that it is no longer available.

export function _stringFormat<Format extends string>(...)

z.base64(); z.base64url(); z.hex();

The docs list `z.hex()` but there is no dedicated section, and it's not clear that it's a new format. The code exposes `_hex` via the string format system, so it's valid. But the docs don't show it in the main list of string formats at the top (they show `z.base64()` and `z.base64url()` but not `z.hex()`). Actually the docs list shows `z.hex()` in the 'String formats' section, so it is documented. This might not be a real mismatch.

Verify that `z.hex()` is documented; if so, no action needed.