Skip to content

Choosing a Rust Validation Library

The Rust ecosystem has three main approaches to data validation. This page compares them honestly — including where zod-rs is not the right choice — so you can pick based on where validation happens in your program.

zod-rsvalidatorgarde
ModelSchemas as runtime valuesStruct attributesStruct attributes
ValidatesRaw JSONDeserialized structsDeserialized structs
Derive macroYes (ZodSchema)Yes (Validate)Yes (Validate)
Runtime schema buildingYesNoNo
Parse + validate in one stepYesNoNo
Context-aware rulesCustom Schema implsCustom functionsBuilt-in context
Error paths in nested dataFull pathsField-levelPath-aware
TypeScript codegenZod schemasNoNo
Built-in i18nYesNoNo
Axum integrationBuilt-in featureCommunity cratesCommunity crates

If you construct structs in Rust and only need to check invariants — lengths, ranges, formats — an attribute-based validator is the simplest tool. garde is the modern choice here: it’s a rewrite of validator with better Option handling and built-in context-aware validation. validator remains fine if you’re already using it.

If validation starts at a boundary — API request bodies, webhooks, config files, message queues — zod-rs validates the JSON itself and hands you a typed struct in one step. You get one error shape for both malformed and invalid input, full paths to failing fields (user.addresses[0].zip), and schemas you can build, store, and compose at runtime.

Your validation rules must match a TypeScript frontend

Section titled “Your validation rules must match a TypeScript frontend”

Only zod-rs generates TypeScript Zod schemas from Rust types, so a Rust backend and a TypeScript frontend can enforce identical rules from one definition. If you’re validating the same payloads on both sides today, this is the differentiator.

[dependencies]
zod-rs = "1.1"

The getting started guide covers installation and a first schema in a few minutes, and there are step-by-step migration guides from validator and garde.