Video Editing Moved Into the Browser Tab
For most of the web’s history, “edit this video online” meant “upload this video to us”. The file went to a server, something happened to it there, and a link came back. That model has an obvious problem for anything you would rather not hand to a stranger: a screen recording of internal software, footage of your children, a clip from a client project. And a less obvious one. Uploading a 400 MB file over home broadband takes longer than the edit itself.
WebCodecs changed that. It gives JavaScript direct access to the same hardware video encoders and decoders the browser already uses to play video, which means a browser tab can now decode frames, alter them and re-encode them without a server being involved at any point.
This post is about what that actually looks like in practice, what the three video tools on this site do, how they differ, and where browser-based editing still hits real limits.
The Same Pipeline, Three Different Jobs
The Video Editor, Video Compressor and GIF Maker look like three separate tools, and to a user they are. Underneath they share most of their machinery: one timeline component for trimming and reordering, and one shared crop-and-caption layer. In every case the encoding happens in a Web Worker, off the main thread, so the page keeps responding while your file is processed. The editor and compressor share a WebCodecs worker, and the GIF maker has its own.
What differs is the destination.
| Tool | Takes | Produces | Use it when |
|---|---|---|---|
| Video Editor | MP4, MOV, M4V | MP4 (H.264) | You need to cut, join, crop or caption |
| Video Compressor | MP4, MOV, M4V | MP4 (H.264) | The file is too big to send |
| GIF Maker | MP4, MOV, M4V | GIF | The destination will not accept video |
That last row is the one worth pausing on, because a GIF is almost never the technically better choice. It is the choice you make when something on the other end refuses to take a video file. More on that below.
What “Compression” Actually Adjusts
The compressor offers three quality settings, and it is worth knowing they change two things at once rather than one:
| Setting | Target video bitrate | Output dimensions |
|---|---|---|
| Low | 500 kbps | Half the original width and height |
| Medium | 1,500 kbps | Three quarters |
| High | 3,000 kbps | Unchanged |
Halving the dimensions is the larger effect of the two, because it removes three quarters of the pixels. That is why the low setting can shrink a file dramatically while medium is a much gentler reduction: the bitrate difference is 3×, but the pixel difference is another 2.25× on top of it.
The practical consequence: if your video is going to be watched full-screen, use High and accept a smaller reduction. If it is going into a chat window or a slide, Low is often indistinguishable at the size it will actually be viewed, and produces a far smaller file.
Audio is re-encoded separately at 128 kbps on the low setting and 192 kbps otherwise, which is a small share of the total for anything but a very short clip.
The Codec Negotiation Nobody Sees
One detail of browser-based encoding that has no equivalent in desktop software: the tool cannot assume the codec it wants is available. Hardware encoder support varies by device, operating system and browser, and the same code on the same browser can succeed on one laptop and fail on another.
The worker handles this by asking before committing. It asks for H.264 High Profile first, since that configuration produces the best quality per bit, then calls VideoEncoder.isConfigSupported() to find out whether this particular machine can do it. If the answer is no, it falls back to Baseline Profile, which is older, slightly less efficient, and supported essentially everywhere.
You never see this happen. But it is the reason the tool works on a five-year-old Android phone as well as a current MacBook, and it is a good illustration of how browser APIs differ from a native application: capability is negotiated at runtime rather than assumed at install time.
Why GIFs Get So Large
The GIF Maker is the tool most likely to surprise people, because GIF is a 1987 format carrying constraints that made sense for dial-up and make very little sense now.
The binding one is colour. A GIF frame can contain at most 256 distinct colours. Converting video means building a palette for each frame and mapping every pixel to its nearest entry, which is exactly what the encoder here does, using omggif under an MIT licence. Flat colours and sharp edges survive that process well, which is why a screen recording of an interface converts cleanly. Skin tones and gradients do not, because a continuous range has to be approximated by a fixed handful of values, and the result is visible banding.
The second constraint is that GIF has no meaningful compression between frames. Modern video stores one complete frame and then describes only what changed; GIF stores each frame close to whole. File size therefore scales almost linearly with the number of frames, and a five-second clip really is five times a one-second clip.
Those two facts together explain the usual advice, which is worth stating as an order of operations. To make a GIF smaller, in this order:
- Cut the duration. Trimming a second off costs less than anything else on this list.
- Lower the frame rate. 10–15 fps is fine for a screen recording; below 10 the stutter becomes the thing people notice.
- Reduce the width. Half the width is a quarter of the pixels, but text becomes unreadable quickly.
And the honest recommendation: if the destination accepts MP4 or WebM, send that instead. The same clip is frequently a tenth the size at higher quality, and both formats loop silently in browsers, which was GIF’s last remaining practical advantage.
What Stays on Your Machine, and What Does Not
All three tools process files entirely on your device. The worker’s dependencies are served from this domain rather than pulled from a CDN when the tool loads, so opening one does not contact a third party, and the video itself is never transmitted anywhere.
That property is the point of the whole approach rather than a marketing line. It means these tools are usable for the footage people most want to edit and least want to upload: screen recordings containing internal tools or customer data, anything under a non-disclosure agreement, family video.
It has a cost worth stating plainly. Processing speed depends on your own hardware rather than on a server farm, so a long clip on an older laptop takes a while, and the tab needs to stay open while it works. A service that uploads your file can throw more CPU at it than your machine has. The trade is compute for privacy, and for most of what people actually edit, that is a trade worth making.
Where the Limits Still Are
Three limits are worth knowing before you start.
The input list is short. All three tools accept MP4, MOV and M4V, and nothing else. A file in another container (WebM, AVI, MKV) needs converting first, even if the video inside it is perfectly ordinary.
Long files need patience and memory. Frames are decoded, processed and re-encoded in sequence, and a phone with limited memory will struggle with a long high-resolution clip in a way a desktop will not.
MP3 is not available as an output, and this one is a licensing decision rather than a technical one. AAC encoding is built into the browser; MP3 encoding is not, and the libraries that add it carry terms this site does not accept. The audio extraction tool therefore produces M4A, which holds AAC audio and plays essentially everywhere. It is the better format of the two anyway. The only thing MP3 still wins on is playback in equipment made twenty years ago.
Try Them
Start with the Video Compressor if you have a file that will not send, the Video Editor if you need to cut or join clips, and the GIF Maker when the destination insists on a GIF. Nothing uploads, nothing needs an account, and you can watch the network tab while you work to confirm both.