Three weeks ago we ran six popular video-to-audio converters through the same file and published what came back. That round left a gap: Google’s first page for “extract audio from video” and “convert video to audio” is full of tools we had not touched, including Adobe Express, Restream, Biteable, Flonnect and the 123apps pair. So here is round two: eight more tools, the same 158 MB video, the same measurements, and one new wrinkle. Three of the eight now do the job inside your browser without uploading anything, and they turned out to be the three fastest.

Disclosure: this blog is published by RedPanda Compress, which is one of the tools in the table. It went through the same procedure as the others and its numbers are reported the same way.

The short answer

• Fast, and nothing leaves your computer: RedPanda Compress takes about 4 seconds, followed by Flonnect at 14 seconds and Biteable at 33 seconds. All three extract the audio in the browser. Every tool that uploads took between a minute and a half and nine minutes for the same file, almost all of it upload time.
• Best default MP3 quality among the upload tools: Restream, with a 237 kbps variable-bitrate file that kept all of the original’s treble. It did, however, clip two-thirds of a second off the end.
• Watch the defaults: four of the eight hand you a 128 kbps MP3 unless you change a setting, and all four measurably thinned the top of the sound. The two 123apps sites (Online Audio Converter and Audio-Extractor.net) also quietly resample 48 kHz audio down to 44.1 kHz.
• Did not finish: Adobe Express never produced a file in three attempts.

How we tested

The file: the same one as round one, Big Buck Bunny (CC-BY, Blender Foundation), 9 min 56 s, 158.6 MB, with a 130 kbps AAC stereo soundtrack at 48 kHz. Anyone can download it and repeat the test.

Which tools: everything on Google’s first page (US, 11 October 2026) for “video to audio converter”, “extract audio from video online” and “convert video to audio” that round one had not already covered. We left out app-store listings, sites built around pasting a YouTube link, and tools that will not let you export without creating an account (Canva, VEED and CapCut all fall into that last group).

What we measured: time from picking the file to the download being offered, with upload and processing separated where the tool shows both; the format, bitrate, sample rate and length of the file that came back; whether anything was uploaded, by watching every request the page made; and treble retention, measured as how much energy above 15 kHz survived compared with the original soundtrack. Within a few tenths of a decibel is a clean copy; a full decibel is audible detail gone. Every tool ran at its defaults.

Setup: an 8-core Apple Silicon Mac, Chrome, roughly 15 Mbps upload. Upload times depend on your own connection, so treat them as a shape rather than a promise.

Results

Tool	Uploads your video?	Time	Output (default)	Treble kept*	Notes
RedPanda Compress	No, runs in browser	4 s	MP3 192 kbps, 48 kHz, 14.3 MB	−0.05 dB	No limits; see engineering note
Flonnect	No, runs in browser	14 s	MP3 320 kbps, 48 kHz, 23.9 MB	+0.03 dB	Biggest file of the test
Biteable	No, runs in browser	33 s	MP3 ~178 kbps VBR, 48 kHz, 13.2 MB	+0.12 dB	500 MB limit
Audio-Extractor.net (123apps)	Yes	1 min 35 s	MP3 128 kbps, 44.1 kHz, 9.5 MB	−1.04 dB	Resampled; same backend as Online Audio Converter
Restream	Yes	1 min 36 s	MP3 237 kbps VBR, 48 kHz, 17.6 MB	+0.08 dB	Output 0.65 s shorter than the source
online-convert.com	Yes	1 min 45 s	MP3 128 kbps, 48 kHz, 9.5 MB	−0.58 dB	Default is labelled “keep original bitrate”
Online Audio Converter (123apps)	Yes	2 min 55 s	MP3 128 kbps, 44.1 kHz, 9.5 MB	−1.04 dB	Resampled; quality slider defaults to “Standard”
OnlineConverter.com	Yes	9 min 8 s	MP3 128 kbps, 48 kHz, 9.5 MB	−0.37 dB	200 MB limit; slowest upload
Adobe Express	Unknown	Did not finish	—	—	Three attempts, no file

