DEV Community: WhizTools.app

Replacing ffmpeg.wasm with WebCodecs: a 1080p export from 10.3s to 2.6s

WhizTools.app — Sat, 10 Oct 2026 05:28:32 +0000

I maintain a browser-based video editor. Everything runs client-side — no upload, no server — which for a long time meant ffmpeg compiled to WebAssembly doing the export.

It works. It's just slow. ffmpeg.wasm encodes around 30 frames a second at 1080p, so a ten-second clip takes about ten seconds of watching a progress bar. Not because ffmpeg is slow — because it's a copy of an encoder running in a sandbox, without access to anything the platform already has.

The browser does have a real encoder. VideoEncoder is the same one it uses for WebRTC. Here's what swapping to it involved, and the three bugs that cost me most of the time.

The result first

             ffmpeg.wasm    WebCodecs
  720p  10s      7.7s         2.0s      3.9x
 1080p  10s     10.3s         2.6s      4.0x

Output is pixel-identical to the ffmpeg path — same compositing code, just fed differently.

The shape of it

Four stages, all of them streaming:

mp4box  →  EncodedVideoChunk  →  VideoDecoder  →  VideoFrame
                                                     ↓
                                          composite offscreen
                                                     ↓
                                   VideoEncoder  →  mux

Demuxing. VideoDecoder wants encoded chunks, and a browser won't give you those from a <video> element. mp4box.js parses the container and hands you samples. The part that isn't obvious: the decoder also needs the codec-private data, and that doesn't live in the samples — it's in the sample description box.

function describe(mp4, track) {
  const trak = mp4.getTrackById(track.id);
  for (const entry of trak.mdia.minf.stbl.stsd.entries) {
    const box = entry.avcC || entry.hvcC || entry.av1C || entry.vpcC;
    if (!box) continue;
    const stream = new DataStream(undefined, 0, DataStream.BIG_ENDIAN);
    box.write(stream);
    // first eight bytes are the box header, which the decoder does not want
    return new Uint8Array(stream.buffer, 8);
  }
}

Miss that , 8 and the decoder rejects the config with a message that tells you nothing.

Compositing. I didn't write a second renderer. The editor's preview already draws every clip, title, transition and colour adjustment to a canvas. For export I run that same code offscreen at output resolution, with its frame source swapped from <video> elements to decoded VideoFrames. Which means the export looks like the preview by construction, rather than by me keeping two renderers in sync for ever.

Bug 1: the decoder stops if you hold its output

VideoDecoder applies back-pressure. If you don't close the VideoFrames it gives you, it stops producing. My first feeder queued decoded frames generously — eight in flight, plenty buffered — and the export hung about four seconds in, every time.

The decoder was waiting for me to release frames. I was waiting for the decoder to produce one more. Neither moved.

while (this.at < this.chunks.length
       && this.decoder.decodeQueueSize < 4
       && this.queue.length < 3) {
  this.decoder.decode(this.chunks[this.at++]);
}

Shallow queues. Counter-intuitive if you're used to buffering being free.

Bug 2: setTimeout(0) is not zero

The frame loop yields to let the decoder run. I used setTimeout(0), as you do.

Browsers clamp nested timers. In a real page that yield costs about 7 ms. Over an export that yields tens of thousands of times, that was most of the runtime I'd supposedly saved.

function yieldToTasks() {
  return new Promise((resolve) => {
    const channel = new MessageChannel();
    channel.port1.onmessage = () => resolve();
    channel.port2.postMessage(0);
  });
}

0.04 ms, and not clamped. Same semantics, 175x cheaper.

Bug 3: one character

The loop asks "does the frame I'm holding cover the moment I need?" I wrote:

if (frame.timestamp + frame.duration > want) break;

A frame at 66,666 µs lasting 33,333 µs covers exactly up to 99,999 — which is precisely the moment the next output frame asks for. With a strict >, it could neither advance nor finish. It waited for ever, on some files and not others, depending on where their timestamps started.

>=. One character, an afternoon.

What actually found it was giving up on guessing and making the timeout print its own state:

throw new Error('The decoder stopped producing frames. '
  + `[want=${want} frame=${this.frame?.timestamp} queue=${this.queue.length} `
  + `at=${this.at}/${this.chunks.length} inflight=${this.decoder.decodeQueueSize}]`);

The numbers made it obvious in seconds. I should have done it first.

What it still can't do

No hardware encoder. VideoEncoder doesn't reach your GPU's dedicated encoder, so desktop ffmpeg is still faster.
Container support is the browser's. ProRes, some MKVs, HEVC in some browsers — those fall back to the ffmpeg path, which is why I kept it.
Memory is the tab's. No server to offload to. That's the trade you make for not uploading anything.

Worth it?

For a browser-only editor, yes — four times faster on the operation users actually wait for. And the fallback matters: WebCodecs where it works, ffmpeg.wasm where it doesn't, decided per file.

If you're doing something similar: shallow queues, MessageChannel not setTimeout, and make your timeouts print their own state before you start guessing.

The editor is at whiztools.app/video-editor if you want to throw a file at it.

Building an AI Image Upscaler That Runs Entirely in the Browser (No Server Required)

WhizTools.app — Wed, 22 Jul 2026 13:55:20 +0000

AI image upscalers are everywhere these days.

Most of them work the same way:

Upload your image.
Wait while it's processed on a remote server.
Download the result.

It works—but it also means you're sending your photos, screenshots, or documents to someone else's infrastructure.

I wanted to see if I could build an alternative that keeps everything on the user's device.

The result is a fully browser-based AI Image Upscaler.

No uploads.

No server processing.

No account required.

