Category: basic knowledge (Page 1 of 3)

The single most common complaint about browser-based video compression has never been quality, privacy or file size. It’s the wait. You pick a file, you hit start, and then you sit there watching a progress bar creep across a 40-minute recording.

We just shipped an upgrade to the engine that does that work. On the same file, on the same machine, encoding now runs roughly three times faster than it did before. Nothing about your workflow changes — same page, same buttons, same output file. It simply finishes sooner.

What actually changed

RedPandaCompress runs a real video encoder inside your browser, compiled to WebAssembly. That’s what makes the privacy guarantee possible in the first place: your file is processed by code running on your own device, so there is no upload step and nothing to store on a server.

The trade-off has always been that a browser sandbox is a more constrained place to run an encoder than a native app. This release is a substantial rework of how that engine executes — enough of a change that we’re measuring around a 3× improvement in encoding throughput on typical hardware. We’re keeping the implementation details to ourselves for now, but the part that matters to you is simple and measurable: the same job, finished in about a third of the time.

What 3× looks like on real files

Encoding time scales with how many pixels there are to process, so the absolute saving grows with the length and resolution of your video. The relative saving is what stays roughly constant. A rough guide, based on the speedup applied to jobs of each size:

Source file	Before	Now (approx.)	Time you get back
1 min, 1080p phone clip	~45 s	~15 s	half a minute
10 min, 1080p screen recording	~7 min	~2.5 min	~4.5 min
12 min, 4K drone footage	~24 min	~8 min	~16 min
45 min, 1080p lecture	~32 min	~11 min	~21 min

Treat those as a shape rather than a promise. Your actual numbers depend on your CPU, how many other tabs are competing for it, and what codec the source file is in. But the pattern holds: the longer the video, the more real time the upgrade hands back to you.

A worked example

Say you have a 1.2 GB, 12-minute 4K clip off a drone, and you need it under 200 MB to share with a client.

The output is identical to what you’d have got last month: an H.264 MP4 at roughly 180 MB that plays on any phone, laptop, TV or editor you hand it to. The difference is that the job that used to occupy the better part of half an hour — long enough that you’d start it and go do something else, then forget about it — now finishes inside a coffee break, with the tab still open in front of you. For anyone compressing several files in a sitting, that’s the difference between a background chore and something you just do.

What did not change

This is a speed release, and it was important to us that it stayed only a speed release. Specifically:

• Your files still never leave your device. There is no upload, no server-side processing, no temporary copy sitting in someone’s bucket waiting on a deletion timer. Faster local work is still local work. If you want to verify that yourself rather than take our word for it, we wrote up three ways to check whether a converter uploads your files — including the numbers we measured on our own tool.
• Output is still universally compatible H.264 MP4. We didn’t buy speed by switching you to a more exotic codec that half your devices won’t play.
• Quality and file size targets are unchanged. Ask for the same target size and you get the same result — this isn’t a case of going faster by encoding worse.
• Large files are still supported. Multi-gigabyte sources keep working the way they did.
• Nothing to install or update. Reload the page and you have it. There’s no version to pick and no setting to turn on.

Where you’ll notice it most

Not every job feels three times faster, because not every job was encoding-bound to begin with. The upgrade pays off most on:

• Long recordings — lectures, webinars, gameplay, anything measured in tens of minutes.
• High-resolution sources — 4K footage has four times the pixels of 1080p, so it was the most painful case and gains the most.
• Modern multi-core laptops and desktops — machines with cores to spare see the biggest improvement.

It pays off least on very short clips, where a few seconds of setup is most of the total time anyway, and on older or low-core devices, where the ceiling is the hardware rather than the software. Phones benefit, but less dramatically than a desktop does — a phone has fewer cores and throttles itself when it gets warm.

One practical tip either way: keep the tab in the foreground while it works. Browsers aggressively deprioritise background tabs, and that will cost you more time than any engine upgrade can give back.

Frequently asked questions

Will my compressed videos look different now?

No. Same encoder settings, same target sizes, same H.264 MP4 output. If you re-run a file you compressed last month at the same target, you should get a comparable result — just sooner. If you do see a difference in quality or size that you can’t explain, we’d genuinely like to know about it.

Why isn’t my machine hitting 3×?

Three times is what we see on typical multi-core hardware, not a guarantee for every device. An older laptop, a low-end phone, a machine already busy with a video call, or a very short clip will all land below that. It should still be faster than it was, on the same file and the same machine.

Does this affect the converters and audio tools too?

The improvement is in video encoding, so it shows up wherever video is re-encoded — format conversion included. Jobs that never re-encode video in the first place, like pulling the audio track out of a video, were already fast because they were mostly reading and copying data, not encoding it.