*Energy above 15 kHz compared with the original soundtrack; closer to zero is better. Small positive numbers are measurement noise, not added detail. RedPanda’s timing and treble measurement are from a clean re-run of the updated converter; the other results are from the original comparison session. In-browser times depend on machine load: Biteable took 7–10 seconds in a separate clean re-run, so the timings are not a controlled speed ranking.

The big change since round one: converters that never upload

In September, RedPanda Compress was the only tool in the test that processed the file locally. This time there are three. Flonnect’s media tools and Biteable’s audio extractor both do the work inside the browser tab with WebAssembly, and both say so on the page. Biteable even warns that a large file “may run out of memory on a phone”, which is the honest trade-off of doing the work on your own device instead of a server.

The practical effect is on the clock. The whole-file upload is the slow part of every server-side converter, and these three skip it. On our connection the upload alone cost between 45 seconds and nearly nine minutes; the three local tools finished in seconds, with RedPanda taking about 4 seconds. On a slower or metered connection the gap gets wider. The second effect is privacy: we watched every network request from each page while it worked, and none of the three sent the video anywhere. For a recording of a meeting, a lecture or a family video, that is the difference between converting a file and handing it to a stranger. If you want to check this for yourself on any tool, we wrote up the method in Are online file converters safe?

What the defaults actually give you

Every tool here can make an MP3. The file you get without touching any settings is a different story, and the spread is wide: from 128 kbps to 320 kbps for the same source.

128 kbps is the most common default, and it costs you something. Four of the eight tools, including both 123apps sites, online-convert.com and OnlineConverter.com, encode at 128 kbps unless you change a setting. All four measurably trimmed the top octave; the 123apps pair lost about a decibel above 15 kHz, the most of anything we tested, and both also resampled the 48 kHz track to 44.1 kHz without saying so. For a podcast or a lecture you may never notice. For music it is the difference between “fine” and “slightly dull”, and it is avoidable by moving a slider.

320 kbps is the other extreme, and it is mostly wasted. Flonnect’s default produced a 23.9 MB file from a soundtrack that only contained 9.8 MB of AAC data to begin with. An MP3 cannot contain more detail than the audio it was made from, so the extra megabytes buy nothing; they just make the file two and a half times larger than it needs to be. Flonnect’s quality was perfect, which is exactly what you would expect at that bitrate, but 192 kbps would have been just as perfect at 60 percent of the size.

The middle is where the sensible defaults live. Restream (237 kbps variable), RedPanda Compress (192 kbps) and Biteable (around 178 kbps variable) all kept the treble intact and produced files between 13 and 18 MB. Any of those is a reasonable file to keep.

Tool by tool

Flonnect: fast, but the file is bigger than it needs to be

Flonnect’s extractor finished our 10-minute video in 14 seconds, entirely in the browser, and the output was a textbook 320 kbps LAME-encoded MP3 at 48 kHz with nothing missing. It offers WAV and AAC as well, and notes that audio will be copied without re-encoding “when possible”; in our test the AAC option did not copy the original AAC track but re-encoded it at 184 kbps, so that promise did not apply to the most common case. The only knock is the default bitrate, which more than doubles the size of the audio you started with. If you are sending the file anywhere, pick a lower rate. One small oddity: the page’s preview player never loaded our file, but the extraction itself worked without it.

Biteable: local, quick, and honest about its limits

Biteable’s tool also runs in the browser, took 33 seconds, and produced a clean variable-bitrate MP3 averaging about 178 kbps. It caps files at 500 MB and tells you up front that big files can be slow on a phone. There is a trim control if you only want part of the audio, and no account is needed.

RedPanda Compress: starts the moment you pick the file

Our own MP4 to MP3 converter began encoding as soon as the file was selected and offered the download about 4 seconds later: a 192 kbps MP3 at the original 48 kHz, with no measurable treble loss and no upload. The engineering note below explains how parallel encoding makes this possible. There are no size or length limits because the file never leaves your device; a two-hour recording just takes proportionally longer. As in round one, the audio converter can also lift the original AAC track straight out of the video as an M4A in a couple of seconds, with no re-encoding at all, which is still the best option if your destination plays M4A.

Restream: the best upload-based default, with a trimmed ending