Why Build It This Way?

I've been building a collection of browser-based utilities over the past few months, and one of the most requested features from the community was image upscaling.

The obvious solution would have been to process images on a backend.

Instead, I challenged myself to keep the entire pipeline inside the browser.

That meant users could enhance images without them ever leaving their device.

Besides privacy, this has a few practical benefits:

🔒 Your images stay on your computer.
⚡ No waiting for uploads before processing begins.
🚫 No account or sign-up required.
🌐 Works even with a slow or unstable connection once the application is loaded.

The Challenges

Building an AI-powered feature entirely in the browser wasn't as straightforward as I expected.

Loading AI Models

AI models aren't small.

Loading them efficiently without making users wait forever was one of the biggest challenges.

The first experience matters, so I spent time reducing unnecessary loading and making the application feel responsive.

Memory Usage

Upscaling large images can quickly consume a lot of memory.

Modern browsers are powerful, but they're still running inside a constrained environment.

Finding the right balance between image quality, speed, and memory usage took quite a bit of experimentation.

Keeping the UI Responsive

Nobody likes a frozen browser tab.

Long-running image processing needs to happen without making the interface feel sluggish.

Keeping the application responsive while processing large images was an important part of the implementation.

Mobile Performance

Desktop computers generally have enough resources for image processing.

Mobile devices are a different story.

Different hardware, limited memory, and thermal constraints meant I had to test across multiple devices to make sure the experience remained usable.

Browser Technology Has Come a Long Way

One thing this project reinforced is how capable modern browsers have become.

A few years ago, I would have assumed this kind of feature required cloud infrastructure.

Today, browsers can handle surprisingly complex workloads while still delivering a good user experience.

It opens up interesting possibilities for building applications that are both privacy-friendly and performant.

What I Learned

This project reminded me that not every feature needs a backend.

Sometimes the browser is more than capable of doing the heavy lifting.

Choosing client-side processing whenever it makes sense can improve:

User privacy
Perceived performance
Simplicity
User trust

Of course, browser-based AI isn't the answer for every use case, but for many everyday utilities it's a compelling approach.

I'd Love Your Feedback

I'm continuing to improve the image quality and performance based on real-world usage.

If you've built AI features that run entirely in the browser, I'd love to hear about your experience.

And if you're interested in trying it yourself, you can check it out here:

👉 https://whiztools.app/upscale-image

I'm especially interested in feedback on:

Image quality
Processing speed
Large image support
Mobile experience
Browser compatibility

Thanks for reading! If you have suggestions or ideas for improving browser-based AI tools, I'd love to discuss them in the comments.

I Stopped Uploading My Files to Random Websites. So I Built My Own Solution.

WhizTools.app — Tue, 21 Jul 2026 11:11:34 +0000

How many times have you done something like this?

Merge a PDF
Compress an image
Convert a PNG to JPG
Format a JSON file
Generate a QR code

You search Google, click the first result, upload your file, wait a few seconds, download the output, and hope the website actually deletes your data.

For years, I never questioned this workflow.

Then one day I asked myself:

Why am I uploading local files for tasks that my browser should already be capable of doing?

That single question turned into a side project that eventually grew into 100+ browser-based tools.

The Browser Has Quietly Become Incredibly Powerful

Modern browsers can do far more than most developers realize.

Today, they can:

Process images
Manipulate PDFs
Generate QR codes
Read barcodes
Perform OCR
Format JSON
Compress files
Work with the Clipboard API
Access local files securely
Store data offline

Yet thousands of websites still upload everything to a backend.

Sometimes that's necessary.

But many times... it isn't.

The "Upload Everything" Habit

I understand why many online tools work this way.

Server-side processing is easier.

You have full control over the environment.

Libraries are mature.

Performance is predictable.

But there's a trade-off.

Every upload means your users have to trust your infrastructure with their personal files.

Whether it's:

Tax documents
Contracts
Family photos
Screenshots
IDs
Business documents

many people would rather those files never leave their own computer.

Privacy Shouldn't Be a Premium Feature

One thing surprised me after launching.

Almost nobody commented on the number of tools.

Instead, people kept saying things like:

"Finally, something that doesn't require an account."

"I love that everything runs locally."

"Instant bookmark."

That made me realize something important.

People don't just want convenience.

They also want control.

Sometimes the best feature isn't AI.

It's not uploading the file at all.

It Wasn't Easy

Building everything inside the browser introduced challenges I hadn't expected.

Large files can easily consume memory.

Different browsers behave differently.

OCR running locally is much harder than using a cloud API.

Mobile devices have much stricter resource limits.

Every feature became a balancing act between:

Performance
Memory usage
Browser compatibility
User experience

Why I Kept Going

Because every time I removed one unnecessary upload...

the experience became simpler.

Open the page.

Choose a file.

Process it.

Download the result.

Done.

No account.

No waiting for uploads.

No unnecessary permissions.

The Result

That idea slowly grew into a collection of 100+ browser-based tools covering:

PDF utilities
Image tools
OCR
QR & Barcode generators
Text utilities
Developer tools
Color tools
Security & encoding tools
Calculators
Productivity tools

Most of them process everything locally inside the browser, and many continue to work offline after the initial page load.

What I Learned

As developers, we often chase bigger features.

Bigger infrastructure.

More APIs.

More backend services.

Sometimes the better product comes from removing complexity instead.

Modern browsers are capable of much more than we give them credit for.

Maybe it's time we started using that power.

If you're interested in browser-first utilities, you can check out what I've been building:

👉 https://whiztools.app

I'd also love to hear your thoughts:

What everyday tool do you wish could run entirely in the browser?