Do I need to do anything to get it?

No. It’s live for everyone. If you had the site open in a tab from before the update, reload it once and you’re on the new engine.

Found a problem? Tell us

A change this deep in the engine touches every file that goes through the site, and real-world video is endlessly varied — odd codecs, unusual frame rates, files from cameras we’ve never seen. If something that used to work now doesn’t, if a file fails, or if a result looks wrong to you, please email us at support@redpandacompress.com. Telling us the file format, roughly how big it was, and which browser and device you were on is enough for us to start looking. Feature requests and “why does it do this” questions are welcome at the same address.

Otherwise, there’s nothing to do but use it. Drop a file on RedPandaCompress and watch it finish sooner than you expect — still free, still entirely in your browser, still without your video ever leaving your computer.

Every online audio converter says roughly the same thing on its homepage: fast, free, private. Almost all of them mean the same thing by it — your file is uploaded to a server, converted there, and handed back as a download link. “Private” means they promise to delete it later.

Ours works differently, and the difference is architectural rather than a policy: the file is never sent anywhere, because the converter itself runs inside your browser tab. This post is the engineering walkthrough — what actually executes, the one trick that makes multi-gigabyte files possible, and the honest trade-offs of building it this way.

The conventional design, and what it costs

A server-side converter has a fixed sequence: upload the whole file, wait in a queue, convert, download the result. The conversion is usually the fastest part. The upload is the part you actually feel.

A 600MB WAV export on a typical 20Mbps upstream connection takes about four minutes to upload before any work begins — and that number is on the optimistic side of what home connections actually deliver. Then it sits on infrastructure you do not control, subject to whatever retention window is written in a policy page.

Removing the upload removes all of it at once: the wait, the queue, the retention question, and the per-file cost that forces other converters to cap free usage. That is the whole motivation.

What actually runs: FFmpeg, compiled to WebAssembly

The engine is FFmpeg — the same project that sits underneath most desktop and server-side media tooling — compiled from C to WebAssembly with Emscripten. It ships as a roughly 7.5MB .wasm binary plus a small JavaScript loader, downloaded once and then cached by the browser.

Two details matter more than they might look:

• It runs in a Web Worker, not on the page’s main thread. Audio encoding is a long, CPU-bound loop; on the main thread it would freeze the interface completely. In a worker, the page stays responsive and progress can be reported while the encode runs.
• It is real FFmpeg, not a re-implementation. The build includes LAME for MP3, the native AAC encoder, PCM for WAV output, and the ipod muxer that produces proper M4A files. The command lines are ordinary FFmpeg arguments — the same ones you would type in a terminal.

The worker is started lazily, while the page sits idle waiting for you to choose a file, so the binary is usually already warm by the time it is needed.

The trick that makes gigabyte files possible

This is the part that most in-browser converters get wrong, and it is the reason many of them quietly cap you at 100MB or 500MB.

The obvious implementation is to read the selected file into memory as an ArrayBuffer and hand that array to the WebAssembly module. It works beautifully in testing — and then dies on a real 3GB lecture recording, because you have just asked the browser to hold the entire file in the WebAssembly heap, on top of whatever the encoder itself needs.

Instead, the file is mounted as a virtual filesystem inside the worker using Emscripten’s WORKERFS. FFmpeg sees an ordinary path it can open and seek around in. Underneath, every read is served by slicing the browser’s File object and reading just that slice synchronously — the bytes are pulled off disk on demand, in the order the demuxer asks for them, and are never all resident at once.

Two consequences fall out of that:

• Memory use tracks the working set, not the file size. An 8GB source is not meaningfully harder on memory than a 200MB one.
• Conversion starts immediately. There is no read-the-whole-file step before work begins — the first bytes are read the moment FFmpeg wants them.

Approach	Time before work starts	Practical size ceiling	Where your file goes
Upload to a server	Full upload + queue	Whatever the free tier allows	Their infrastructure
In-browser, read whole file into memory	Seconds to minutes	Hundreds of MB	Stays local
In-browser + WORKERFS (what we use)	Essentially none	8GB desktop / 2GB mobile	Stays local

Step one: probe, then decide

Before converting anything, the worker runs FFmpeg once with just -i pointed at the mounted file. That prints the input banner — container, streams, codecs, duration — which gets parsed out of the worker’s stderr messages.

That one cheap run pays for three things:

1. A real progress bar. FFmpeg reports its position as a timestamp, not a percentage. Knowing the total duration up front is what turns time=00:04:11 into a meaningful number on screen.
2. A useful error instead of a cryptic one. If the file has no audio stream at all, you get told that in plain language rather than watching a conversion fail deep inside the encoder.
3. The copy-versus-encode decision, which is the difference between seconds and minutes.