Restream’s audio extractor needed no sign-up, uploaded our file in about 45 seconds and had the MP3 ready about 50 seconds after that. The output was the highest-quality server-side result in the test: a 237 kbps variable-bitrate MP3 that kept every bit of the treble. The one thing to know is that the file came back 0.65 seconds shorter than the video. For a lecture that is nothing; for a song that ends on a held note, check the last second before you delete the original.

Online Audio Converter and Audio-Extractor.net: the same engine twice

Both sites belong to 123apps and both returned exactly the same file, byte for byte: a 128 kbps MP3 resampled from 48 kHz to 44.1 kHz, with the biggest treble loss of the round. Online Audio Converter has a quality slider whose default is “Standard 128 kbps”; drag it to “Good” or “Best” before you convert. Audio-Extractor.net has no quality control at all for MP3. Both upload the whole video first; the slower of the two took almost three minutes on our connection, the faster about a minute and a half, and the difference appeared to be which upload server each page picked.

online-convert.com: “keep original bitrate” does not mean what it says

online-convert.com’s MP3 page selects “Keep original bitrate” by default, which sounds like the safe choice. The file that came back was a 128 kbps constant-bitrate MP3, a step down from the 130 kbps source and with a measurable half-decibel of treble gone. The site exposes a full set of variable and constant bitrate options if you open the optional settings, and the upload itself finished in under two minutes. Pick a bitrate explicitly and it is a fine tool.

OnlineConverter.com: nine minutes, a 200 MB cap, and a decoy button

OnlineConverter.com produced a perfectly usable 128 kbps MP3 at 48 kHz, with less treble loss than the other 128 kbps tools. Getting it took just over nine minutes, nearly all of it a slow upload to the site’s server. Files are capped at 200 MB, which rules out most phone videos longer than a few minutes. Be careful on the page itself: a large green “DOWNLOAD” button sits right next to the real form, and it installs a browser extension, not your file. The real controls are the small grey ones.

Adobe Express: three attempts, no file

Adobe’s free MP4 to MP3 page accepted our video and showed its editing panel, then stalled with a five-second placeholder in the player and the Download button greyed out. We tried the full 158 MB file twice and a 29 MB clip once, waiting a minute or more each time, and never got past that screen. The page advertises a 1 GB limit, so size should not have been the problem. We drove the page by script rather than by hand, so it is possible a human clicking through would fare better; we are reporting what we saw.

What to check before you convert

1. Does it upload? If the page shows an upload progress bar, your video is going to someone’s server. For anything private, use a tool that runs locally.
2. What bitrate is the default? 128 kbps is common and audibly softer on music. 160 to 192 kbps is the sweet spot for a file you will keep; 320 kbps only makes sense if the source itself was that good.
3. Do you need MP3 at all? The audio inside an MP4 is usually AAC. Copying it out as M4A takes seconds and loses nothing. Only convert to MP3 for a player or platform that demands it.
4. Check the length. One tool in this round trimmed the end. Compare the duration of the MP3 with the video before you throw the original away.

Engineering note: how we made MP3 extraction faster

Profiling our own converter on this file showed where the time went: decoding the AAC track took about a second, and most of the remaining work was MP3 encoding. We run LAME, compiled to WebAssembly. Two changes made it faster. First, we set its encoding effort to LAME’s own command-line default, using ffmpeg’s -compression_level 5. In the worker benchmark this reduced encoding time from 8.3 to 6.9 seconds without a measurable change in treble retention. Second, and more importantly, LAME is single-threaded, so we split the track into independent slices and encode them in parallel. The eight-core test machine used four workers; the converter caps this at four and reduces the count on devices with less memory or fewer cores. Each cut sits on the 1,152-sample MP3 frame grid, with three extra frames on either side to give the encoder context. We disable the bit reservoir so a kept frame never depends on bytes in a discarded frame, trim the extra frames, join the results, and repair the Xing/LAME header so duration, seeking and gapless playback remain correct. Validation confirmed the expected decoded sample count and a treble-energy difference of only −0.05 dB from the source.

