DEV Community: Max/Wang

My browser video compressor choked on a 2.2 GB AVI. Here's why

Max/Wang — Mon, 05 Oct 2026 02:52:52 +0000

I run SquishyFile, a video compressor that works entirely in the browser. Most files go through WebCodecs with Mediabunny. Files the browser can't decode natively, like AVI, MPG, MTS and FLV, fall back to ffmpeg.wasm. The same fallback kicks in when a browser has no working H.264 encoder.

Last week a user sent me a bug report. A 2.24 GB .avi failed in Chromium with my generic "Something went wrong" message, before encoding even started. They had already traced it to one line in my code, and they were right.

The line

await ffmpeg.writeFile(inName, new Uint8Array(await file.arrayBuffer()));

Almost every ffmpeg.wasm example I found online uses this pattern, and I copied it without thinking. It does two expensive things:

file.arrayBuffer() reads the entire file into one JavaScript buffer. In Chromium that read fails at just under 2 GiB with NotReadableError.
writeFile then copies those bytes into MEMFS, ffmpeg's in-memory filesystem. MEMFS lives on the wasm heap, and a 32-bit wasm module can't address more than 4 GB in total. The input, the output and the codec buffers all fight for that space.

So even if step 1 passed, step 2 would hit a wall soon after. My probe step, which runs ffmpeg -i to read duration and resolution, used the same line. That's why the error showed up before any encoding.

I had the same code in two other tools on the site, MP4 to audio and video to MP3. Same bug, nobody had reported it there yet.

WORKERFS

Emscripten ships a filesystem called WORKERFS. Instead of copying a File into memory, it mounts the File object and reads slices from it on demand with FileReaderSync inside the worker. ffmpeg sees a normal path and seeks around in it as usual. @ffmpeg/ffmpeg 0.12 exposes it through ffmpeg.mount().

Before switching, I checked that the core build I load (@ffmpeg/core 0.12.10) actually includes WORKERFS. Emscripten only bundles it when the build asks for it, so a quick grep through ffmpeg-core.js is worth doing. Mine had it.

I wrote a small helper and pointed all six call sites at it:

import type { FFmpeg, FFFSType } from '@ffmpeg/ffmpeg';

let seq = 0;

export async function mountInput(ffmpeg: FFmpeg, file: File, baseName: string) {
  const ext = file.name.split('.').pop()?.toLowerCase().replace(/[^a-z0-9]/g, '') || 'bin';
  const name = `${baseName}.${ext}`;
  const dir = `/in${++seq}`;

  // Wrapping a File in a new File doesn't read it. It only renames it.
  const renamed = new File([file], name, { type: file.type });

  await ffmpeg.createDir(dir);
  await ffmpeg.mount('WORKERFS' as unknown as FFFSType, { files: [renamed] }, dir);

  return {
    path: `${dir}/${name}`,
    release: async () => {
      await ffmpeg.unmount(dir).catch(() => {});
      await ffmpeg.deleteDir(dir).catch(() => {});
    }
  };
}

Then each call site looks like this:

const input = await mountInput(ffmpeg, file, 'input');
try {
  await ffmpeg.exec(['-i', input.path, ...args, 'output.mp4']);
} finally {
  await input.release();
}

A few details I chose on purpose:

I rename the file. WORKERFS uses file.name as the filename inside the mount. User filenames have spaces, emoji and odd characters that make ffmpeg arguments annoying. new File([file], name) creates a new reference to the same data, so it costs nothing.
Each mount gets its own directory. The probe and the encode share one ffmpeg instance. A counter avoids a clash if a mount from a cancelled run never got cleaned up.
I pass the string instead of importing the enum. FFFSType is a runtime enum. I load @ffmpeg/ffmpeg lazily with a dynamic import, and importing the enum at the top of the file would pull the package into the main bundle. A type-only import plus the string value keeps it lazy.

What it doesn't fix

The output still goes into MEMFS, because ffmpeg has to write it somewhere. For a compressor that's fine, since the output is usually a fraction of the input. A tool that makes files bigger would still hit the ceiling.

It also doesn't make anything faster. I use the single-threaded core so I don't need COOP/COEP headers, and a 2 GB AVI on one thread takes a while. I'll take a slow encode that finishes over a fast "Something went wrong".

What I'd tell anyone using ffmpeg.wasm

Search your code for arrayBuffer() next to writeFile. That pattern works in every test you run with a 50 MB sample and breaks the first time a real user drops in a long recording. Mount the File instead.

Thanks to the person who sent such a precise bug report. If you want to try it, the compressor is at SquishyFile.

I’ve been building a tool site for a little over a month, so I figured I’d share where it’s at.

Max/Wang — Sun, 04 Oct 2026 14:31:58 +0000

I’ve been building SquishyFile for a little over a month, so I figured I’d share where it’s at.

I’ve seen quite a few tool sites doing surprisingly well with ads, and I came across a bunch of those cases on X. That got me thinking: why not build one myself and see where it goes, haha.

So I started building a bunch of video tools and put them all into one site.

Right now there are tools for things like compressing videos, converting formats, video to text, upscaling, extracting audio and frames, GIFs, filters, and a bunch of smaller stuff.

I’ve been building it with a lot of help from Claude, and after a little over a month it’s doing around 100 users/day.

The traffic is still pretty interesting though.

Google isn't really sending much traffic yet, which I honestly expected to be the opposite.

Bing is actually sending more traffic than Google right now, and a decent chunk is coming from social, mostly Threads.

So I'm basically still figuring out where the traffic is going to come from.

Some tools get impressions, some get almost nothing. Some keywords look like they should have traffic but don't. And Google seems to be taking its sweet time.

The most fun part so far has actually been getting emails from users.

A few people have emailed me because they ran into bugs, which is already really useful because I obviously can't test every possible video and browser combination myself.

But some people have also emailed me just to suggest things they'd like to see added.

That was honestly pretty cool.

When you're building a site by yourself, you spend a lot of time staring at Analytics and Search Console, so getting an actual email from someone saying “hey, it'd be great if you added this” feels much more encouraging than another 20 users showing up in Analytics.

For now I'm just going to keep adding tools, trying different ways to get traffic, and seeing what happens.

Eventually I'd like to monetize it with ads. That's kind of the whole experiment for me — I've seen other tool sites make it work, so I want to see if I can make one work too.

No idea how far it'll go yet, but it's been pretty fun so far.

I'll post another update when something interesting happens.

I put gifsicle in the browser to build a GIF compressor

Max/Wang — Sun, 04 Oct 2026 13:06:13 +0000

I run SquishyFile, a small site of free video tools, and I recently added a GIF compressor to it. It runs gifsicle, Eddie Kohler's GIF optimizer, compiled to WebAssembly inside a Web Worker. You drop in a GIF, pick a target size or a few settings, and get a smaller GIF back. All of the work happens on your own device, so there's no upload and no queue.

