RedpandaCompress Blog

Free Video Compression for Everyone.

3× Faster Video Compression: We Just Upgraded Our Engine

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 fileBeforeNow (approx.)Time you get back
1 min, 1080p phone clip~45 s~15 shalf 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.

Are Online File Converters Safe? How to Check If Yours Uploads Your Files

Ask whether an online file converter is safe and you’ll get the same answer everywhere: look for HTTPS, check that they delete files afterwards, avoid sketchy sites. All reasonable. All beside the point.

Those answers quietly assume the file gets uploaded, and then argue about how well it’s guarded afterwards. But uploading isn’t a requirement of converting a file — it’s an architectural choice, and a growing number of tools don’t make it. So the useful question isn’t “do I trust their retention policy?” It’s the much simpler, much more checkable: did my file leave this computer at all?

You can answer that yourself in about a minute, without taking anyone’s word for it. Here are three tests, from most rigorous to easiest, and what we measured when we ran them on our own tool.

First: there are two completely different things called “online converter”

They look identical — a web page, a drop zone, a download button. Underneath they’re opposites.

Server-sideIn-browser (local)
Where the work happensTheir machinesYour machine
Your fileUploaded, stored, processed, deleted on a timerNever transmitted
Wait before work startsFull upload timeNone
Why there’s a size capBandwidth and CPU cost them moneyOnly your device’s memory
Privacy rests onTheir policy and their securityNothing leaving in the first place
Typical free-tier limit100 MB – 1 GBMulti-gigabyte

This is why the tests below work at all. The two designs leave completely different fingerprints, and neither can hide them.

Test 1: Watch the network tab (the rigorous one)

Your browser will tell you exactly what it sent. Nobody can spoof this — it’s your own browser reporting on itself.

  1. Open the converter, then press F12 (or Cmd+Option+I on a Mac) and click the Network tab.
  2. Click the clear button to empty the list.
  3. Now add your file and run the conversion.
  4. Sort by the Size column, largest first, and look at the biggest outgoing request.

If it uploads: you’ll see a POST request roughly the size of your file. A 200 MB video produces about 200 MB of outgoing data. It cannot be smaller — the bytes have to physically get there.

If it’s local: the largest outgoing request will be kilobytes. There is nowhere for a 200 MB payload to hide.

One false positive to know about

You will very likely see entries starting with blob:, sometimes with a large size and a 206 status. That is not an upload. A blob: URL is a local handle to data already in your browser’s memory, and the browser lists it in the Network panel because it’s a “fetch” in the technical sense. Nothing crosses the network. Local tools generate a lot of these — it’s a sign of local processing, not against it.

The entries that matter are ones with a real hostname and a request payload.

Test 2: The stopwatch test (no tools needed)

Uploads obey physics. Your home internet’s upload speed is usually far slower than its download speed, and a file cannot be processed on a server before it has finished arriving.

Your fileMinimum upload time at 10 Mbps upAt 50 Mbps up
100 MB~80 seconds~16 seconds
1 GB~14 minutes~3 minutes
4 GB~55 minutes~11 minutes

So: drop in a large file and watch what happens in the first few seconds. If a progress bar for the actual conversion starts moving immediately on a 2 GB file, no upload occurred — there wasn’t time. If you sit through a long “Uploading…” phase before anything else happens, you have your answer, and it was honest about it.

This is also the practical reason local tools handle big files at all. A site paying for bandwidth has to cap you; a tool using your own CPU has no such bill.

Test 3: Cut the network mid-job

The bluntest test: take the internet away and see if the work continues.

The sequencing matters, and most write-ups of this test get it wrong. Modern web apps load code in pieces, so the conversion engine may not download until the moment you actually select a file. Disconnect too early and you’re testing whether the page finished loading, not where the processing happens.

Do it in this order:

  1. Open the page and select your file. Wait until the tool shows it’s ready to go.
  2. Now turn off Wi-Fi or pull the cable.
  3. Start the conversion.

