Most video edits don't need re-encoding

Exporting a video normally means decoding every frame, changing it, and encoding it again — which is why a desktop export takes minutes and a web service asks you to upload first and come back later. But a surprising number of the edits people actually want don't change a single pixel. When that's true, the work is bookkeeping rather than computation, and a browser can do it in milliseconds on a file of any size. This page is about which edits those are, where the line falls, and what happens on the other side of it.

What is actually inside a video file

A video file is a container — MP4, MOV, MKV, WebM — and a container is essentially a wrapper with an index. Inside it are packets: short runs of compressed data, each carrying a slice of picture or a slice of sound, and each stamped with the moment it should be presented.

Two things follow, and between them they explain everything below. The expensive part of video is what's inside a packet. Opening one means running a decoder; producing a new one means running an encoder, and a few minutes of phone footage is tens of thousands of packets. The container is not the expensive part, and neither are the timestamps — those are numbers in an index, and rewriting them costs nothing at all.

So the useful question to ask of an edit is not "how complicated is this?" but "does this change what is inside a packet?" If the answer is no, the edit is a file copy with different bookkeeping, and it finishes at the speed of your disk. If the answer is yes, no amount of clever engineering avoids the cost — every frame has to be opened and made again.

Not a yes-or-no question

"Does it re-encode?" sounds like it has two answers. It has four, and the two in the middle are easy to miss — between them they do most of the interesting work.

Copied

The compressed video packets are written straight into the new file. No decoder is created, no encoder is created, and what comes out is bit-for-bit what went in.

Retimed

The packets are still copied; only the timestamps attached to them change. Nothing inside a packet is opened.

It depends

Copies when one specific condition holds and re-encodes when it does not. The tool works out which before the run, and tells you.

Re-encoded

Every frame is decoded, changed and encoded again. There is no packet-level shortcut for this in any engine, because the picture itself is different afterwards.

What each edit costs

Every row below is a tool on this site, and the verdict in each row is the decision that tool's own code makes before it starts — not a summary written afterwards. 6 of the 12 never open a video packet.

Why each answer is what it is

One line per row above, plus the case where it stops being true. The longer explanations for the more interesting ones follow further down.

Some numbers

Each of these was measured rather than estimated, and each carries the day it was taken — a claim about what a browser can do has a shelf life, and one written in the present tense hides that.

The cases worth explaining

A speed change is a timestamp change

This is the clearest example of the whole idea. A frame carries a picture and a presentation time. Playing a clip at double speed doesn't need different pictures — it needs the same pictures, presented twice as quickly. So the speed tool reads the file's encoded packets, divides every timestamp and duration by the speed, and writes them back out. No decoder is ever created. On a 10-second 720p clip that took nine milliseconds, and every one of the 240 video packets in the output was byte-for-byte identical to the one it came from.

The sound has no equivalent trick, and it's worth understanding why, because it comes up repeatedly. Audio samples run at a fixed rate — 48,000 of them a second, say. A track that plays in half the time must therefore contain half as many samples. Rescaling audio timestamps the way we rescale video ones would leave each packet still decoding to its original number of samples, and the track would overlap itself. So the audio really is decoded, retimed and re-encoded, while the picture beside it is copied. That combination — copied picture, rebuilt soundtrack — is common enough that it's worth naming, and several tools here report it as its own tier rather than rounding it to "fast" or "slow".

Splitting can copy every part — if you cut where the file lets you

A video isn't a sequence of independent pictures. Most frames are stored as differences from the frame before, and only occasionally — every one to four seconds, typically — does the encoder write a keyframe, which stands alone. A part of a video can only begin at a keyframe, because that's the only place a decoder can start without having watched everything before it.

That constraint is what makes splitting cheap and what makes it awkward. Cheap, because if your cuts land on keyframes, every part is a straight copy of a range of the original packets — a four-way split of a long recording is four file copies. Awkward, because a cut you place with your own hands lands on a keyframe roughly never.

We built the resolution to that twice and got it wrong both times, in the same way: we let the constraint drive the interface. The first version let a cut sit anywhere and quietly snapped it, so dragging a marker across four seconds of timeline changed nothing. The second made keyframes the only legal positions, which was at least honest but broke "split into two equal parts" — on a 13.96-second clip it cut at 8.5 seconds instead of 7. What finally worked was the other order: the timeline is a player scrubber, cuts go exactly where you put them, and snapping to keyframes is one optional action, priced in advance by how far the furthest cut would move. The engine's constraint is offered as a choice rather than imposed as a mystery.

Rotation is metadata; a mirror is not

MP4 and MOV files can carry a display matrix — an instruction to the player saying "show this rotated 90°". Rotating a video into one of those containers therefore doesn't touch the picture at all; it copies every packet and writes four numbers in the header. MKV and WebM have no usable equivalent (their muxer's own source comment notes that players ignore the value it would write), which is why the rotate tool always hands back an MP4.