This post covers how I picked the defaults, two bugs I hit when dropping frames, and how the tool hits a size like 256 KB when gifsicle has no flag for that.

Why gifsicle

GIF compression is an old problem, and gifsicle has handled it well for a very long time. The part I cared about most is its lossy mode. GIF uses LZW, which loves long runs of identical pixels and hates noise. Lossy mode lets the encoder swap a pixel for a close neighbor color when that creates a longer run. On camera footage you see a bit of grain. On the file size you see a big drop.

I used the gifsicle-wasm-browser package. It ships its worker as a source string with the .wasm inlined as base64, so nothing loads from a CDN at run time. The module weighs about 340 KB, and most people who open the page never press Compress, so I only import it on the first click.

Before I picked defaults I ran some tests. On a 36 MB GIF (800px wide, 120 frames), -O3 gave me the same size as -O2 and took about three times longer. So every level uses -O2, and only the lossy value changes: 30 for Light, 80 for Balanced, 140 for Strong. Balanced took that 36 MB file down to about 17 MB in roughly 5 seconds.

What each setting buys you

The tool has four knobs: compression level, colors, max width and frames. I ran them on a 3-second, 480×270 sample with 36 frames that starts at 4.0 MB:

Settings	Result	Saved
Light	2.5 MB	38%
Balanced	1.9 MB	53%
Strong	1.6 MB	59%
Balanced + 64 colors	1.5 MB	63%
Balanced + 360px wide	1.1 MB	74%
Strong + 64 colors + 360px + every 2nd frame	343 KB	92%
Balanced + 64 colors + 240px + every 2nd frame	206 KB	95%

Compression alone got this GIF to about half its size. To get it really small I had to cut width and frames too. Width saves the most because halving it leaves a quarter of the pixels, but it's also the change people notice first.

Dropping frames broke two things

Keeping every 2nd or 3rd frame sounds simple. My first version just picked frames 0, 2, 4 and so on, and it went wrong in two ways.

The GIF played at double speed. Each GIF frame carries its own delay. Throw away half the frames and keep the delays as they are, and a 3-second loop finishes in 1.5 seconds. It looked like fast-forward. Now each kept frame takes over the delays of the frames I drop after it:

export function keptFrames(delaysCs: number[], step: number) {
  const kept = [];
  for (let i = 0; i < delaysCs.length; i += step) {
    let delay = 0;
    for (let j = i; j < Math.min(i + step, delaysCs.length); j++) delay += delaysCs[j];
    kept.push({ index: i, delayCs: delay });
  }
  return kept;
}

Frames came out half drawn. Optimized GIFs, including plenty you'll find online, store most frames as a patch over the previous frame. When I picked frame 2 and skipped frame 1, frame 2 got painted over a frame that wasn't there anymore, and I got smeared, broken images. So frame dropping now runs in two passes. The first pass runs gifsicle with -U to turn every frame back into a full image. The second pass picks the frames, compresses them and optimizes again.

One more gifsicle detail bit me here. A -d delay flag applies to every frame after it until the next -d. So as soon as any kept frame has a delay, I write an explicit -d in front of every kept frame, even when the value is 0.

The unoptimize pass also prints "GIF too complex to unoptimize" on almost every run, even when the output is fine. I compared the results frame by frame against the source to make sure, then filtered that line out of the console so it doesn't scare anyone who opens DevTools. Real failures still show up, because they produce no output file and the promise rejects.

Hitting a size target

Most people compress a GIF because something rejected it. A Discord emoji slot wants 256 KB, a chat app or forum has its own cap. So the tool has a "Fit under a size" mode with presets from 256 KB to 10 MB, plus a custom value.

gifsicle can't aim at a byte budget, so the tool searches. It walks a ladder from gentle to harsh and stops at the first result that fits:

Light, Balanced, Strong
Every 2nd frame
128 colors, then 64
Width, last

Every step is a full gifsicle run, so I didn't want to run all of them every time. I measured how much each step usually shrinks a file compared to the step before it. Balanced comes out around 0.76 of Light, Strong around 0.86 of Balanced, and dropping half the frames around 0.55. The tool uses those factors to estimate the next result and skips steps that will clearly still be too big.

For width I stopped stepping down blindly. GIF size roughly follows pixel count, so the tool solves for the width it needs:

const next = Math.floor(width * Math.sqrt(budget / measured) * 0.97);

If that lands far under the budget, it spends one more pass on a wider version, so you don't get a GIF smaller than it had to be. It also aims at 98% of the target, because sites don't always count bytes the same way. Most fits finish in 2 to 5 passes.

Smaller things

Reading the GIF. I wrote a tiny parser that walks the GIF block structure to get width, height, frame count and each frame's delay. It never decodes pixels, so even a 50 MB GIF reads instantly.
Cancel. The package's own run() helper owns its worker and you can't stop it. I start a worker from the same source myself, so the Cancel button can call terminate().
Progress. gifsicle reports nothing while it works, so the progress bar runs on a time estimate. I measured about 7 MB of GIF per second and let the bar park at 95% until the worker answers.
Bigger output. On some already tight GIFs the result comes out larger. In that case the tool tells you so and doesn't offer the bigger file as a download.

Try it

The tool lives at squishyfile.com/compress-gif. If you have a GIF that comes out weird or barely shrinks, send it my way. Those are the ones I learn the most from.

How I Made a Simple Browser-Based Video Compressor for Discord

Max/Wang — Sun, 27 Sep 2026 14:14:47 +0000

I kept running into the same stupid problem: a video is just a few MB too large to upload.

Especially with Discord.

So I made a small browser-based video compressor that lets you shrink videos to a specific target size — 8MB, 10MB, 20MB, 25MB, 50MB, etc.

It runs locally in the browser using WebAssembly, so the video doesn't need to be uploaded to a server.

Useful when you need to:

compress a video for Discord
make an MP4 smaller
get a video under a specific file size
reduce video size before uploading

I built it mainly because I got tired of opening a full video editor just to make a 30MB clip fit under a file-size limit.

If you need something like this, it's here:

https://squishyfile.com/

Would be interested to hear what file-size limits people run into most often.

Upscaling anime in the browser: why I stopped trusting the AI model alone

Max/Wang — Sat, 26 Sep 2026 09:30:48 +0000

I run a free video upscaler that works entirely in the browser: no upload, the video never leaves your machine. For sources up to 720p it runs a small super-resolution model (IMDN_RTE, about 100k parameters) through onnxruntime-web on WebGPU. Above 720p it switches to AMD's FSR 1.0 shaders, because at that point speed matters more than squeezing out a few extra pixels.