On the test file, end-to-end conversion fell from 9–12 seconds with a single worker to 3.6–4.2 seconds with parallel encoding, which we round to 4 seconds in the table. The parallel path handles MP3 encoding for inputs at least 30 seconds long at 32, 44.1 or 48 kHz when the device has enough cores and memory. Any worker error, stall or short slice sends the job back to the single-worker path automatically. We also tried a SIMD build of the encoder; its extra speed was too small to justify a larger download and an additional compatibility path, so we left it out.

Frequently asked questions

What is the best free tool to extract audio from a video?

For speed and privacy, one of the three that run in your browser: Flonnect, Biteable or RedPanda Compress. All three finished our 10-minute, 158 MB test in under 40 seconds without uploading it. If you prefer a server-side tool, Restream had the best default quality in this round, and CloudConvert had it in round one.

Does extracting audio from a video lose quality?

Converting to MP3 always re-encodes, and at 128 kbps the loss is measurable: every 128 kbps tool here trimmed the top of the sound. At 192 kbps or above the loss was below what our measurement could detect. Copying the original AAC track out as an M4A loses nothing at all.

Why is the MP3 bigger than the audio in the video?

Because the tool encoded at a higher bitrate than the source. Our video carried 130 kbps of audio; a 320 kbps MP3 of it is 2.4 times larger with no extra detail to show for it. Pick a bitrate close to or a little above the source.

Can I extract audio from a video on my phone without uploading it?

Yes, the in-browser tools work on phones too, but they do the encoding on the phone’s own processor and memory, so a long video takes longer and a very large one can fail. Biteable says so on its page; the same applies to the others. For a long recording, a laptop is the comfortable choice.

Conclusion

The headline from round two is that the “upload it and wait” model is no longer the only way to get audio out of a video online. Three of the eight tools do it locally, in well under a minute, with nothing sent anywhere, and the quality of their output was as good as or better than the upload-based tools at their defaults. Beyond that, the lesson from round one still holds: the default bitrate decides what you get far more than the brand on the page. If you want to try the local route, RedPanda Compress converts MP4 to MP3 in your browser, keeps the file on your device, and has no size limit.

A growing number of video compressors promise that your file never leaves your computer. Instead of uploading the video to a server, they compress it inside the browser tab. That’s good for privacy and it means no upload wait, but “runs in your browser” covers some very different technology. We ran the same video through the four in-browser compressors that actually get search traffic and measured what came back.

Disclosure: this blog is published by RedPanda Compress, which is one of the four tools tested. It went through the same procedure as everyone else, and we report where it lost.

The short answer

• Best quality for a given file size: RedPanda Compress. It hit our 50 MB target exactly with a VMAF score of 84.0. The only tool that matched that quality needed a file 77% larger. The catch: it took 3 min 42 s, five to six times longer than the others.
• Fastest with a size target: VidShift. 44 seconds to a 50 MB file, but at that size it scored lowest of the group (VMAF 74.1), a difference you can see.
• Fastest overall, best looking presets: OpenReplay. 35 seconds and good quality, but no size control: its smallest setting still produced an 88 MB file.
• Kommodo is just as fast and has resolution options, but it also has no size control, and its presets compressed less than they promise.

Two ways to compress video in a browser

All four tools keep the video on your device, but they encode it in one of two ways, and that choice explains almost every result below.

Hardware encoding (WebCodecs). VidShift, OpenReplay and Kommodo use WebCodecs, a browser feature that hands the video to the hardware encoder built into your computer’s graphics chip. Those encoders are designed for real-time jobs like video calls and screen recording. They are very fast, but they make simpler decisions about where to spend bits, so at the same file size they lose more detail. They also depend on what your browser and hardware support.

Software encoding (FFmpeg compiled to WebAssembly). RedPanda Compress runs FFmpeg with the x264 encoder inside the page, on your CPU. x264 is the same encoder used by most server-side compressors. It analyses each frame much more thoroughly, which costs time but gets more quality out of every megabyte. On a desktop computer it works the same in any modern browser because it doesn’t depend on the graphics chip. We explain the engine in more detail in how an in-browser converter actually works.

