# Zod vs Valibot in 2026: Bundle Size and Speed, Compared
For about two years the pitch for Valibot was one line long: it's the tiny one. That was enough. If you were shipping schemas to the browser, the weight difference was impossible to ignore, and plenty of teams migrated on that argument alone.
Then Zod v4 landed with a 14x string parsing speed gain and a stripped down build called Zod Mini, and the tiny one argument suddenly needed a rematch. So here are the actual numbers, where each library still wins, and which one I'd reach for on a new project today.
Why this choice costs you twice
Validation is one of the few pieces of code that gets taxed on both sides of the wire.
On the client it ships. Every user who loads your page downloads your schema library before they can type into a form, and it sits in the same budget you fight over when you're arguing about whether to lazy load a chart component.
On the server it runs hot. Every request that crosses your API boundary gets parsed. Every webhook payload, every query param, every row you pull back from an untrusted source. If your validator is slow, that slowness compounds at exactly the point where you have the least headroom.
Most library choices only hit one of those. A charting library is bundle weight and nothing else. A queue worker is runtime cost and nothing else. Schema validation is both, which is why the argument gets so loud for a dependency that most people write maybe forty lines against.
Bundle size: the three numbers that matter
Here's the comparison people keep getting wrong, because there are three builds in play and not two.
| Build | Minified + gzipped | Why |
|---|---|---|
| Valibot (core) | ~1.37 kB | Modular functions, pruned per import |
| Zod Mini | ~6.88 kB | Tree shakeable subpackage added in v4 |
| Zod Standard | ~17.7 kB | Full chainable API, one large surface |
Zod Standard is heavy for a reason that isn't sloppiness. The chainable API means z.string() returns an object carrying every refinement method you might call next, so your bundler can't confidently prove that .datetime() is dead code when you never touch it. One big connected surface prunes badly.
Valibot goes the other way. Everything is a standalone function you import by name, so the bundler does what bundlers are good at: it drops what you never referenced. Import three validators, ship three validators.
The mistake I see constantly in 2026 is people quoting the 17.7 kB figure at Valibot. That comparison was fair in the Zod v3 era. It isn't now. If bundle size is your reason for looking at Valibot, the honest matchup is 1.37 kB against 6.88 kB, and that's a much narrower gap than the one that started the migrations.
Zod v4: what actually changed
Two things, and they happen to be the exact two complaints that pushed people out.
Speed came first. String parsing got roughly 14x faster, which is the kind of jump you notice in a load test rather than in a demo. Then Zod Mini arrived as a separate entry point built for tree shaking, which finally gave Zod an answer to the weight question instead of a shrug.
// Zod Standard: chainable, reads well, prunes badly
import { z } from "zod";
const User = z.object({
id: z.string(),
age: z.number().int().min(18),
});
const result = User.safeParse(input);
// Zod Mini: same engine, function-first entry point, tree shakeable
import * as z from "zod/mini";
const User = z.object({
id: z.string(),
age: z.number(),
});
const result = z.safeParse(User, input);
Be honest about where the speed actually lands, though. A signup form validating one object on submit will never notice 14x. What notices is the API gateway parsing thousands of payloads a minute, or the ingestion job running a schema across a large array of rows. If validation isn't on your hot path, treat the speed number as nice rather than as a reason to migrate.
API ergonomics: where each one wins
Zod wins on familiarity, and familiarity is worth more than developers like to admit. The chained style reads like a sentence, your editor autocompletes you through it, and roughly every tutorial, every form library adapter, and every Stack Overflow answer written since 2022 assumes you're holding a Zod schema. That ecosystem gravity is the real product.
import * as v from "valibot";
const User = v.object({
email: v.pipe(v.string(), v.email()),
age: v.pipe(v.number(), v.integer(), v.minValue(18)),
});
const result = v.safeParse(User, input);
Valibot wins on honesty. That import line at the top is a literal bill of materials for what you're about to ship, and after a week the pipe style stops feeling like ceremony and starts feeling like composition. You can pull a validator out into a named constant and reuse it across schemas without wrapping anything.
It has a real learning curve, though, and I'd rather say that plainly than pretend otherwise. Everyone arriving from Zod finds it verbose at first, error message customisation takes a minute to locate, and if a teammate is debugging a schema at 2am they will be slower in the style they've never written. That cost is temporary but it's not zero, and on a team of eight it's eight times whatever it is.
When to pick which
| Situation | Pick | Why |
|---|---|---|
| Server only code, no client bundle | Zod Standard | Weight is irrelevant, ergonomics and ecosystem win |
| Existing Zod codebase | Zod Mini | Same engine, no rewrite, most of the size back |
| Greenfield, client heavy, tight budget | Valibot | Smallest footprint, and no migration cost to pay |
| Publishing a library | Valibot | Your kilobytes become your users' kilobytes |
| Team optimising for velocity | Zod | Ecosystem answers questions before you ask them |
The one I'd push back on hardest is migrating a large existing Zod codebase purely for kilobytes. Switching a few hundred schemas costs you review time, a window of subtle behaviour differences in error shapes, and every integration that expects a Zod schema. Moving from Zod Standard to Zod Mini gets you most of the size back for a fraction of that risk. Do the cheap thing first, measure, and only then decide whether the last few kilobytes are worth a rewrite.
FAQ
Is Valibot better than Zod?
Not universally. Valibot is smaller and prunes better, so it wins where bundle weight is the constraint. Zod wins on ecosystem, on how many libraries already speak its schemas, and on how quickly a new teammate becomes productive. Pick against your actual constraint rather than against a benchmark someone posted.
What changed in Zod v4?
String parsing got roughly 14x faster, and a new Zod Mini subpackage arrived that's built for tree shaking. Together those addressed the two reasons people were leaving: it was slow on hot paths and it was heavy in the browser. If you evaluated Zod before v4 and walked away, your evaluation is out of date.
Which TypeScript validation library has the smallest bundle?
Valibot, at roughly 1.37 kB minified and gzipped for the core package. Zod Mini sits at about 6.88 kB and Zod Standard at about 17.7 kB. Just make sure you compare against the build you'd actually ship, because quoting the Standard figure against Valibot overstates the gap by a lot.
The verdict
For most teams in 2026 the answer is Zod Mini. You keep the ecosystem, you keep the muscle memory, and you give up a handful of kilobytes to Valibot rather than the ten plus you were giving up before v4.
Reach for Valibot when you're starting fresh and the client bundle is genuinely the thing you're optimising. The old size argument still points at Valibot, it just doesn't win the whole debate by itself anymore.
If you want a deeper look at how validation fits into a production TypeScript stack, I cover it in more detail on my site.
If you want this wired up on your own site end to end, that is exactly the kind of work I take on.
Drop a comment if your setup looks different. Curious what people are actually running for schema validation in 2026, and whether anyone has migrated back.
Top comments (0)