It worked fine on phone footage. Then I fed it anime, and it looked bad.

The problem: the model learned from photos

IMDN_RTE learned on DIV2K, a set of photographs. Photos have soft gradients, texture, noise. Anime has none of that: it's flat colour fills separated by dark, hard ink lines. So when the model enlarges a cel-shaded frame, it does what it learned to do on photos. It keeps the edges smooth. The lines come out a little blurry and a little grey, and the whole frame looks like a slightly out-of-focus scan.

My first instinct was the obvious one: throw a sharpening filter on top. That made it worse. A normal unsharp mask overshoots on both sides of an edge, so every black line gets a thin white glow next to it. On live action you barely notice. On anime, with its perfectly flat fills, those halos jump out immediately.

So I wrote a dedicated "anime mode" pass that runs on the GPU right after the upscale. It only touches luma (brightness) and leaves the colour channels alone, so it can't create colour fringes. It does three things.

Step 1: sharpen, but never overshoot

I still use an unsharp mask, but I clamp the result to the darkest and brightest luma values already present in the pixel's own small neighbourhood:

let Ls = clamp(L + u.sharpen * (L - blurred), localMin, localMax);

That one clamp is the whole trick. The edge gets steeper, but a pixel can never become brighter or darker than something that's already next to it. No overshoot means no halo.

Step 2: darken the lines, not the edges

Anime lines should be dark. But "darken edges" is the wrong rule, because not every edge is a line. A white shirt against a blue wall is an edge between two flat regions, and if I darken it, I get a fake outline around everything.

I tried a Difference-of-Gaussians darken first (the approach Anime4K uses). It did exactly that: every colour boundary got a dark rim, and the result looked like a cheap cartoon filter.

What works better is a morphological black top-hat: take a grayscale closing of the image (max filter, then min filter) and subtract the original. The closing erases any dark stroke thinner than the window, so closing(L) - L is positive only on thin dark lines. A boundary between two wide regions survives the closing, so it gets zero response. I add that response back as extra darkness, and only real ink lines get darker.

Step 3: thin the lines

Upscaled lines also come out too thick. For this I borrowed Anime4K's "thin lines" idea: compute the Sobel gradient, blur it into a smooth "edge field", then for each pixel sample the image a tiny step down that field's slope, away from the centre of the line. Lines shrink a bit, the transitions between flat regions get steeper, and flat areas don't move at all because the field is zero there.

The details that made it actually work

Everything scales with the upscale factor. A line that's 2 px wide in the source is 8 px wide after a 4x upscale. So every blur radius, the top-hat window and the warp distance multiply by k = scale / 2. With fixed radii, the pass looked great at 2x and did nothing at 4x.

Separable passes. The Gaussian blurs and the min/max filters for the top-hat all split into a horizontal pass and a vertical pass. The whole thing ends up as 9 compute passes plus a final warp, ping-ponging between two rgba16float textures.

Bands instead of full frames. A 720p video at 4x becomes 5120×2880. Two full-size half-float textures at that resolution cost about 236 MB, which is a great way to crash a laptop GPU. So I process the frame in horizontal bands of roughly 4 megapixels, with extra rows above and below each band. That halo equals the sum of every vertical kernel radius in the chain, so each band's output matches a full-frame run exactly, and the seams stay invisible.

A reference before shaders. I wrote the whole chain in numpy first, tuned it on real anime frames, and only then ported it to WGSL. The GPU output matches the numpy reference to f16 precision. Debugging a 10-pass shader chain by staring at video is miserable; diffing against a known-good array is not.

On the FSR path, it replaces a pass. FSR normally runs EASU (the upscale) then RCAS (its own sharpener). In anime mode I drop RCAS and run my pass instead, since mine already sharpens without halos, and sharpening twice just brings the halos back.

Things I'd tell you if you're trying this

Don't reach for a bigger model first. The fix here wasn't more AI, it was about 350 lines of plain image processing that knows what anime looks like.
Work in luma only whenever you can. You avoid a whole class of colour bugs for free.
Clamp every sharpening step to its local range. It's one line and it kills halos.
Test at every scale factor. Anything with a radius in it needs to scale with the output.

If you want to see it on your own clips, the tool is here: squishyfile.com/video-upscaler. Tick "Anime / cartoon" before you hit start. It needs a browser with WebGPU (recent Chrome or Edge works); without WebGPU the upscale still runs, just on the CPU and without the anime pass.

I'm happy to go deeper on any of the passes in the comments.

8mb.video Alternative: Skip the Line, Skip the Upsell

Max/Wang — Wed, 23 Sep 2026 03:47:24 +0000

I compressed a video on 8mb.video to see what "free" means there. Position 64 in line, and a paywall behind the one feature that would have solved my problem.

Why 8MB specifically

Almost nobody wakes up wanting an 8MB video for its own sake. They want to send a clip somewhere that caps uploads at 8MB — usually Discord without Nitro, sometimes an old forum or a slow upload form — and their phone just handed them a 40MB file. "8MB video compressor" is a size problem with a deadline, not a hobby, which is exactly the moment a queue is the worst possible answer.

What "free" gets you on 8mb.video

I opened 8mb.video to compress a video to 8MB — the same job my own 8MB compressor does. Instead of a progress bar, I got this:

Waiting in Line

You are position 64 in line. There are hundreds of people using the service right now, hold on a second and we'll be with you soon.

HOLD MUSIC: clink clank clinkity clop

💖 A labor of love by a cool girl. Upgrade for a few dollars and skip the line immediately while funding continued improvements.

I checked twice while writing this, a few minutes apart, from a normal residential connection with nothing unusual going on. Both times: a queue, a position number, and the same offer to pay to skip it. That's not a bad day for their servers — it's the free tier working as designed. Every video someone uploads has to run through 8mb.video's own hardware, one at a time per worker, so when enough people show up at once, someone waits. The wait is also part of the pitch: it's what makes "upgrade for a few dollars" worth clicking rather than closing the tab.

The custom size field is a paywall, not a feature

8mb.video's presets are 8MB, 10MB, 20MB, 25MB, 50MB and 100MB. Below the presets there's a "Custom" field that looks like it takes any number up to 200MB — which would matter if you needed a 15MB file for a form with an odd limit, or a 35MB file because that's what someone specifically asked for. Type a number in and try to run it, though, and what comes back isn't a compressed video — it's a subscription prompt. The field shows you what you're missing rather than giving it to you.

So a free account on 8mb.video really does mean six sizes and no others. Anyone who needs a seventh number is the customer the upgrade prompt is built for, not an edge case the site forgot to handle.

Why a browser-based compressor doesn't have either problem