A mirror has no such mechanism anywhere. No container has a flip flag, so flipping means drawing every frame onto a canvas with a reversed transform and encoding the result. Same tool, same-looking button, two completely different costs — which is why the tool tells you which one you're about to pay before you press go.

Merging asks the question twice

Joining clips has to answer "can this copy?" separately for the picture and for the sound, and the two answers are routinely different. A video track can describe only one decoder configuration for its whole length, so joining is all-copy or all-re-encode — there's no "re-encode just the odd clip out" mode to offer, because the format cannot express it.

The dangerous part is that a mismatch doesn't fail loudly. Give the muxer clips with different resolutions or different codec configurations and it will happily write a file that downloads cleanly and decodes to green frames from the first join onward. So the merge tool fingerprints every clip — codec string, coded size, colour space, the codec's own configuration bytes — against the first one, and re-checks that immediately before copying each clip's packets, because the file on disk could have changed between the check and the run.

Adding a soundtrack always copies the picture

Every other row in the table has some case where the picture has to be re-encoded. This one doesn't, and not by luck: putting sound on a picture never touches a video packet, and the only thing that could force a re-encode is having nowhere portable to put the result — but every video codec this engine can write has some container that carries it properly. So there is no re-encode tier in that tool at all, and no video encoder is ever created.

The decisions all move to the sound instead. Mixing two tracks rewrites samples. Looping does too, because copying a loop packet-for-packet carries the encoder's priming silence into every seam. So does a volume change, and so does nudging the sync backwards — a copy can only cut the head off an audio track on a packet boundary, which for AAC is about 23 milliseconds, so a 40-millisecond nudge would otherwise be quietly rounded to something you didn't ask for. Shifting sound forwards, on the other hand, is just a change of timestamps, and stays a copy.

Trimming, and the thing we got wrong

Trimming looks like it should be the easiest case here and is one of the more awkward. The trimmer runs through a general conversion pipeline that forces a full decode of every track as soon as the requested start moves past the track's own first timestamp — so trimming only the end of a clip can be a straight copy, while moving the start by a tenth of a second re-encodes the lot. There's a second condition that's easy to forget: the source has to already carry the codec this browser would write, so an HEVC clip from a phone re-encodes even when only the end moves.

For a while we wrote that down as a broader rule — that a keyframe-aligned copy of a range starting past zero simply wasn't available in a browser — and that was wrong. We had generalised a property of one API into a property of the whole library. The lower-level interface exposes exactly the keyframe lookup and bounded packet iteration such a copy needs, which is what the split tool is built on, and it shipped after the trimmer did. The narrower statement is the true one: a tool that reaches for that particular conversion pipeline cannot move an in-point without paying for a full re-encode. Whether the trimmer should move down to the packet level is a real open question rather than an oversight — it would trade a frame-exact in-point for a keyframe-aligned one, and that's a product decision, not a refactor.

Cropping and resizing have no fast path at all

This is the honest bottom of the table. Cropping and resizing change the shape of the picture, which makes every frame genuinely a different picture. There is no packet-level shortcut in any engine, and there isn't going to be one. So these tools don't compete on speed — what they own instead is the choice: reframing is a decision about what to lose, and the tool shows you exactly what each option discards (this percentage of the frame, bars this thick, this much upscaling) before you commit, using the same arithmetic that will produce the file.

A trap: muxable is not portable

One distinction runs through all of this and is worth stating on its own, because it's the difference between a fast tool and a fast tool that hands you an unplayable file.

An MP4 muxer will accept VP9, AV1 and ProRes. The resulting file is structurally valid and plays in Chrome and almost nowhere else. So "can this container hold this codec?" is the wrong question; the right one is "will the result open on the machine this is going to?" Every copy decision on this site is made against the narrower list. It's why converting WebM to MP4 re-encodes rather than taking the fast path that is technically available, and why a rotated VP9 file is refused up front rather than being written into a WebM whose players would ignore the rotation and show it sideways.

Where the browser still loses

Three limits, stated plainly, because a page arguing that browsers are faster than you'd expect should say where they aren't.

• GIF still needs ffmpeg. There is no GIF encoder in WebCodecs and no GIF muxer in the library that does the rest of this work, so the GIF tool loads a WebAssembly build of ffmpeg — about 9 MB — the moment you choose a file. It's the one tool here whose headline output can't take any of the fast paths above.
• Anything re-encoded is bounded by your machine. A copy is indifferent to file size; a re-encode is not. The tools that re-encode cap what they'll accept and say so before you start rather than failing halfway through a long run.
• Codec support is the browser's, not ours. Chrome and Edge are fastest because both the copy paths and the hardware-backed encoder lean on WebCodecs. Where a browser can't decode or encode something, the tool detects that before the run instead of discovering it partway in.