Customizing errors
In Zod, validation errors are surfaced as instances of the z.core.$ZodError
class.
The zod/v4
package uses a subclass of this called z.ZodError
that implements some additional convenience methods.
Instances of $ZodError
contain an .issues
array. Each issue contains a human-readable message
and additional structured metadata about the issue.
Every issue contains a message
property with a human-readable error message. Error messages can be customized in a number of ways.
The error
param
Virtually every Zod API accepts an optional error message parameter.
This custom error will show up as the message
property of any validation issues that originate from this schema.
All z
functions and schema methods accept custom errors.
If you prefer, you can pass a params object with an error
parameter instead.
The error
param optionally accepts a function. This function will be called at parse time if a valiation error occurs.
Note — In Zod v3, there were separate params for message
(a string) and errorMap
(a function). These have been unified in Zod 4 as error
.
The error
function received a context object you can use to customize the error message based on the input
or other validation information.
For advanced cases, the iss
object provides additional information you can use to customize the error.
Depending on the API you are using, there may be additional properties available. Use TypeScript's autocomplete to explore the available properties.
Per-parse error customization
To customize errors on a per-parse basis, pass an error map into the parse method:
This has lower precedence than any schema-level custom messages.
The iss
object is a discriminated union of all possible issue types. Use the code
property to discriminate between them.
For a breakdown of all Zod issue codes, see the zod/v4/core
documentation.
Global error customization
To specify a global error map, use z.config()
to set Zod's customError
configuration setting:
Global error messages have lower precedence than schema-level or per-parse error messages.
The iss
object is a discriminated union of all possible issue types. Use the code
property to discriminate between them.
For a breakdown of all Zod issue codes, see the zod/v4/core
documentation.
Internationalization
To support internationalization of error message, Zod provides several built-in locales. These are exported from the zod/v4/core
package.
Note — The zod/v4
library automatically loads the en
locale automatically. The zod/v4-mini
sub-package does not load any locale; instead all error messages default to Invalid input
.
To lazily load a locale, consider dynamic imports:
For convenience, all locales are exported as z.locales
from zod/v4/locales
.
Locales
The following locales are available:
ar
— Arabicaz
— Azerbaijanibe
— Belarusianca
— Catalancs
— Czechde
— Germanen
— Englishes
— Spanishfa
— Farsifi
— Finnishfr
— FrenchfrCA
— Canadian Frenchhe
— Hebrewhu
— Hungarianid
— Indonesianit
— Italianja
— Japaneseko
— Koreanmk
— Macedonianms
— Malayno
— Norwegianota
— Türkîpl
— Polishpt
— Portugueseru
— Russiansl
— Slovenianta
— Tamilth
— Thaitr
— Türkçeua
— Ukrainianur
— Urduvi
— Tiếng ViệtzhCN
— Simplified ChinesezhTW
— Traditional Chinese
Error precedence
Below is a quick reference for determining error precedence: if multiple error customizations have been defined, which one takes priority? From highest to lowest priority:
- Schema-level error — Any error message "hard coded" into a schema definition.
- Per-parse error — A custom error map passed into the
.parse()
method.
- Global error map — A custom error map passed into
z.config()
.
- Locale error map — A custom error map passed into
z.config()
.