SquishyFile compresses video with WebAssembly running in your own browser tab. There's no upload step, because there's no server on the other end doing the work — your device does it, the same way it would if you'd installed FFmpeg locally instead of using a website at all.

That has one direct consequence for each problem above. There's no queue because there's nothing to queue: my video doesn't wait behind anyone else's, because it's never in a line with anyone else's — it just runs on my own CPU while I watch. A thousand people could be compressing video on SquishyFile at the same moment and none of us would notice, because none of us are sharing a server or a worker pool. There's no capacity to run out of.

And the target size box takes any number I type, not six of them. It's the same input whether I want 8MB or 37MB, free, because there's no server cost that scales with how unusual my number is — the work happens on my machine either way, so there's nothing to gate behind a subscription.

None of that is free of trade-offs. A browser tab needs to stay open and in the foreground while it works — some browsers throttle background tabs — and a large 4K source on an old laptop takes real time and real battery, because it's using that laptop's CPU rather than a server farm's. That's the one place 8mb.video's model genuinely helps: if your device is weak enough that local encoding would crawl, borrowing someone else's hardware is a real advantage, queue or not.

How I tested this

Same 42-second 1080p H.264 clip on both, targeting 8MB, over a normal home connection, no VPN, checked on two separate visits a few minutes apart. 8mb.video queued both times with a different position number; SquishyFile started encoding immediately both times, as it always does, since there's no shared server to queue behind. I'm not claiming 8mb.video is always this busy — server load moves around — but the custom-size paywall isn't load-dependent. That one's there every time, queue or no queue.

Side by side

	8mb.video (free)	SquishyFile
Where it runs	Their server	Your device
File leaves your device	Yes, uploaded	No
Size options	8/10/20/25/50/100MB presets only	Any number you type
Custom size	Paywalled	Free
Queue at busy times	Yes, with a position number	None — nothing to share
Skip the wait	Pay to skip	Nothing to skip
Good for weak/old hardware	Yes — uses their servers	Slower on very old devices

Common questions

Why do I have to wait in line on 8mb.video?

Because it compresses video on its own servers, one file at a time per available worker. When enough people use it at once, new jobs queue behind the ones already running — and the site offers to let you pay to jump the line.

Can I get a custom size for free on 8mb.video?

There's a custom size field, but entering a number and submitting it prompts a subscription upgrade rather than compressing the file. Free accounts are limited to the six preset sizes.

Is there a free video compressor with no queue and no size limit?

Yes — anything that runs in your browser instead of on a server, like SquishyFile. Since it uses your own device's processing power rather than shared server capacity, there's no line to wait in and no reason to cap which sizes are free.

Does my video leave my device with 8mb.video?

Yes. It has to — the compression happens on their servers, so the file uploads before any processing starts.

Why does Discord need an 8MB video anyway?

8MB is Discord's upload limit for accounts without Nitro. It hasn't changed in years, phone cameras keep getting bigger files, and the gap between the two is exactly what an 8MB compressor exists to close.

The honest version

8mb.video isn't broken — it's a server-based tool with a free tier shaped to nudge people toward paying, which is a completely reasonable business to run. If your device is old enough that local compression would genuinely be slow, uploading to someone else's hardware is a fair trade, queue or not. But if you just need a video under a certain size and you're not in a hurry to fund someone's server bill, running it locally skips the queue and the upsell by never having either one to skip.

I built a free tool that compresses video down to 8MB

Max/Wang — Mon, 21 Sep 2026 13:05:56 +0000

Quick share for anyone who still needs a video under 8MB — some old forums, upload forms and bots still cap at that number even though Discord doesn't anymore.

I made a small browser tool that does exactly this: drop in a video, the target's already set to 8MB, hit compress, get an MP4 that fits. It runs entirely client-side (WebAssembly), so the file never leaves your machine.

A few things I learned building it that might save you a headache:

Length matters way more than resolution. At 8MB you're roughly looking at: 20 seconds at 1080p, 30 seconds at 720p, about a minute at 540p. Past 90 seconds it still fits, just looks rough. It's pure bitrate math — 8MB is only ~67 megabits total once you subtract a safety margin.

If it's actually for Discord: they bumped the free upload limit to 20MB back in August 2026 (it's been 8 → 25 → 10 → 20 over the years). So compress to 20MB for Discord, not 8 — that's 2.5x the bitrate budget for the same clip. Only use 8MB when something explicitly states that limit.

"Under 8MB" isn't the same number everywhere. Windows counts 1MB as 1,048,576 bytes; Mac Finder counts it as 1,000,000. A file that reads 7.6MB on Windows can show as 8.0MB on a Mac. If a site keeps rejecting your file, target 7MB instead of 8 to leave no doubt.

Link: https://squishyfile.com/8mb-video-compressor

Happy to answer questions if anyone hits a weird edge case.

I built a browser tool that compresses video to 8MB. The bitrate math was the easy part.

Max/Wang — Mon, 21 Sep 2026 10:38:33 +0000

"Compress this video to 8MB" sounds like a one-liner. I thought so too. Take the target size, divide by the duration, hand the encoder a bitrate, done.

I shipped that version. Then real people started feeding it real videos, and I spent the next few weeks learning that hitting a file size and producing something watchable are two very different problems.

This post walks through how my 8MB video compressor actually decides what to do with your clip. Everything runs client-side: no upload, no server, no queue. That constraint shaped almost every decision below.

The part everyone gets right: the budget

8MB is a hard number, so the budget is pure arithmetic.

// 8 MB in bits
const targetBits = 8 * 1024 * 1024 * 8; // 67,108,864

const MUX_OVERHEAD = 0.985; // MP4 container + index
const TARGET_SAFETY = 0.94; // encoders overshoot more than they undershoot

const totalBudget = (targetBits * MUX_OVERHEAD * TARGET_SAFETY) / durationSec;

That leaves me roughly 62 megabits for the whole clip, video and audio together. A 30-second clip gets about 2 Mbps. A 2-minute clip gets about 0.5 Mbps.

I aim about 6% under on purpose. One wasted re-encode costs the user far more time than a few percent of unused budget, and "at most 8MB" is a promise. A file that lands at 8.1MB is a file that fails to upload.

If you stop here, you get a tool that hits the size every time. You also get a tool that turns a 90-second 1080p clip into blocky soup, because 0.7 Mbps spread over two million pixels per frame is nowhere near enough.

The part that actually matters: bits per pixel

Bitrate on its own tells you nothing about how a video will look. 2 Mbps is generous at 480p and unwatchable at 4K. The number I care about is bits per pixel per frame:

const bpp = videoBitrate / (width * height * frameRate);

Here's the same 1 Mbps budget at two resolutions:

1920×1080 at 30fps → 0.016 bpp. Falling apart.
960×540 at 30fps → 0.064 bpp. Soft, but clean.

