Video compression can produce a file that is larger than the original, lose audio, drop subtitles, or return a clip whose duration the browser cannot read, and a single run can trigger several of these failures at once. The result depends on the source footage, the target bitrate, the browser's available codec, and how the tool captures frames in the first place. None of these failures are rare edge cases: every preset on a browser-based encoder trades size for quality in a way that varies by clip, so a setting that shrinks one video can enlarge another. A useful mental model is that compression is a negotiation between the encoder's bit budget and the unpredictability of the input, and the failure modes are simply the points where that negotiation breaks down.
The map below names each failure mode, explains why it happens, and shows how Video Compressor treats it honestly rather than hiding it behind a generic "compress" button. Reading it before you click Start will save you from deleting an original file you still need.
Where Compression Goes Wrong: A Failure Map
Most failed compression runs fall into one of these categories. Naming them up front makes it easier to recognize them when you see the output rather than chasing the wrong fix afterward.
| Failure mode | What you see | Why it happens |
|---|---|---|
| Output is larger than the source | Percentage change shows a positive number | Source already uses an efficient codec or the footage is noisy, so re-encoding at a fixed bitrate cannot shrink it |
| Audio is missing | Playback is silent | Browser did not expose a capturable audio track, or the track was not appended to the MediaRecorder stream |
| Subtitles, chapters, or color metadata gone | Player shows no captions and no chapter list | Canvas-based re-encoding draws pixels only and does not copy sidecar data, container tags, or HDR signaling |
| Codec-dependent playback | Same preset produces different file in Chrome vs Firefox vs Safari | MediaRecorder picks VP9, VP8, or generic WebM according to browser-reported support |
| Job stops or the tab freezes | No download, or recording ends early | Input exceeded 500 MiB, 5 minutes, or 3840 × 2160, decoder was missing, or the tab was closed during real-time processing |
None of these failures are bugs in the strict sense; they are predictable consequences of running an encoder inside a browser. A tool that warns you, reports actual bytes, and refuses to fake a result is more useful than one that quietly produces a file with no audio and a green checkmark.
When the Output Ends Up Larger Than the Source
Compression is not a guarantee of smaller bytes. The Video Compressor tool asks the browser for a specific bitrate between 180 kbps and 8 Mbps, then asks MediaRecorder to honor that request. If your source is already encoded at a few Mbps with H.264 or HEVC and you ask for the Quality preset, the recorder may be asked for a bitrate high enough that the WebM container and chosen codec end up writing more bytes than the input. The percentage number you see afterward is calculated from the two actual Blob sizes, and the tool never labels a larger file as a reduction.
Three source characteristics make a larger output especially likely:
- Already efficient codecs. A modern HEVC file has very little redundancy left to throw away.
- Heavy noise or grain. Random pixel variation defeats bitrate-saving heuristics and forces the encoder to spend bits on visual noise.
- Rapid motion, camera shake, or frequent scene changes. The encoder cannot reuse frames, so every frame carries full detail.
If a preset produces a file that is the same size or larger, the practical fix is to try a smaller preset, accept the result if it suits your purpose, or move to a desktop encoder with two-pass rate control for a tighter size target.
Audio, Subtitles, and Other Things That Disappear
Browser-based encoders that draw frames into a Canvas can only capture what the Canvas sees, which is pixels. Audio survives only if the browser exposes a capturable audio track on the source element and the tool appends it to the recorded stream. Subtitles, chapters, attachments, rotation tags, color metadata, and HDR signaling live outside the pixel stream and are not preserved by a Canvas pipeline. This is not a bug; it is the cost of using a browser as a transcoder rather than as a structured demuxer.
The practical consequences show up in places that are easy to miss until you play the result:
- A silent result is possible when the source uses a codec the browser cannot decode, even if the file extension looks normal.
- Sidecar subtitles, embedded captions, and chapter markers will not survive.
- Vertical video will not keep its rotation tag, so upload the file already oriented correctly.
- HDR signaling and color metadata are not preserved in the output.
Before deleting the original, play the downloaded file end to end and check both picture and sound. If any of these elements matter for your destination, verify the file there, not just on the device you compressed it on.
Browser and Codec Differences You Should Expect
Two browsers given the same preset and source file can produce WebM files of different sizes and slightly different visual quality. MediaRecorder support varies across engines, so the codec the recorder selects can differ from browser to browser. The recorder tries VP9 first, then VP8, then a generic WebM MIME, and uses the first one the current browser reports as supported, which is how the choice is documented in the MDN MediaRecorder reference. The container itself is fixed to WebM because browser-generated MP4 through MediaRecorder remains inconsistent across engines.
For most everyday uses this is invisible. It becomes important when your destination platform, player, or editing suite has a strict codec requirement. If you need a specific codec profile, two-pass encoding, fixed keyframe intervals, or deterministic cross-platform output, a maintained desktop tool with a reviewed command is the right choice. Browser re-encoding is a fast, local convenience, not a delivery-spec guarantee.
Limits, Errors, and Jobs That Stop Mid-Stream
The Video Compressor tool caps input at 500 MiB, 300 seconds, 4096 pixels on either side, and 3840 × 2160 of decoded area. These caps exist to bound memory, Canvas allocation, and the real-time work the page performs. An input that exceeds any cap, an unsupported decoder, or a Canvas stream that fails to produce frames triggers an error and no download. Nothing is silently truncated.
Real-time encoding has its own failure mode. Because MediaRecorder observes the Canvas stream while the source plays, a two-minute source takes roughly two minutes to process. Closing the tab, picking a new file, changing presets, or pressing cancel invalidates the active job and releases the temporary Object URLs the page allocated. If you need to step away, leave the tab open and use device volume if the audio bothers you, but do not assume muting has no effect on a captured track, since the source plays audibly while the recorder is running.
Choosing the wrong preset for a quiet screen-recording, picking a 4K source with no decoder, or trying to compress a long lecture all produce errors that look identical in the UI: no download appears. The fix is always the same: read the message, adjust the source or the preset, and try again.
What Each Preset Actually Does
The three presets are transparent product choices, not claims about a universal optimum. Each one preserves the source aspect ratio, never enlarges the source, and rounds output dimensions down to even pixel values for codec compatibility. The bitrate is chosen by a bounded bits-per-pixel heuristic and clamped from 180 kbps through 8 Mbps.
| Preset | Maximum width | Target frame rate | Typical use |
|---|---|---|---|
| Small | 640 px | 24 fps | Quick sharing where size matters more than detail |
| Balanced | 1280 px | 30 fps | General-purpose playback at reasonable size |
| Quality | 1920 px | 30 fps | Keep as much detail as the source allows |
None of these guarantees the output will be smaller than the source. A low-motion animation may shrink dramatically; noisy footage, an already efficient source, or aggressive motion can produce a similar or larger file.
How to Run Video Compressor Without Surprises
- Pick a browser-decodable video no larger than 500 MiB, no longer than five minutes, and no more than 3840 × 2160 of decoded area.
- Open the Video Compressor page and choose the file from your device.
- Select Small, Balanced, or Quality based on what you need: smaller for sharing, larger for keeping detail.
- Start the compression and keep the tab open while the source plays in real time; do not switch files or close the tab.
- When the run finishes, read the reported output dimensions, input and output bytes, and the measured percentage change.
- Download the WebM and play it fully, including picture, sound, and duration, before deleting the original.
If the percentage change is not what you wanted, try a different preset and compare. The reported numbers are the truth of that run, not a marketing estimate, and they reflect the actual input and output bytes that the recorder produced.
Inspecting the Result Before You Delete the Original
The most reliable way to confirm a result is to play it on the same kind of player your destination uses. A file that opens in Chrome may stall in a chat app, in an editor, or in a TV browser. Watch for visible artifacts, audio that drops out, a duration that shows as zero, and a bitrate that looks too low for the resolution. For more on the verification side, the guide on checking the result after video compression walks through the inspection steps in detail.
Keep the original until you have confirmed that the compressed file meets every requirement of where it is going. Bytes reported by the tool describe the run, not the destination's compatibility, and only a full playback test will tell you whether the negotiation actually worked.
Related reading: What the 500 MiB Limit Means in Video Compression.