{"id":174,"date":"2026-05-01T05:04:12","date_gmt":"2026-05-01T05:04:12","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/valibot-vs-zod-2026-i-half-migrated-and-stopped\/"},"modified":"2026-05-01T05:04:12","modified_gmt":"2026-05-01T05:04:12","slug":"valibot-vs-zod-2026-i-half-migrated-and-stopped","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/valibot-vs-zod-2026-i-half-migrated-and-stopped\/","title":{"rendered":"Valibot vs Zod in 2026: I Half-Migrated and Stopped"},"content":{"rendered":"

Confession: I’ve been typing z.object({...})<\/code> so reflexively for the past five years that when a teammate suggested swapping to Valibot, my first reaction was a tired “why would I do that to myself.” Then I actually looked at the bundle.<\/p>\n

Our app’s client-side validation pulled in 13.4 KB of gzipped Zod just to parse three forms. That’s not a crisis, but it’s not nothing on a low-end Android phone. Valibot’s pitch is simple: same idea, tree-shakable, often a fraction of the size. The marketing pages will tell you it’s “57x smaller.” The marketing pages are lying in a normal marketing way, but the real number for a typical schema is still good enough that I took it seriously.<\/p>\n

So I migrated. Sort of. Then I stopped. This post is what I learned about both libraries, what made me switch on the client, and what kept Zod on the server. If you’re staring at the same choice, here’s the honest middle answer.<\/p>\n

Why I even looked at Valibot<\/h2>\n

The pitch comes down to bundle size. The “functional pipeable API” framing is real but it’s a taste preference, roughly as religious as tabs vs spaces. Tree-shaking is table stakes on any modern bundler.<\/p>\n

For a real comparison, I built the same schema in both libraries: a sign-up form with email, password rules, optional referral code, and a nested address. With Zod, the import cost about 13.4 KB gzipped. With Valibot’s parse<\/code>, object<\/code>, string<\/code>, email<\/code>, minLength<\/code>, optional<\/code>, and the rest of what I needed, it came out around 1.1 KB. That’s not 57x. It’s about 12x. And 12x is still very good.<\/p>\n

The catch: Valibot’s bundle wins because it’s modular by design. You import every validator individually. That feels weird at first if you’re coming from z.string().email().min(8)<\/code>.<\/p>\n

\/\/ Zod\nconst Signup = z.object({\n  email: z.string().email(),\n  password: z.string().min(8),\n});\n\n\/\/ Valibot\nimport { object, string, email, minLength, parse, pipe } from "valibot";\nconst Signup = object({\n  email: pipe(string(), email()),\n  password: pipe(string(), minLength(8)),\n});\n<\/code><\/pre>\n
The Valibot version is a few more lines. In return, your bundler can drop anything you don’t actually use. Worth it on the client. Mostly noise on the server. See Valibot’s docs<\/a> for the full API surface.<\/p>\n
The API differences that actually matter<\/h2>\n
Bundle size is the headline. Day-to-day, the API differences matter more.<\/p>\n
Zod uses method chaining. Every transform, refine, or default lives on the schema object. Valibot uses standalone functions composed via pipe<\/code>. After about a week, both feel fine. The honest difference is that pipe<\/code> plays better with TypeScript inference in some weird edge cases, particularly when you’re chaining custom validators. Zod’s chain is more discoverable in editor autocomplete because everything hangs off z.<\/code>.<\/p>\n
A real example. Validating a string that should be a UUID, lowercased:<\/p>\n
\/\/ Zod 3.x\nconst Id = z.string().uuid().transform((s) => s.toLowerCase());\n\n\/\/ Valibot\nconst Id = pipe(string(), uuid(), transform((s) => s.toLowerCase()));\n<\/code><\/pre>\n
Same length. Slightly different mental model. The difference isn’t ergonomic. It’s where the type errors point. Zod errors cluster on .uuid()<\/code> if you typo something. Valibot errors point at pipe<\/code>. After two months of writing both, I had a clear preference: Zod for code I’m reading on a screen share, Valibot for code I’m tree-shaking.<\/p>\n
For error formatting, both libraries return a structured error tree. Zod’s error.format()<\/code><\/a> is more polished out of the box. Valibot’s flatten()<\/code> is leaner but you’ll write your own formatter if your UI cares about per-field nested error paths. I wrote one in about 30 lines. It wasn’t a tax I expected.<\/p>\n
Where Zod still wins<\/h2>\n
I went in expecting “Zod wins on ecosystem” to be the headline. It is, but not for the reason I thought.<\/p>\n
The real win isn’t the number of integrations. It’s the second-order stuff. drizzle-zod<\/code> gives you schemas auto-generated from your DB tables. tRPC defaults to Zod. Hono’s validator middleware ships with Zod adapters by default. Most OpenAPI generators assume Zod. Every one of these has a Valibot equivalent in some state of completeness, and “some state of completeness” is doing a lot of work in that sentence.<\/p>\n
If you’re picking between them on a brand new project, this matters less than it sounds. If you’re inside an existing app, it matters a lot. I’ve been migrating an app from Prisma to Drizzle, and drizzle-zod<\/code> lets me skip writing schemas by hand. There’s a drizzle-valibot<\/code> package, and it works, but it lags behind on edge cases. I hit one bug with nullable JSONB columns in March that was still open the last time I checked.<\/p>\n
Server-side, this is the whole game. I have schemas being shared between database, API, and client validation. Switching one to Valibot meant either translating at the boundary or migrating everything. Neither was a good Tuesday.<\/p>\n
So the rule I landed on: client-bundled schemas go to Valibot. Server-side schemas, especially anything shared with the database, stay on Zod. Boring, but it works.<\/p>\n
I covered a related case in my post on TypeScript branded types<\/a>, where the same “runtime validation meets the type system” tension shows up.<\/p>\n
My partial migration: what I moved, what I didn’t<\/h2>\n
Concrete numbers from a small SaaS app. Before:<\/p>\n