So when a bitrate is forced on me, I don't keep the source resolution and let the encoder smear it. I walk down a ladder and pick the largest size the budget can actually sustain:

const SHORT_EDGE_LADDER = [2160, 1440, 1080, 720, 540, 480, 360, 270, 180, 144];

I ladder on the short edge, not the height. Every phone video is portrait, and a 1080×1920 iPhone clip is "1080p", not "1920p". Treating it as landscape would have made every vertical video pick the wrong rung.

I also trade frame rate before I trade too much resolution. Once the budget drops a clip below 720p, I halve 60fps to 30fps and re-run the ladder. For gameplay and screen recordings, 30 sharp frames beat 60 mushy ones.

In practice this works out to roughly 20 seconds at 1080p, 30 seconds at 720p and a minute at 540p for a typical iPhone clip. Past 90 seconds it still fits in 8MB, but I show a warning before download, because it will look rough and I'd rather say so than let the user find out after they post it.

Bug #1: I turned a 1080p video into a postage stamp

My first quality floor was a fixed H.264 reference table:

bpp	what it looks like
0.15+	visually transparent
0.10	good
0.075	acceptable, my floor
0.05	soft, blocky on motion
0.03 and below	falling apart

Then a user sent me a 1080p clip at about 700 kbps and got back 480×270.

The table wasn't wrong. I was using it on the wrong videos. That table describes a first-generation encode, straight out of a camera. Most files people compress have already been through something: a messaging app, a download, an export. That earlier pass already stripped out the noise and fine detail, which are exactly the parts that cost bits. A re-shared clip holds up fine at a bpp that would look dreadful from a camera.

My planner read "low bpp" as "damaged" and "rescued" the video by throwing away three quarters of its pixels.

The fix: I judge the source against itself. The floor becomes whichever is lower, the absolute table value or a fraction of the bpp the source already carries:

const TARGET_BPP_FLOOR = 0.075;
const TARGET_SOURCE_FLOOR_RATIO = 0.2;

const bppFloor = Math.min(TARGET_BPP_FLOOR, srcBpp * TARGET_SOURCE_FLOOR_RATIO);

I tried keeping a small absolute floor underneath that, too. It produced my favorite absurd result: a source at 0.022 bpp got downscaled from 1858×1660 to 806×720 just to reach 0.032 bpp. I threw away most of the pixels to exceed the quality of the original. Any floor that can sit above the source's own bpp does this, so now the floor is purely relative.

Bug #2: HEVC made good videos look bad

I always encode H.264, because it plays everywhere: Discord, iPhone, Android, every browser. But sources arrive as HEVC, VP9 and AV1, and those codecs hold the same picture in noticeably fewer bits.

Every iPhone records HEVC by default. So a clean iPhone clip at 700 kbps of HEVC looked, to my planner, like a starved H.264 file. I was punishing sources for being efficient.

Now I convert the source bitrate into "the H.264 bitrate that would look the same" before comparing it with anything:

const CODEC_EFFICIENCY = {
  avc: 1,
  hevc: 1.45,
  vp9: 1.4,
  av1: 1.6,
  vp8: 0.95,
  prores: 0.25, // intra-only, spends huge bitrates on a picture H.264 carries cheaply
};

These are conservative mid-points from the usual codec comparisons, not gospel. When I can't detect the codec, I assume H.264. Guessing something more efficient would inflate my estimate of the source and over-compress it.

Bug #3: the encoder refused to spend my budget

This one surprised me. A user asked for 60MB and got 28MB. My retry logic noticed the undershoot, "corrected" the target to 58.2MB, and the next pass produced 28MB again.

The cause: in most WebCodecs implementations, a constant-bitrate request is a ceiling, not a promise. Easy content simply costs less than the budget allows, and the encoder won't pad it.

My correction step clamped the retry to just under the target, which meant it asked for less than the pass that had already undershot. Useless. Now, on an undershoot, I ask for more than the target:

if (actualBytes > desiredBytes) {
  // Overshoot: mandatory fix. The promise is "at most N MB".
  return previousTarget * (desiredBytes / actualBytes) * 0.96;
}

if (attempt === 1 && !cappedBySource && actualBytes < desiredBytes * 0.8) {
  // Undershoot: raise the ask once.
  const scale = Math.min(1.9, desiredBytes / actualBytes);
  return previousTarget * scale * 0.95;
}

That's safe because the overshoot branch runs first and is mandatory. If the raised ask lands over 8MB, the next pass pulls it back down. I cap it at three passes total, and I only raise once. If the content is cheap, it will undershoot at any budget, and every extra pass is a full re-encode the user sits through for nothing.

Bug #4: "compress" made a file bigger

A 684 kbps clip came back 10% larger. The culprit was audio. The source had a 48 kbps audio track, and I re-encoded it at 128 kbps.

Audio gets re-encoded, not copied, so giving it more bits than the original had invents nothing. It just makes the track bigger. On a thin video, that alone pushes the file past the original.

Audio now follows three rules:

It never gets more than the source had.
It never gets more than 18% of the total budget.
It snaps to a standard ladder (128, 96, 64, 48, 32, 24, 16 kbps) instead of arbitrary values, because some browsers' AAC encoders throw OperationError: Encoding error on odd low bitrates instead of just sounding worse.

At 64 kbps and below I switch to mono, since stereo at that rate sounds worse than mono. I only drop audio entirely when the budget can't carry even 16 kbps.

Running it in the browser

I use two engines behind the same plan:

Mediabunny on top of WebCodecs for modern containers. It uses the hardware encoder, so it's fast.
ffmpeg.wasm for everything else, and as a fallback when a hardware encode fails with a recoverable error. It's pure software, slower, but it doesn't depend on whatever GPU driver the user has.

Both engines consume the exact same CompressionPlan object (resolution, frame rate, bitrate, audio settings, keyframe interval), so they behave identically. The planner is a pure module with no browser APIs in it, which also means I can unit-test every one of the bugs above without touching a video file.

The client-side constraint cost me some speed, but it bought two things I care about. Nobody's video touches my server, and the source file can be as large as the user's device can handle.

One gotcha that isn't mine: what "8MB" means

I count 1 MB as 1,048,576 bytes, like Windows Explorer does. macOS Finder counts 1 MB as 1,000,000 bytes, so the same file looks bigger on a Mac: 7.6MB on Windows shows as 8.0MB in Finder.

My first pass aims at roughly 7.9 million bytes, which clears both definitions. If some upload form still rejects the file, the honest answer is to type 7 instead of 8.

What I'd tell anyone building this

