I Added AVIF Export to My Browser Image Editor in Under 10 Minutes With Codex

The part that impressed me was not that Codex wrote some code. It was that it took a real browser feature gap, found the right open source path around it, and shipped a working fix in less than 10 minutes.

One of the little web tools I have been building with Codex is Image Editor, a simple browser-based editor in my web-tools project.

It does exactly the sort of things I want from a lightweight utility: drop in an image, zoom, rotate, crop, resize, and export it back out without bouncing through a desktop app.

Recently I wanted to add AVIF export.

That sounded like the kind of feature that should be boring. Take the edited image, export it as AVIF, done.

Except the web platform is still a little awkward here.

Browsers are very good at displaying AVIF now, but exporting AVIF is a different story. The canvas APIs do not guarantee support for every output format. MDN is pretty explicit about the baseline: browsers must support PNG export, and many also support JPEG and WebP, but other formats depend on the user agent. So if I wanted an AVIF export button that actually worked, canvas.toBlob(..., "image/avif") was not a real plan.

That led to the obvious next question: what if I just did the encoding myself in a WASM web worker?

I handed that problem to Codex. It did the research, landed on @jsquash/avif, integrated it into the app, and wired it up cleanly. On the first pass, everything worked.

The hard part was not AVIF. It was the last mile around the browser

This is one of my favorite kinds of engineering problems because it looks like a codec problem, but it is really a packaging problem.

The missing piece was not "invent AVIF." The missing piece was "how do I make AVIF export reliably available inside a browser app when the native platform does not give me a clean cross-browser button for it?"

WASM is such a good answer to that class of problem.

Codex found a real implementation path, not just a demo

The specific choice here was @jsquash/avif, which turned out to be exactly the kind of open source project I was hoping existed.

And the integration path was pleasantly practical.

Codex added the package, synced the runtime files into public/vendor/jsquash-avif, and set up a dedicated /workers/image-editor-avif-worker.mjs worker for the actual encoding. The main UI grabs the canvas pixel data, transfers the raw buffer to the worker, and gets encoded AVIF bytes back. If the browser is cross-origin isolated and supports WASM threads, the worker uses the multithreaded encoder. If not, it falls back to the single-threaded path.

That is exactly the kind of detail work that usually burns the time.

Not the big idea. The little decisions. Which package is mature enough? How do the runtime files get shipped? What belongs on the main thread versus the worker? How do you make the fallback behavior sane instead of fragile?

That is where Codex felt unusually strong here.

It did not just autocomplete some syntax. It narrowed the search space, found a plausible open source answer, integrated it into the project, and got the whole thing across the line quickly. That is the part that felt impressive to me.

Not "AI invented a new codec," but "AI removed most of the yak shaving between idea and shipped feature."

That distinction matters.

Cheap experiments change the backlog

The biggest thing this changed for me is not that Image Editor now exports AVIF. That is useful, and I wanted it, but the more interesting part is what it says about the cost of trying things.

If a feature like this takes half a day, or a full day, or one of those fuzzy "I'll have to really sit down with it" blocks, it tends to stay on the list.

If it takes less than 10 minutes from idea to working implementation, it stops feeling like a project and starts feeling like a reasonable thing to just do.

That is a real shift.

A lot of side projects die in the gap between "this would be nice" and "I do not want to burn an afternoon fighting browser APIs and build tooling." Coding agents are getting very good at collapsing exactly that gap.

Not every task goes this smoothly. A lot of them do not. But when the problem is well-bounded, the docs exist, and open source has already solved the hardest part, the speed can feel almost unfair.

This is the version of AI coding I find most convincing

I like big ambitious demos as much as anyone, but this is the category that keeps making me pay attention: weird little real-world product improvements that are too annoying to prioritize until they suddenly are not.

Adding AVIF export to Image Editor is not a moonshot. It is not a benchmark. It is not a toy one-liner either. It sits right in the middle: specific, useful, slightly messy, and just technical enough that it used to come with a bunch of friction.

That is exactly the kind of work where Codex has been most valuable for me.

It is good at turning "I wonder if this is possible" into "yes, and the feature is live now."

That is a big deal.

If you are building web tools, I think this is one of the most important workflow changes to watch. The bottleneck is shifting. More and more often, the limiting factor is not implementation time. It is whether you thought to ask the question.

For this one, I did. Codex handled the rest.