A note on RedPanda Compress on phones. Everything in this test ran on a desktop computer, where RedPanda Compress always uses the software encoder described above. On phones and tablets it also uses WebCodecs hardware encoding when the device supports it, because software x264 on a phone’s CPU would be slow and hard on the battery. It always does this for large files (200 MB and up) and for many smaller ones too, and if the hardware path fails on a particular file, it falls back to the software encoder. So on mobile, the speed-versus-quality trade-off in this article works in favour of speed.

How we tested

• Test file: Big Buck Bunny (Blender Foundation, CC-BY), the same file as our online video compressor comparison: 1280×720 at 24 fps, 9 min 56 s, H.264 + AAC, 158.6 MB. It’s openly licensed, so you can repeat the test yourself.
• Goal: about 50 MB, roughly a third of the original. If a tool accepts a target size, we typed 50 MB. If it only has presets, we ran its default and the preset closest to 50 MB.
• Tools: in-browser compressors with real search traffic (US organic visits per month, October 2026): VidShift (~18.7K), OpenReplay (~12.1K), Kommodo (~3.7K) and RedPanda Compress. The rest of the category gets close to zero visits, so we left it out.
• Time: from clicking the compress button to the finished file being ready.
• Quality: VMAF, Netflix’s open-source perceptual quality metric (0–100), comparing every frame of the output with the original. Roughly, a 2-point gap is hard to see and 6 or more is clearly visible.
• Upload check: we logged the size of every request each page made while compressing. None of the four sent anything over 1 MB, so all four do what they say: the video stays on your device.
• Machine: Apple M2 MacBook (8 cores, 16 GB), Chrome 154, plugged in, one tool at a time.

Results

Tool and setting	Engine	Time	Output	VMAF
RedPanda Compress target 50 MB	x264 (CPU)	3 min 42 s	49.9 MB	84.0
VidShift custom 50 MB	WebCodecs (GPU)	44 s	50.3 MB	74.1
Kommodo Low, smallest preset	WebCodecs (GPU)	35 s	62.7 MB	78.5
OpenReplay Low, smallest preset	WebCodecs (GPU)	35 s	88.4 MB	85.2
Kommodo Medium, default	WebCodecs (GPU)	40 s	115.4 MB	90.3
OpenReplay Medium, default	WebCodecs (GPU)	35 s	134.4 MB	91.7

All outputs stayed at 1280×720 and 24 fps and played as standard H.264 MP4s, with no watermarks. We ran RedPanda twice in different browser profiles (3 min 42 s and about 3 min 45 s, same size and score) and VidShift twice (42 and 46 s).

The table reads two ways. Sorted by speed, the hardware encoders win easily: 35–44 seconds against almost four minutes. Sorted by what you get per megabyte, it flips. OpenReplay needed 88 MB to slightly beat the quality RedPanda delivered at 50 MB, and VidShift, at the same 50 MB, was 10 VMAF points behind.

Averages can hide the bad moments, so we also counted the frames scoring below 70, roughly where damage becomes easy to spot. RedPanda: 8.8% of frames. OpenReplay (Low, 88 MB): 8.5%. Kommodo (Low): 21%. VidShift: 32%, about one frame in three.

Why the results look like this

To understand the gaps, we read each tool’s own page code to see what it asks the encoder for, and we looked inside every output file to see how the encoder actually built it. Three things explain almost everything.

	RedPanda	VidShift	Kommodo	OpenReplay
Encoder	x264, software (CPU)	Hardware, via WebCodecs	Hardware, via WebCodecs	Hardware, via WebCodecs
How the bitrate is chosen	From the size you type	From the size you type	Fixed per preset and resolution	Fixed per preset and resolution
B-frames (share of frames)	67%	none	none	none
Full keyframe every	~5.6 s, placed at scene cuts	5 s	2 s	2 s
Frames encoded per second	~65	~325	~410	~410

Frame structure measured on the first two minutes of each ~50–90 MB output. Frames per second = 14,315 frames ÷ total time.

1. The hardware encoders skip B-frames