The size is arithmetic. The quality is judgment. Spend your time on resolution and frame-rate decisions, not on the division.
Judge a source against itself. Absolute quality tables assume camera-fresh footage, and almost nobody compresses camera-fresh footage.
Know which codec spent the bits. An HEVC bitrate and an H.264 bitrate aren't the same number.
Treat encoder bitrate as a ceiling. Verify the output size and correct in both directions.
Tell the user the truth. If 8MB can't hold their 3-minute clip at a decent resolution, warn them before they download.

If you want to see how it behaves on your own clips, the tool is here: compress video to 8MB. It's free, there's no watermark or sign-up, and the video never leaves your browser.

I'm curious how other people handle the undershoot problem with WebCodecs. If you've found a cleaner fix than "ask for more and correct on the next pass", tell me in the comments.

Handbrake Alternatives: What to Use When You Don't Want to Install It

Max/Wang — Mon, 21 Sep 2026 10:08:28 +0000

People look for a Handbrake alternative for one of three reasons, and they need different answers.

Some want the same power without the interface — they're fine installing software, they just find Handbrake's settings panel unfriendly. Some want no install at all, usually because it's one file, or a work laptop that won't allow it, or a phone. And some want something Handbrake can't do — editing, trimming, subtitles, format conversions outside its range.

Worth saying clearly first: for batch-processing a library with precise encoder control, Handbrake is still the best free option and nothing listed below beats it at that. This is about the jobs where it's more tool than the task needs.

Browser-based compressors

The category that barely existed a few years ago. Browsers can now encode video natively through the WebCodecs API, which means a web page can compress a file on your own machine instead of uploading it somewhere — the same basic operation Handbrake performs, minus the install.

SquishyFile is built this way: open the page, drop in a video, either pick a compression level or type an exact target size in MB, download the result. Nothing uploads, there's no account and no watermark, and it works the same in Safari on an iPhone as in Chrome on a desktop.

Where it wins: one-off files, locked-down machines, phones and tablets, and the specific case of "this has to be under 25MB" — where you type 25 instead of calculating a bitrate and running a two-pass encode.

Where it doesn't: encoding runs on your own hardware, so a multi-gigabyte 4K source on a modest laptop takes real time. There's no queue of fifty files running unattended overnight, and no frame-level encoder control. If either of those is your workflow, stay with Handbrake.

Upload-based online converters

Clideo, VEED, FreeConvert, Media.io and a long tail of similar services take a different approach: you upload the file, their servers compress it, you download the result. That's genuinely useful when your own machine is slow, since the work happens on hardware you don't own.

Where it wins: heavy files on weak hardware, and feature sets that go well beyond compression — trimming, subtitles, format conversion, basic editing.

Where it doesn't: your video leaves your device, which rules the category out for anything confidential. Free tiers vary a lot and change often — caps on file size or duration, watermarks, required accounts, daily limits. Check the current terms of whichever one you're considering rather than trusting a comparison article, this one included. And large uploads on a slow connection can take longer than compressing locally would have.

Other desktop tools

FFmpeg is what Handbrake is built on, minus the interface. If you're comfortable at a command line it's strictly more capable, scriptable, and the fastest way to batch anything. If you're not, it's a wall of flags.

VLC is already installed on most machines and has a convert/save function that will compress video. It works. It's also poorly signposted, gives much less control than Handbrake, and fails in ways that are hard to diagnose. Fine in a pinch, not a real replacement.

Shutter Encoder is the closest thing to a direct Handbrake competitor — an FFmpeg front-end with a broader feature set covering conversion, trimming and some professional formats. Different interface philosophy; whether it's friendlier is a matter of taste. Free.

Adobe Media Encoder and similar paid tools are excellent and priced for people who do this professionally. Not a sensible answer to "I don't want to install Handbrake".

Built-in options you already have

On macOS, QuickTime Player's File → Export As offers fixed resolution presets (1080p, 720p, 480p). Crude, no size control, already installed.

On iOS, Mail's attachment size menu and the Shortcuts app's Encode Media action both compress without any download — covered properly in how to compress a video on iPhone.

On Windows, the Photos app can export at a lower resolution, though it's slow and the controls are minimal.

All of these share the same limitation: resolution presets, not size targets. They'll make a file smaller. They won't make it smaller than a specific number.

Picking one

What you need	Use
One file, under a specific MB limit	A browser-based compressor
Fifty files, overnight, precise settings	Handbrake or FFmpeg
Can't install software on this machine	A browser-based compressor
Huge file, slow hardware, not confidential	An upload-based service
Compress plus trim, subtitles or editing	An upload-based editor, or Shutter Encoder
Confidential footage	Anything local — Handbrake, FFmpeg, or a browser-based tool
Scriptable and repeatable	FFmpeg

Common questions

Is there an online version of Handbrake?

Not officially — Handbrake is desktop-only and there's no web edition. The closest equivalent is a browser-based compressor that encodes on your own device, which matches the "nothing uploads" property without matching Handbrake's depth of settings.

What's the best free alternative to Handbrake?

It depends on the job. FFmpeg if you want more power and are fine with a command line, Shutter Encoder for a broader GUI feature set, and a browser-based compressor for one-off files where you'd rather not install anything at all.

Can I compress a video without downloading software?

Yes. Browser-based compressors encode on your device with nothing installed, and upload-based services do the work on their servers. The difference that matters is whether your file leaves your machine.

Is Handbrake still worth using?

Very much so, for batch work and precise encoder control — it remains a strong free desktop option, and our settings guide covers getting good results from it. It's just heavier than a single file usually warrants.

Are online video compressors safe?

Browser-based ones don't transmit your file at all, so there's nothing to intercept or store. Upload-based ones necessarily send it to a third-party server — fine for a holiday clip, worth thinking twice about for anything confidential.

The honest summary

Most people searching for a Handbrake alternative don't need a smaller, friendlier Handbrake — they need a video under a size limit in the next few minutes, and a full encoding suite is the wrong shape of tool for that.

If that's you, type the number into a browser-based compressor and move on. If you're processing a library, or you need specific encoder parameters, install Handbrake and read what its settings actually do — you'll get better results than a simpler alternative will give you.

I downscaled a 1080p video to 480x270 to protect its quality

Max/Wang — Sun, 20 Sep 2026 14:57:42 +0000

Someone handed my compressor a 1080p clip. It gave back a 480×270 postage stamp.

Nothing crashed. Every line did what I wrote it to do. I had written code that looked at that video, decided it was too damaged to deserve its own resolution, and rescued it by throwing away three quarters of its pixels.

I build this thing on my own, so there's nobody to hide behind here. Every bug below is mine, and I shipped six of them in about two weeks.

