What the browser can do without FFmpeg

For twenty years the answer to “how do I process video?” has been FFmpeg, and for most of that time the browser’s contribution was playing the result. That has changed. A page you are reading can decode your video, hand every frame to the same hardware encoder your operating system uses, and give you back a smaller file, without the bytes leaving your machine.

It has not changed completely, though, and most writing on the subject either oversells the browser or ignores it. This page is the honest map. Every claim in the first two sections runs live on this site, so you can check them against your own files rather than taking our word.

What the browser does natively

WebCodecs exposes the platform’s real decoders and encoders to JavaScript: the same silicon your screen recorder and video calls use. On top of it, a small library like Mediabunny handles the part FFmpeg calls demuxing and muxing: reading MP4, WebM, MKV or WAV, and writing them back.

That combination covers, natively:

• Transcoding. Decode anything the browser plays, re-encode to H.264, H.265, VP9 or AV1, subject to which encoders the machine provides. This is the transcode lab.
• Quality control. A fixed quantizer per frame, the raw knob underneath CRF. Not CRF itself; more on that below.
• Resizing, cropping, rotating. Declared once on the conversion, applied during the decode-encode pass.
• Trimming. Frame-accurate, via a re-encode. The one caveat is instructive: FFmpeg’s -c copy trick of slicing compressed packets without re-encoding only works in the browser when the cut starts at the top of the file, because a mid-file start would need the keyframe bookkeeping FFmpeg does and browser pipelines do not.
• Stream copy. When the source codec already fits the target container and nothing else changes, the compressed data passes through bit for bit. Remuxing MKV to MP4 takes about as long as reading the file.
• Audio. Extract, re-encode to Opus or AAC, resample, remix channels, or write plain PCM into a WAV.
• Per-frame pixel work. Any frame can be drawn to a canvas between decode and encode, which turns “filters” into ordinary drawing code: watermarks, crops, colour fades, picture-in-picture.

Every how-to page on this site now ends with a panel that runs the page’s own settings on a file you drop in. That panel is this list, executed.

What the browser can fake convincingly

The canvas hook is more powerful than it first looks. FFmpeg’s overlay, fade, hue, eq and drawtext filters are, at heart, per-frame pixel arithmetic, and a 2D canvas does per-frame pixel arithmetic at hardware speed. The watermark how-to composites a logo with the same placement maths as overlay=W-w-M:H-h-M, just written in JavaScript.

The difference is not capability but vocabulary: FFmpeg ships four hundred filters as one-line incantations; the browser makes you write the loop. For one effect that is ten lines. For a colour pipeline it is a project.

What still needs FFmpeg

Be suspicious of anyone who says the browser replaces FFmpeg. These do not have a browser-native answer in 2026:

• CRF and the smart rate controls. WebCodecs accepts a bitrate or a fixed quantizer. The perceptual adaptation that makes CRF spend bits where your eye needs them lives inside x264 and x265, not inside the platform encoders. The quantizer lab exists precisely to show what the raw knob does.
• MP3 encoding. Decoding is universal; encoding never made it into any browser. Opus and AAC did.
• Encoder tuning. No presets, no tune grain, no psy-rd. The platform encoder’s speed-quality trade-off is whatever the vendor chose.
• The deep filter library. Motion-compensated denoising (hqdn3d, nlmeans), stabilisation (vidstab), scene detection, loudness normalisation to broadcast spec (loudnorm), palette-optimised GIF generation. Reimplementing any one of these well is a research project.
• Subtitles. Burning in an .ass file with correct styling is a rendering engine (libass); no canvas one-liner approximates it.
• Anything at scale. A browser tab is one user’s machine. A thousand files want a server, and the server wants FFmpeg.

There is a wasm escape hatch: FFmpeg itself compiled to WebAssembly runs in a tab. It also weighs about 31 MB before your file starts processing and runs on one CPU thread, an order of magnitude slower than the hardware encoders WebCodecs reaches. It is the right tool when you need one specific filter in a browser, and the wrong default for everything else, which is why this site does not use it.

Why the line sits where it does

The pattern in the lists above is not random. Everything the browser does natively is work the operating system already had silicon or system libraries for: decode, encode, resample, draw. Everything that needs FFmpeg is encoder intelligence (rate control, tuning) or accumulated filter craft (denoisers, stabilisers), software that took two decades to write and lives nowhere else.

The browser did not replace FFmpeg. It replaced the upload: for the common shapes of work - convert this, trim this, shrink this, mark this - the machine that already has the file can now do the job, privately, at hardware speed. Knowing which side of the line your task is on is the skill, and it is teachable: drop a file on any how-to page and see.