Video-Kompressor

The output can exceed your expectations when the compression settings are less aggressive than the source file already is. The tool re-encodes your video by playing it through a hidden video element, drawing each frame to a canvas, and feeding canvas.captureStream() into MediaRecorder at one of three bitrate targets: 600 Kbps for Low, 1.5 Mbps for Medium, and 4 Mbps for High quality. If your source is a screen recording at 800 Kbps or a heavily compressed social-media clip already at 500 Kbps, selecting High quality will produce an output with a higher bitrate than the input, resulting in a larger file. The re-encoding process also adds container overhead. The output is WebM with VP9 and Opus when supported, or MP4 with H.264 and AAC as a fallback. Neither container adds significant overhead, but the codec's keyframe interval and variable bitrate behavior can push individual files above the nominal target. To actually reduce size below the source, always select Low or Medium quality when the source was recorded at high bitrate. For screen recordings or lecture videos with limited motion, Low quality at 480p frequently achieves 80 to 90 percent size reduction with no perceptible quality loss. Practical tip: check the source file size before compressing and pick a quality preset with a lower bitrate target than the source — the tool displays source resolution and estimates output size after the video loads.

The tool can process long recordings, but a two-hour file introduces practical constraints you should understand before starting. The compression pipeline plays the source video in real time through a hidden video element while MediaRecorder captures the stream. A 2-hour video therefore takes approximately 2 hours of wall-clock time to encode. The browser tab must remain active and in focus throughout because browser throttling reduces video playback speed for background tabs in most Chromium-based browsers and Firefox. Closing the tab or letting the device sleep will interrupt the session. Memory is a more immediate constraint. The raw source file is held in browser memory as an object URL for the duration of the session. A 2-hour recording at a typical 5 Mbps source bitrate is approximately 4.5 GB. Chrome allocates per-tab memory budgets in the 2 to 4 GB range on most desktop systems. Files above 2 GB may trigger an out-of-memory error during decoding or mid-encoding. The best approach for long recordings is to split them first using the Video Trimmer tool, compress each segment separately, and then use a local tool like FFmpeg or Handbrake to merge the segments if needed. All processing stays in your browser — nothing is uploaded. Practical tip: for files above 1 GB, test with a 10-minute segment first to confirm the browser handles your specific codec and resolution before committing to a full-length encode.

Firefox supports MP4 output through MediaRecorder but only when the underlying platform provides a hardware or OS-level H.264 encoder. The tool probes MediaRecorder.isTypeSupported() at startup, checking candidates in order: MP4 with AVC1 and AAC, then WebM with VP9 and Opus, then WebM with VP8, and finally plain WebM. On Windows, Firefox can access the Media Foundation H.264 encoder via the Windows media pipeline, which means MP4 output is usually available. On Linux, H.264 hardware encoder access through Firefox depends on the distribution and the installed GStreamer plugins. On macOS, Firefox can access VideoToolbox for H.264, but support varies by macOS and Firefox version. When the tool detects that MP4 is not supported, it falls back automatically to WebM. WebM with VP9 is an excellent codec — it achieves comparable quality to H.264 at the same bitrate — but some video editors, social media platforms, and corporate media systems do not accept WebM natively. If you need guaranteed MP4 output, Chrome on Windows or macOS is the most reliable choice. Both ship with platform H.264 encoders that MediaRecorder can access. Chromium-based browsers on Linux also benefit from hardware encoder access if VA-API is enabled. Practical tip: if Firefox produces a WebM file but you need MP4, open the output in a second browser tab using the HTML-to-MP4 tool, or use a local tool like FFmpeg to remux the WebM container to MP4 without re-encoding.

Audio quality impact during video compression is usually minimal but not zero. The pipeline captures audio through canvas.captureStream() combined with the source video's audio track and feeds both into MediaRecorder. When the output is WebM, the audio is encoded with the Opus codec. Opus is a modern perceptual codec that achieves excellent intelligibility and musical fidelity at 64 to 96 Kbps, which is the default bitrate MediaRecorder applies. At this range, differences are inaudible on speech and lightly compressed music. When the output is MP4, the audio uses AAC at a comparable rate. Problems arise when the source audio was already highly compressed — MP3 or AAC at 128 Kbps or lower — and a second encoding cycle is applied. Each lossy re-encode introduces generation loss: the artifacts from the first compression become inputs to the second encoder, which cannot distinguish them from real signal. The effect is most audible on high-frequency content like cymbals, sibilant speech, and synthesizer pads. If audio fidelity is critical — for podcast production, music videos, or voiceover delivery — extract the audio track first using the Video Audio Extractor to get a lossless WAV, compress the video without audio using the Muted option, and reassemble locally with FFmpeg. Practical tip: toggle the Mute Audio option when compressing videos intended for silent playback in banners, loops, or background visuals — this eliminates audio encoding entirely and slightly improves the video bitrate budget.