Quick context, then I'll get to the interesting part. The tool compresses video entirely client-side — nothing uploads. I run two engines: WebCodecs through Mediabunny as the fast path, using the browser's own hardware encoders where they exist, and single-threaded ffmpeg.wasm (~32 MB, fetched on first use, then parked in the Cache API) for containers WebCodecs can't demux — AVI, WMV, FLV, MPEG program streams, older 3GP. I picked the single-threaded core deliberately: the multi-threaded one needs SharedArrayBuffer, which needs COOP/COEP headers, which would break static hosting for the sake of files that are rare and usually small.

None of that matters much for what follows. I barely had a single bug in the encoders. All of them lived in the ~700 lines that decide what to ask an encoder for.

Bitrate is the wrong number to look at

A compressor has to answer one question: given this source and this goal, what resolution, frame rate and bitrate do I encode at? And the quantity that decides how a video looks isn't bitrate. It's bits per pixel per frame.

bpp = videoBitrate / (width * height * frameRate)

2 Mbps is generous at 480p and unwatchable at 4K. Rough H.264 landmarks:

bpp	looks like
0.15+	visually transparent
0.10	good (YouTube-ish)
0.075	acceptable
0.05	soft, blocky on motion
0.03−	falling apart

So when a bitrate gets forced on me — "fit this in 25 MB" — I don't keep the source resolution and let the encoder smear it into mush. I ladder down: take the largest resolution whose bpp still clears a floor. I set that floor at 0.075, straight off the table above.

That floor is the bug.

The floor ate the picture

Here's the clip that broke it. 1080p, 30 fps, 700 kbps. The level's retention cut takes the budget to ~455 kbps first, then my ladder runs:

short edge	dimensions	bpp at 455 kbps	clears 0.075?
1080	1920×1080	0.0073	no
720	1280×720	0.0165	no
540	960×540	0.029	no
480	852×480	0.037	no
360	640×360	0.066	no
270	480×270	0.117	yes

Every step is correct. The conclusion is insane.

My table lies in two ways it doesn't warn you about.

It describes a first-generation encode. It tells you what a fresh capture out of a camera needs. But most files people compress have already been through a pass — a messaging app, a download, an export. That pass already stripped the noise and fine detail, which are the parts that cost bits. A second-generation clip holds up fine at a bpp that would look dreadful straight off a sensor. I read a re-shared clip's low bpp as damage, and that's the whole bug.

I double-charged. I cut the source bitrate to a fraction first, and then ran the resolution ladder against the already-cut number. My cut caused my downscale, and both landed on the same clip.

Target-size mode produced the stupidest version of this. A 77.5 MB source carrying 0.022 bpp, asked to fit in 25 MB, went from 1858×1660 down to 806×720 — a downscale whose entire purpose was to reach 0.032 bpp. Half again the density the source itself had. I threw away three quarters of someone's pixels in order to beat the quality of their original.

Here's the one thing in this post I'd actually put on a wall:

Any absolute quality floor that can sit above the source's own value will destroy the source in order to meet it.

So I made the floor purely relative. Now it can never get up there:

const bppFloor = srcBpp === null
  ? TARGET_BPP_FLOOR
  : Math.min(TARGET_BPP_FLOOR, srcBpp * 0.2);

A fifth of whatever the source itself carried. I landed on 0.2 because bpp is really standing in for how hard the content is to encode, and a source's own bpp is the best measure of that I have: footage that already survives at a low bpp is cheap footage, and it stays cheap at a fifth of that.

That downscale was also worse than it looked, for a reason I didn't see coming. In target-size mode it defeats itself — a smaller frame is cheaper to encode, so the encoder stops spending the budget I gave it and lands far under target. The user pays in resolution and gets a file half the size they asked for. One 91 MB file asked to fit in 60 MB — a budget covering two thirds of its own bitrate — came back at 720p for exactly this reason.

I was dividing a number I never measured

Underneath all of that sat something worse. The number I kept dividing wasn't a video bitrate at all.

When my packet-index read failed or looked unrepresentative, I fell back to this:

videoBitrate = (file.size * 8) / durationSec;

That's the wrong quantity, not a rougher version of the right one. It folds in the audio track and every byte of container overhead, so it reports a video bitrate the video track never had. Then my planner divides it by the pixel count and decides, from a number nobody measured, whether the source keeps its resolution.

I had a real reason for that fallback. I used to sample only the first 120 packets (~4 s) to get the frame rate, and a prefix that short genuinely misleads whenever the opening seconds are simpler than the rest — so I threw away the bitrate that came with it.

Then I stopped being scared of the full pass:

const stats = await videoTrack.computePacketStats(); // metadataOnly
if (stats.averagePacketRate > 0) frameRate = stats.averagePacketRate;
if (stats.averageBitrate > 0) videoBitrate = stats.averageBitrate;

Scanning every packet costs almost nothing, despite how it sounds. With metadataOnly it reads each sample's size and timestamp straight out of the container index — stbl/stsz for MP4, Cues for MKV/WebM — and never touches a frame of pixel data, let alone decodes one. The file is already a local Blob, so nothing goes over the network. You get both numbers exactly: averagePacketRate is the real frame rate, and averageBitrate is the video track's own bitrate, measured from actual packet sizes.

I punished files for being efficient

I always write H.264. But sources show up as HEVC, VP9 and AV1 — every iPhone since iOS 11 records HEVC by default, and the messaging apps most videos arrive through re-encode to HEVC or VP9 too.

700 kbps of HEVC carries roughly what 1 Mbps of H.264 carries. Compare a source bitrate against an H.264 table without converting it first and you'll conclude that a lean phone clip is a bad one, then compress it accordingly. I was penalising files for being efficient.

const CODEC_EFFICIENCY = {
  avc: 1, vp8: 0.95, vp9: 1.4, hevc: 1.45, av1: 1.6, prores: 0.25
};

ProRes sits below 1 because it's intra-only: it spends enormous bitrates on a picture H.264 holds for a fraction. An unknown codec assumes 1.0 — if I assumed anything more efficient I'd inflate my estimate of the source's quality and over-compress it.

But that conversion can ask for a bigger file than the source. Holding an HEVC or AV1 picture in H.264 really does cost 45–60% more bits, so the conversion times a high retention can land above what the source actually spent. A button labelled "compress" handing back a larger file is indefensible no matter how good my image-quality argument is, so I cap it hard at 0.95 × source. When those two goals collide, compressing wins.

Audio had the identical bug, and this is the one I'm least proud of: a 684 kbps clip with a 48 kbps audio track came back 10% larger on my lightest setting, because I re-encoded the audio at 128 kbps. I re-encode audio rather than copy it, so asking for more bits than the original carried invents nothing — it just makes the track bigger than the one it replaces. On a thin video track, that alone flips the whole file. Now I treat the source's audio bitrate as a ceiling, not a target.

Browsers lie to you as well

Three of these, quickly.

