Das Video wird dekodiert und mit geringerer Bitrate neu kodiert, über denselben Hardware-Videoencoder, mit dem Ihr Gerät aufnimmt. Nichts wird hochgeladen — die Datei verlässt das Gerät nie, und genau das ist der Grund, dies einem Dienst vorzuziehen, der erst den Upload verlangt. Sie wählen Auflösung und Qualität, und das geschätzte Ergebnis wird vor dem Start angezeigt.
The bitrate is worked out from the pixel count rather than fixed, because a figure that suits 1080p starves 4K and wastes bytes on 480p. A smaller resolution is never upscaled: choosing 1080p for a 720p video leaves it at 720p rather than inventing detail. Audio is re-encoded as AAC into an MP4 where the browser can write AAC; where it cannot, the result is written as WebM with Opus audio instead, which keeps the sound rather than dropping it. Only where neither is possible does the export end up silent.
Was Kompression leisten kann und was nicht
-
Die Auflösung spart mehr als die Qualität:
Die Maße zu halbieren entfernt drei Viertel der Pixel, eine weit größere Ersparnis als jede Qualitätseinstellung. Ist das Video für einen Telefonbildschirm bestimmt, sieht 720p meist identisch aus und ist ein Bruchteil der Größe.
-
Ein bereits komprimiertes Video kann größer herauskommen:
Bei einer effizient kodierten Datei bleibt wenig zu entfernen, und sie neu zu kodieren gibt Bits dafür aus, die Artefakte des ersten Durchgangs zu bewahren. Die Schätzung sagt das vor dem Start und das Ergebnis danach — behalten Sie in diesem Fall das Original.
-
A WebM result is not a downgrade:
AAC, which MP4 requires, is unavailable in Firefox on every platform and in every browser on desktop Linux. On those systems this tool writes WebM with Opus audio instead, so the sound survives — WebM plays natively in every current browser and in most players and editors, just not in some older software that only expects MP4.
-
MP4 sources encode considerably faster:
an MP4 is read frame by frame straight out of the container and handed to the decoder. Anything else — WebM, or a file the demuxer cannot parse — falls back to stepping the video through frame by frame instead, which works with any file the browser can play but is much slower. Converting an awkward source to MP4 first is often quicker overall than compressing it directly.
-
Halten Sie den Tab im Vordergrund:
browsers throttle background tabs heavily, and encoding slows to a crawl or stalls entirely. This matters most on the slower fallback path, but it is worth doing either way.
How the size estimate is actually calculated
The bitrate the [msm_tool slug="video-compressor"] targets is worked out from the pixel count of the chosen resolution rather than fixed at one number, because a bitrate that suits 1080p would starve a 4K export and waste bytes on a 480p one. Encoding runs through the same hardware video encoder the device already uses to record, and the whole job happens without the file ever leaving the machine.
Resolution is the bigger lever, not quality
Halving both dimensions of a frame removes three quarters of its pixels, a far larger saving than moving the quality setting alone can produce. A recording destined for a phone screen usually looks identical at 720p and is a fraction of the size of the same file left at its original resolution — the quality slider is worth adjusting after the resolution, not instead of it.
It never upscales
Choosing a target resolution larger than the source does not invent missing detail; the output is simply left at whatever resolution the source actually was. The setting is a ceiling, not a promise.
An already-compressed file can come out bigger
A video that was efficiently encoded the first time has little redundancy left to strip out, and re-encoding it spends bits reproducing the artefacts already baked into that first pass rather than removing anything meaningful. Where that is likely, the estimate says so before the run starts, and the result confirms it afterwards — the original is usually the better file to keep in that case.
Which setting is actually worth choosing
For sharing or posting to the web, 1080p at a balanced quality covers almost everything without a visible trade-off. For a phone screen or a messaging app, 720p is usually indistinguishable from the original and considerably smaller again — most video is never watched at a size where the difference would register. The smallest-file setting is worth reaching for only when a hard size limit forces it, since it is the point where the saving starts to cost visible quality.
Where sound needs a different container
Audio is re-encoded as AAC into the MP4 wherever the browser can write AAC. Firefox cannot, on any platform, and no browser can on desktop Linux — a limitation of those browsers, not of this tool. Rather than deliver a silent MP4 on those systems, the export switches to WebM with Opus audio instead, which keeps the sound. WebM plays natively in every current browser and in most media players and editors; the only real cost is a file that says .webm rather than .mp4, which some older software that only expects MP4 will not open. The page says which format was used before you download.
Why MP4 sources finish sooner
An MP4 is read directly: the frames are pulled out of the container and handed to the decoder in sequence, so no individual frame costs anything beyond decoding it. Anything the demuxer cannot read — a WebM source, or an unusual MP4 variant — falls back to stepping the video element to each frame in turn and capturing it, which works with any file the browser can play but pays a seek for every single frame. If a source is slow to process, converting it to MP4 first and then compressing is often quicker than compressing it directly.
Keep the tab in front
Browsers throttle background tabs heavily, and an encode running behind another window slows down or stalls outright. This matters most on the slower fallback path, where each frame is already waiting on the video element, but it is worth doing whichever path a file takes.