as you said, "decode" and "parse" are essentially synonymous. encoding is the new thing here, and it's the inverse of parse. but in anycase, this isn't something I just came up with: see io-ts and Effect Schema.

starting with Zod 4, Zod is published to JSR but not deno.land/x

for a more detailed technical breakdown of codecs, read the associated blog post 👍 colinhacks.com/essays/intro...

including...

✅ stringToNumber
✅ stringToInt
✅ stringToBigInt
✅ numberToBigInt
✅ isoDatetimeToDate
✅ epochSecondsToDate
✅ epochMillisToDate
✅ jsonCodec
✅ utf8ToBytes
✅ bytesToUtf8
✅ base64ToBytes
✅ base64urlToBytes
✅ hexToBytes
✅ stringToURL
✅ uriComponent

instead of providing first-party APIs for commonly-needed codecs, Zod is taking a page from shadcn

fully-tested versions of 16 commonly-needed codecs are available on the new Codecs page. you're encouraged to copy/paste/customize them as needed 👍
zod.dev/codecs

Codecs is useful when mapping data between two different domains. for instance, when converting data in your Node.js backend from a rich JavaScript representation (Dates, BigInts, Maps, Sets, etc) into a JSON-serializable format (ISO datetimes, arrays, etc)

these methods are intended for use cases involving data *conversion*, not *validation* (though they do that too). so if you pass in an input of an unexpected type, you'll get a TypeScript error.

"how does .decode() differ from .parse()?"

good question! they're identical at runtime, but their type signatures differ in an important way.

unlike .parse()—which accepts `unknown` input—decode and encode expect strongly-typed inputs

It is coupled with the addition of new methods (available on all Zod schemas)

.decode() — "forward" parsing
.encode() — "reverse" parsing

sounds like you found an alternative but the answer is "not at all". MIT license, go ham :)

very nice 🤩

I'm throwing a happy hour in SF that evening to celebrate (thx @clerk.com!) — if you're any the area come hang out :) lu.ma/waqmeggb

hi Axel! big fan! the ? syntax definitely felt right...and when it unlocked recursive objects I knew it was the way.

though actually in Zod 4, z.object() adds the "?"to T.optional() but not to z.union(T, z.undefined()) as you're suggesting...a small change that makes things a little more sound

z.safeint() exists but it's just z.int() 🙃 anything outside of safe range will throw. hadn't considered doubleint seriously. is that basically z.int128()? I'd represent that with a ZodBigInt subclass (similar to z.int64() and z.uint64 currently). but idk if it's widely used enough to merit addition?

yikes, thanks! last minute changes gone awry

thank you! this means a lot and is exactly the reaction I was hoping for :))))

huge thanks to @clerk.com for supporting my work on Zod 4! they've been an amazing partner through the much-longer-than-expected development process 🫶

the beta period will last 4-6 weeks so ecosystem tooling/library authors can implement day-one support. if that's you: this page is a good starting point. don’t hesitate to reach out for guidance!
v4.zod.dev/packages/core

breakage was kept to an absolute minimum, but there are some relatively minor changes to the public API. i'd love for some brave pioneers to upgrade and report any breakage not described in the changelog:
v4.zod.dev/v4/changelog