Most frames in a compressed video are stored as differences from other frames. P-frames borrow only from frames before them; B-frames can borrow from frames before and after, which usually makes them far cheaper. In RedPanda’s file, two out of three frames are B-frames, averaging about 1 KB each. The three hardware-encoded files contain no B-frames at all, so every frame is a P-frame costing 2.6–4.2 KB. With the same 50 MB budget, the software encoder has more bits left over for the frames that matter.

2. Keyframes are expensive, and two tools insert one every two seconds

A keyframe is a complete picture that doesn’t borrow from anything, so it’s many times bigger than the frames around it. Kommodo and OpenReplay start a new keyframe every 2 seconds, which takes about 20% of their bit budget. RedPanda’s encoder places keyframes mostly where the scene actually changes, about every 5.6 seconds on this film, and spends around 17% on them.

3. Software encoding plans ahead; hardware encoding works frame by frame

x264 looks 20 frames ahead before deciding how to spend bits, and gives more detail to parts of the picture that later frames will reuse, so the effort is spent once and repaid many times. It also tries several ways of predicting each block before picking one. The video encoders built into graphics chips are designed mainly for real-time jobs like video calls and screen recording, where there’s no time to look ahead. That makes them five to six times faster here, but at the same size they keep less detail, and the loss concentrates in busy scenes like grass and leaves.

The flip side explains RedPanda’s speed. All that analysis is real work, and in a browser it runs as WebAssembly on your CPU. That’s much faster than it used to be, with multiple threads and SIMD instructions, but it still can’t use the hand-tuned assembly code x264 relies on in desktop apps, and decoding the input happens in software too. The hardware tools can hand both decoding and encoding to the chip’s dedicated video circuits.

How each tool works, and where its problems come from

RedPanda Compress

How it works: on a desktop computer, it runs FFmpeg, compiled to WebAssembly, in your browser tab and encodes with x264. You type a size, and it works out the bitrate that fits: (50 MB − the audio) ÷ the video’s length gave 541 kbps here. It then asks x264 for that bitrate at a steady rate, with a few seconds of buffer so busy scenes can borrow from quiet ones.

Strengths: the best quality per megabyte in this test, and the size you type is the size you get (49.9 MB for a 50 MB target), which matters when an email, app or upload form has a hard limit. On desktop it doesn’t need WebCodecs or a particular graphics chip and accepts files up to 8 GB, and on phones it switches to hardware encoding where the device supports it. The output is always plain H.264 MP4.

Weaknesses, and why: it’s the slowest by far, 3 min 42 s on this file, about 2.7× faster than real time. That’s the cost of software encoding described above: x264’s analysis running as WebAssembly on the CPU. It also keeps the CPU busy for the whole job, so a laptop’s fans will spin up, and older or lower-power computers will take noticeably longer. (On phones, where this would hurt most, it uses the hardware encoder instead, as described above.)

VidShift

How it works: it uses Mediabunny, an open-source library, to drive the browser’s WebCodecs hardware encoder. For a custom size, it computes a bitrate aimed at 97% of your target, as a safety margin, and asks the hardware encoder for a constant bitrate. Its presets are fractions of the source’s own bitrate (70%, 40% or 20%).

Strengths: the only hardware-based tool here that takes a target size, and it lands close (50.3 MB for 50 MB). It’s fast (44 s) and the most-visited tool in this group.

Weaknesses, and why: at the same 50 MB it scored lowest (VMAF 74.1), and about one frame in three fell below 70. Constant bitrate is what makes the size predictable, but it also means a busy scene gets no more bits than a still one. Combined with the hardware encoder’s lack of B-frames and look-ahead, the busy scenes are where it breaks up (see the second image above). It also came out slightly over target, by about 0.5%, so for a hard limit, type a little less than the limit.

OpenReplay

How it works: WebCodecs hardware encoding in a background worker. Its quality presets don’t look at file size at all. The bitrate is a fixed formula of the output resolution: width × height × 30 × 0.045 for Low, 0.075 for Medium and 0.12 for High, capped at 95% of the source’s bitrate. At 720p that’s 1.24 Mbps for Low and, after the cap, 2.02 Mbps for Medium. It asks for that as a variable bitrate.

Strengths: the fastest tool (35 s) and the best-looking files, because its presets are generous. Medium scored 91.7.

