Video & audio

Trim, extract and convert — decoded by your own browser, not a server.

All 3 video & audio tools

Every one runs in your browser. Nothing is uploaded and nothing is metered.

What browser video tools are

Tools that read and rewrite video and audio using WebCodecs, the browser’s own hardware-accelerated media pipeline, rather than a server or a WebAssembly build of ffmpeg. The distinction decides what is possible: remuxing and audio work are fast, and re-encoding video is not.

Three video and audio tools that run on your own machine. Nothing is uploaded, which for a 200 MB video is not a privacy nicety — it is the difference between a tool that works and an upload bar.

The set is deliberately small. Everything that avoids re-encoding is fast and honest; everything that re-encodes video in a browser is slow enough that we would rather not offer it than offer it badly.

Why there are three and not twenty

The obvious way to build a video section is ffmpeg compiled to WebAssembly, and it is the wrong way twice over. Its core is GPL-2.0 — shipping it to a browser is distribution, which would oblige this entire site to the same licence — and the binary is 30.7 MB, over the 25 MiB per-asset limit our host allows. It is not a preference; the file cannot be served.

What works instead is WebCodecs, which every current browser exposes and which needs no special headers. Through it, trimming is a remux: the compressed frames are copied into a new container untouched, so a cut is lossless and takes about as long as reading the file. Extracting audio is a decode and a re-encode of a much smaller stream. Both are genuinely fast.

Re-encoding video is the operation that is not. A general "video converter" in a browser is many times slower than the desktop tool people already have, and would fail on the formats they most want converted. So the tools here are the ones where the browser is genuinely the right place to do the work, and the rest is left alone.

What makes these video & audio tools different

  • Trimming copies packets rather than pixels

    A video file is a container of already-compressed packets, so cutting it to a range means copying the packets you want into a new container. No decoder runs, no encoder runs, and the picture that comes out is the picture that went in.

    A ten-second cut from a 1080p file typically finishes in under a second, bounded by how fast the disk reads rather than by how fast the processor encodes.

  • The keyframe offset is printed, not rounded away

    A stream copy can only begin at a keyframe, so a cut asked for at 10.0 seconds on a file with keyframes every two seconds has to start at 8.0. Most tools round silently and hand back a clip that begins early. This one looks up the last keyframe at or before your point and shows the real figure as you move the handle.

  • Audio extraction works where WebCodecs does not

    Decoding audio never needed WebCodecs. decodeAudioData hands the work to the same operating-system codecs the browser uses to play the file, so the MP3 tool runs in browsers where the two video tools have to refuse.

    Firefox on Android ships no WebCodecs at all — neither decoders nor encoders. Video to MP3 still works there; the other two say so plainly rather than spinning.

  • Frames are asked for by timestamp

    Modern codecs use bidirectional frames, so decode order and presentation order differ for most real footage. Requesting an explicit ascending list of timestamps makes the sequence a property of the tool rather than of the decoder.

    Safari up to version 26.3 returns decoded frames in the wrong order; WebKit fixed it in the Safari 27 beta, leaving a long tail of devices that have not updated.

How to do it

The order that works, and why each step changes the answer.

  1. Check what your browser can actually do

    The panel says up front whether WebCodecs is present. Where it is not, the audio tool still works and the two video tools cannot — that is a browser fact rather than a setting to go looking for.

  2. Trim before anything else

    A lossless cut is the cheapest operation available and everything downstream gets faster for it. Taking two minutes out of an hour before making a GIF saves more time than any encoder setting will.

  3. Read the keyframe offset before you commit

    If the printed start is further from your mark than you can live with, nudge the handle forward; a nearer keyframe is usually a fraction of a second away. If you need frame accuracy, you need a re-encode and a desktop editor.

  4. For a GIF, cut the width first

    File size scales with area, so width is the cheapest lever by a distance. Frame rate is next. Length is last, because a shorter GIF is a worse GIF and the other two are usually free.

  5. Keep the original

    Every output here is a new file and none of them modifies what you dropped in, so a second attempt starts from the source rather than from a generation of loss.

Worked examples

Real inputs, real numbers. Pick one.

A cut that cannot land where you asked

You give it

Start at 10.0 seconds on a file with keyframes every 2 seconds.

You get

The copy must begin at 8.0 seconds. The figure is shown rather than applied silently, and moving the handle forward will usually find a keyframe within a fraction of a second.

Why a long recording is refused instead of attempted

You give it

A one-hour podcast at 48 kHz, stereo.

You get

Decoded audio is four bytes per sample per channel and cannot be streamed on this path: 48,000 × 2 × 4 × 3,600 = 1.38 GB held at once, which takes the tab down. The ceiling here is 300 MB of decoded audio — 781 seconds, or just over 13 minutes — and the arithmetic for your own file is printed with the refusal.

Halving the width of a GIF

You give it

A 640-pixel-wide clip re-exported at 320 pixels.

You get

Area falls to a quarter and so does the output, for a change most people will not notice in a chat window. Dropping the palette to 32 colours would save far less and be far more visible.

Which video & audio tool do you need?

Start from the job, not the tool name.

Against an uploading converter

AspectdsynA typical online converter
Upload time for a 200 MB clipNone — the file is never sentMinutes, before work begins
TrimmingLossless remux, no re-encodeRe-encoded, quality lost
Where the cut landsThe real keyframe start is measured and shownRounded silently
File retentionNever receivedCommonly deleted after 1–2 hours
Daily limitNoneOften 2–10 conversions
Format coverageWhat your browser decodesAlmost anything

The figures behind that

  • A trim here copies compressed frames rather than re-encoding them, so it is lossless — the trade is that cuts snap to keyframes and the real start can differ from the one you asked for by up to about two seconds.

  • Audio extraction works in every browser, including Firefox on Android, because it uses AudioContext rather than WebCodecs. The video tools need WebCodecs and will say so plainly where it is missing.

  • Decoded audio is held uncompressed at four bytes per sample per channel: roughly 85 MB for a four-minute track and about 1.38 GB for an hour at 48 kHz stereo, which is why anything past 781 seconds is refused rather than allowed to crash the tab.

  • FFmpeg’s WebAssembly build is GPL-2.0 and 30.7 MB — larger than the 25 MiB per-asset ceiling this site’s host will serve.

Keep exploring