Codec support answers are optimistic. I asked Chrome whether AAC could handle 16–24 kbps mono. It said yes — an isConfigSupported-style answer, not a real encode attempt. Then it threw OperationError: Encoding error on the very first sample. I reproduced it at 16000, 24000 and 25969 bps alike, on a freshly created worker's first encode, so it isn't a warm-up artifact either. I stopped asking and hardcoded the split: Opus below 64 kbps, AAC at or above. Opus is the better codec down there anyway.

Firefox ships an AVC encoder and no AAC encoder. The tempting read is that Firefox needs my ffmpeg path. It doesn't — MP4 carries Opus perfectly well, and pulling 32 MB of wasm over someone's connection because of an audio track would be ridiculous. So my engine decision checks exactly one thing, on purpose: canEncodeVideo('avc').

Hardware encoder sessions are a shared, limited resource, and closing one doesn't always free it right away. Compress twice back to back in the same tab and the second can fail with that same generic OperationError — and so can every attempt after it, until you reload the page. I now treat that specific DOMException as recoverable and drop to ffmpeg.wasm for the rest of the run, because software encoding never touches the session I couldn't get.

A constant bitrate request is a ceiling, not a promise

In target-size mode I check the output and re-encode when I miss. Correcting an overshoot is mandatory — "at most 25 MB" is a promise I made.

Undershoot is the interesting direction. It's almost never because I asked for too few bytes; I asked for the target. It's because the encoder declined to spend them. Most WebCodecs implementations treat a constant-bitrate request as a ceiling, and easy content simply costs less than the budget allows.

Which means the right answer to an undershoot is to ask for more than the target. I used to clamp the corrected ask to desiredBytes * 0.97, so correcting a 28 MB result against a 60 MB target handed back an ask of 58.2 MB — smaller than the ask that had just undershot. My next pass faithfully reproduced 28 MB and gave up.

I raise it once, though, not repeatedly. An encoder undershooting because the content is cheap will undershoot at any budget, and every extra pass is a full re-encode someone sits and waits through.

The line that looked like a no-op

Passing frameRate into the conversion when it already equals the source's rate is not a no-op. Mediabunny quantises every sample onto a rigid 1/frameRate grid and drops or duplicates whichever sample lands in a bucket that's already full. Real footage is rarely perfectly constant-frame-rate — auto-exposure and capture jitter alone push samples off any fixed grid, and a VFR source has no single rate to quantise to at all. I forced that grid when I didn't need to, and it produced real judder. Now I pass it only when I deliberately changed the rate, and the same goes for ffmpeg's -r.

One more, free: round output dimensions down to even, never to nearest. H.264 wants even dimensions for 4:2:0 chroma, and real captures and crops do produce odd heights. Rounding 1081 up to 1082 means encoding a frame larger than the source — interpolating pixels that were never there, for a softer picture at more bits.

What they all had in common

Every one of these came from taking a number at face value:

a bitrate I computed from file size and called a video bitrate
a quality table describing first-generation encodes, which I applied to footage that had been through Messenger
a codec-support API answering about a configuration it had never tried
a bitrate request the encoder treated as optional

The encoders were fine. WebCodecs and ffmpeg.wasm both did exactly what I asked. Every bug was in my asking.

If you're building something in this shape, here's the rule that would have saved me most of it: judge the source against itself, not against a table. An absolute standard, applied to a file that never met it, will always conclude the file has to be destroyed for its own good.

The compressor all this came out of is at squishyfile.com — runs in your browser, nothing uploaded. Ask me anything in the comments, I'll go as deep as you want.

Convert MP4 to Transcript

Max/Wang — Thu, 17 Sep 2026 10:14:50 +0000

Running speech recognition locally is possible, but the real challenge isn't just making the model run in a browser.

You have to balance model size, processing speed, memory usage, language support and transcription quality — all on hardware you don't control.

The result is a different trade-off from cloud transcription: no upload or server processing, but a smaller model and more limited language coverage.

I built an MP4 → text tool around that approach. It currently supports English, Spanish, Japanese, Chinese and Korean, with TXT, SRT and VTT export.

Try it here: https://squishyfile.com/mp4-to-transcript

I Built My Own Free Background Remover

Max/Wang — Wed, 16 Sep 2026 14:15:48 +0000

Recently, remove.bg started moving its background removal experience to Canva.

So I started looking around for alternatives.

There are quite a few good ones. Adobe has a pretty decent background remover, for example. The actual results are surprisingly good.

But then I hit the usual problems.

Limits.

And sometimes you can process an image for free, but you need to sign in before you can actually download the result.

I also came across rembg, which is completely free and works really well. But I wanted something that could handle HEIC and HEIF images too, since a lot of photos these days come directly from iPhones.

So, naturally, I ended up coding my own.

A background remover that runs in the browser

I wanted to keep the whole thing simple:

Free
No account
No download limits
Supports JPG, PNG, WebP, HEIC and HEIF
Background removal happens locally in the browser

For the model, I went with BiRefNet-lite and converted it to ONNX so I could run inference with ONNX Runtime Web.

The interesting part is that this doesn't need a backend GPU.

It uses WebGPU when available, so the model can run directly on the user's machine.

I've tested it on a few different images and, honestly, the results are pretty good. Hair, people, products, objects, etc. are generally handled quite nicely.

It's not magic, of course. Background removal is one of those tasks where there will always be difficult images — messy hair, low contrast, objects blending into the background, and so on.

But for a lightweight browser tool, I'm pretty happy with it.

Why BiRefNet-lite?

I also looked at other models, including RMBG-1.4.

RMBG-1.4 can be very fast in my testing, and the output quality is in the same general range.

However, licensing matters when you're building a public commercial website, so I ended up using BiRefNet-lite for this project. The model is released under the MIT license, which makes things much simpler for this kind of use.

The trade-off is that inference isn't necessarily as fast as RMBG-1.4 on every setup.

That's something I'm still interested in optimizing.

One important limitation

There is one fairly big requirement:

Your browser needs WebGPU.

If your device or browser doesn't support WebGPU, this tool won't work.

That's the trade-off for running a relatively capable AI model directly on the user's machine instead of sending images to a server.

For newer laptops, desktops, and phones, WebGPU support is becoming much more common, though.

HEIC/HEIF was actually one of the reasons I built it

This was probably the biggest practical motivation.

If you're using an iPhone, there's a good chance you've encountered HEIC images.

I wanted to be able to drop one of those images into the tool, remove the background, and download the result without having to convert it somewhere else first.

So now it does exactly that.

Anyway, this started as one of those "why doesn't this simple thing work the way I want?" projects and turned into another little tool for SquishyFile.

You can try it here:

https://squishyfile.com/image/transparent-background-creator

Hopefully some of you find it useful. 🙂