Weaknesses, and why: since the bitrate comes from the resolution, not from a size you choose, it can’t target a size. Low will always be about 1.2 Mbps at 720p, so a 10-minute video can’t go below ~88 MB unless you lower the resolution. On our file, Medium asked for 95% of the source’s bitrate, so it barely compresses. Nearly all of the 15% it saved came from the hardware encoder delivering about 20% less than it was asked for (Kommodo’s files came in 20% under in exactly the same way). The page’s size estimate, about 153 MB, matches what Medium requests rather than what the encoder delivered, and it didn’t change when we switched quality levels. Separately, the audio came out at about 189 kbps, higher than both the source (~130 kbps) and the 128 kbps its code requests.

Kommodo

How it works: it also uses Mediabunny and the WebCodecs hardware encoder (the page shows “Encoder: AVC (Hardware)”). Each preset is a fixed bitrate for 1080p (8, 4 or 2 Mbps for High, Medium and Low), scaled down by pixel count for smaller resolutions: 1.78 Mbps for Medium and 0.89 Mbps for Low at 720p. It’s capped just below the source’s own bitrate and requested as a variable bitrate.

Strengths: fast (35–40 s), simple, and it lets you pick a lower resolution, the most effective way to shrink a file if you can accept fewer pixels.

Weaknesses, and why: no target size, and the labels (“~50%”, “~70% compression”) are fixed text that doesn’t depend on your video. Because the bitrate is fixed per resolution, the saving depends entirely on how big the source already was. Our 720p source was 2.1 Mbps, so Medium’s 1.78 Mbps saved only 27%, and Low saved about 60%. On a typical phone video, recorded at a much higher bitrate, the same presets would save more than the labels say. Like OpenReplay, the hardware encoder delivered about 20% under the requested bitrate, and a keyframe every 2 seconds eats into the budget, which is why Low’s 62.7 MB looked worse (78.5) than RedPanda’s 50 MB. Its FAQ also says it doesn’t work on iPhone, because Safari’s WebCodecs support is limited.

Which one should you use?

If you need…	Use
To get under a hard size limit (email, Discord, a form) with the best quality	RedPanda Compress
A size target, and speed matters more than detail	VidShift
A modest reduction with almost no visible loss, fast	OpenReplay (Medium) or Kommodo (Medium)

For short clips the speed gap matters less in absolute terms: RedPanda processed this 720p film at about 2.7× real time, so a one-minute 720p clip takes around 20–25 seconds on a machine like ours, against a few seconds for the hardware tools. It matters most with long recordings. If the file is going somewhere with a size limit, though, quality per megabyte is the number that decides how good it looks when it gets there.

FAQ

Can I compress a video online without uploading it?

Yes. All four tools in this test compress the video inside your browser tab, and we confirmed none of them sent the file anywhere. You can check any tool yourself with your browser’s developer tools; we show how in Are Online File Converters Safe?

Why are in-browser compressors so different in speed?

It comes down to the encoder. Tools built on WebCodecs use the hardware video encoder in your computer’s graphics chip, which is fast but less efficient. Tools built on FFmpeg/WebAssembly run a software encoder on your CPU, which is slower but squeezes more quality into each megabyte.

Are in-browser compressors worse than server-based ones?

Not necessarily. In our comparison of upload-based compressors, the best server tool scored 85.3 at about 48 MB, close to RedPanda’s 84.0 at 50 MB, but it required uploading the whole file first. The hardware-encoding browser tools trade some quality for speed instead.

Will these results be the same on my computer?

The quality and size numbers should be very close, because they come from the encoders’ settings. The times will vary: software encoding scales with your CPU, and hardware encoding depends on your graphics chip and browser. On an older laptop, expect all of them to be slower, and the software encoder more so.

The bottom line

Every tool here keeps your video private. The real choice is between speed and quality per megabyte. If you need a file to fit under a limit and still look good, try RedPanda Compress: type the size you need and it compresses the video on your own device, with no upload, no watermark, and a standard H.264 MP4 at the end. If you just want a quick, moderate reduction, the hardware-based tools will get you there in under a minute.