A local tool runs to completion and hands you the file. A server-side tool stalls or errors out, because the thing doing the work is no longer reachable.

What we measured on our own tool

It would be a bit much to publish these tests without running them on ourselves. So we did, with the browser’s own network log as the instrument.

We fed a 4.19 MB MP4 into the video compressor on this site and recorded every outgoing request from the moment the file was selected until the download was ready.

  • Total outbound data: 1,325 bytes. Two Google Analytics beacons — 311 bytes and 1,014 bytes.
  • Bytes of video sent: zero. The largest request body in the entire run was one kilobyte.
  • During the encode itself, requests to our own domain: zero. Not a single one while the progress bar was moving.

An accidental detail makes the point better than we’d have managed on purpose: during the test, those analytics beacons actually failed — our own host returned a 503 for them. The compression finished anyway, at full speed. The pipeline doesn’t just avoid sending your file; it doesn’t depend on the network at all once it’s running.

Two things we want to be straight about. First, yes — there is analytics, and there are ads on the page. That’s how a free tool with no signup and no upload cost stays free. What those beacons carry is page views and button clicks, not your file. Second, that 1,325 bytes is the honest full number, not “roughly nothing” — you can reproduce it with Test 1 in about a minute, and we’d rather you did.

The mechanism behind this isn’t exotic. The conversion runs as WebAssembly — a real build of FFmpeg compiled to run inside the browser tab, reading your file straight off your disk through the browser’s file API. We wrote up how that pipeline works in detail in How an In-Browser Audio Converter Actually Works.

What “we delete your files after 2 hours” actually buys you

Most reputable server-side converters do delete uploads, and most of them mean it. This isn’t an accusation. It’s about what kind of assurance you’re getting.

A deletion policy is a promise about something that already happened. Your file was transmitted, written to a disk you don’t control, and passed through logs, backups and whatever infrastructure sits in between. Keeping that promise depends on their retention actually working, their access controls holding, their vendors behaving and their company continuing to exist. Every one of those is probably fine. None of them is checkable by you.

A file that was never sent doesn’t need a promise. There is no copy to retain, breach, subpoena or forget about.

For a meme clip, the difference is academic — upload it anywhere. It stops being academic for the things people actually convert and compress: a signed contract, a passport scan, medical paperwork, an NDA’d client cut, unreleased footage, video of your kids. That’s also why we care most about it on the PDF compressor, which is where the genuinely sensitive documents show up.

Frequently asked questions

Are online file converters safe to use?

The mainstream ones are generally safe in the sense that they aren’t trying to harm you — the real variable is whether your file gets uploaded, and how much you care about that for this particular file. Run Test 1 above and you’ll know which kind of tool you’re using in about a minute, rather than relying on the marketing copy.

Does HTTPS mean my file is private?

No. HTTPS protects your file in transit, from people between you and the server. It says nothing about what happens once it arrives — who can read it, how long it’s kept, where it’s backed up. HTTPS is necessary, not sufficient, and it’s irrelevant to a tool that doesn’t transmit the file at all.

Why do most free converters cap file size?

Because every megabyte you upload costs them bandwidth, storage and CPU time. The cap is where the free tier stops being affordable, which is why it usually sits between 100 MB and 1 GB and why the paid tier raises it. Tools that run in your browser don’t have that cost, so their ceiling is your device’s memory instead — gigabytes rather than megabytes.

Can a website really convert video without a server?

Yes. WebAssembly lets real compiled code — including FFmpeg, the same engine behind most desktop video tools — run at close to native speed inside a browser tab. The page delivers the program; your own processor does the work. It’s the same reason a modern browser can run a video editor or a 3D game without installing anything.

Don’t trust it — check it

Every claim in this article, including ours, is verifiable from your own machine in under a minute. Open the network tab, drop in a file, look at the largest outgoing request. Do it to us, and do it to whatever tool you were about to paste a contract into.

If you’d like something to test it on, the video compressor, converters and PDF compressor here all run entirely in your browser — free, no signup, no watermark, and now you don’t have to take our word for it.

« Older posts