Copy versus encode

Converting audio does not always mean re-encoding it. When the source stream is already in the codec the target container wants, the stream can simply be lifted out and rewrapped — no decoding, no encoding, no quality loss whatsoever.

Source → target	What runs	Speed	Quality effect
MP3 → MP3	-c:a copy	Seconds, any size	None — bit-identical stream
AAC (most MP4/MOV) → M4A	-c:a copy	Seconds, any size	None — bit-identical stream
Anything → MP3	Decode + LAME at 192kbps	Much faster than real time	One lossy generation
Anything → M4A	Decode + AAC at 192kbps	Much faster than real time	One lossy generation
Anything → WAV	Decode + PCM 16-bit	Fast; output is large	None beyond the source’s own

Worked example. Pulling the audio out of a 2-hour, 3GB MP4 lecture recording: the video stream is discarded with -vn, and because the audio inside an MP4 is nearly always AAC, choosing M4A output takes the copy path — a few seconds, and roughly 170MB out. Choosing MP3 instead forces a decode-and-re-encode, which takes a couple of minutes and lands in the same size range. Same file, same page, two very different amounts of work, decided automatically by what the probe found.

This is also why the honest advice about output format is not “always pick the biggest number”. If you want the details of that trade-off, we wrote them up separately in WAV vs MP3: which audio format should you use.

Getting the file back out

FFmpeg writes its output into the WebAssembly module’s in-memory filesystem. When the run finishes, the worker posts that buffer back to the page, where it becomes a Blob and then an object URL that the download button points at. No network request is involved in any of it.

One detail here cost real debugging time and is worth passing on. The buffer that comes back can be padded with trailing zero bytes. Tolerant players — VLC, Chrome — happily ignore the padding. Strict demuxers do not: macOS QuickLook and Windows Media Foundation would reject a file that played perfectly elsewhere. The fix is to walk the MP4 box headers from the start of the buffer, follow each box’s declared size to find where the last real box ends, and truncate there. Payloads that are not MP4-structured simply fall through unchanged.

“It plays in my player” is not the same as “it is a valid file”, and only one of those is good enough to ship.

The honest trade-offs

Running locally is not free of downsides, and it would be dishonest to present it as pure upside.

• You pay a one-time download of about 7.5MB for the engine, on first use.
• It uses your CPU and your battery, not a rack somewhere. On a very old phone, a long re-encode is genuinely slower than a server would be.
• Audio conversion here runs single-threaded, one file at a time — a batch is processed serially rather than in parallel.
• There is still a size ceiling, because browsers impose their own limits on how much a tab may allocate. It is 8GB on desktop and 2GB on mobile rather than 100MB, but it is not infinite.

What you get in exchange: no upload wait, no queue, no account, no watermark, no per-file pricing, and no copy of your recording sitting on someone else’s disk. For voice memos, client interviews, medical or legal recordings and unreleased music, that last point is not a nice-to-have.

Frequently asked questions

How can I verify my file really is not uploaded?

Check it yourself, which is the point of an architecture like this. Open your browser’s developer tools, switch to the Network tab, and convert a file. You will see the page’s own assets and the engine binary load, and no request carrying your audio. For a stronger test, disconnect from the network after the page has finished loading — the conversion still completes, because nothing about it needs a server.

Is WebAssembly slower than a real server?

For the encode step itself, somewhat — WebAssembly typically lands within a small factor of native code, and this build is single-threaded. But end-to-end, the comparison usually favours running locally, because the server route has to move the file across your connection twice before it can start. For a large file, the upload alone tends to exceed the entire local conversion.

Why does the same file sometimes convert in seconds and sometimes take minutes?

That is the copy-versus-encode split above. If the source stream already matches the output container — MP3 into MP3, AAC into M4A — it is rewrapped without re-encoding and finishes almost instantly. Any other combination has to decode and re-encode the audio, which is real work proportional to the recording’s length.

Which formats can it read?

Audio: MP3, M4A/AAC, WAV, FLAC, OGG, Opus and WMA. Video: MP4, MOV, MKV, AVI, WebM, WMV, TS, MPG, FLV and 3GP, with the audio track extracted. Output is MP3, M4A or WAV. Because the engine is real FFmpeg, the input list is a matter of which demuxers were compiled in rather than a hand-written parser per format.

Try it

The whole cluster runs on the pipeline described above: the audio converter if you want to choose the output format, or a fixed-output page like WAV to MP3, MP4 to MP3 or M4A to MP3 if you would rather not make one.

Free, unlimited, no signup — and the file stays on your machine, which you can confirm with the Network tab rather than taking our word for it. More tools at RedPandaCompress.