1999.LOC

A video in, a shorter or smaller or looping one out.

Cutting a video does not have to re-encode it. If the output can hold the codec the file already uses, the compressed video is copied across untouched, so the result is bit for bit your original, just shorter, and it takes seconds rather than minutes. Change the size, the rotation or the quality and it has to be decoded and encoded again, which is slower and costs a generation of quality.

Every other converter re-encodes everything and says nothing. This one works out which one your settings mean and tells you before you press the button.

Is this actually private?

• Nothing is uploaded. Static page, no endpoint, no account. The file is read from disk into this tab and the result is written back out of it.
• Copying is not re-encoding, and the difference is the whole point. When the output container can hold the codec your file already uses and nothing about the picture changes, the compressed video is copied across untouched: identical quality, and roughly ten times faster. The panel above says which of the two your settings mean before you start.
• Changing container is usually free. An MP4 can hold VP9 and a Matroska file can hold almost anything, so “convert this WebM to MP4” is normally a repackage rather than a conversion. The codec your file already uses is preferred over whatever this page would otherwise call best, precisely so that stays true.
• A copied cut lands on a keyframe. Every frame in a compressed video is stored as a change from the one before it, back to a keyframe, a frame stored whole. A copy has to begin at one, because there is nothing to describe its first frame against otherwise. The page reads your file to find the last keyframe before your start point and tells you exactly where the cut will land and by how much it moved. If you need the frame you actually pointed at, tick the box and it will re-encode to get there.
• Copying needs no codec at all. Repackaging never decodes anything, so a video in a codec this browser cannot play (an old phone's HEVC, say) can still be trimmed and moved into another container here. Only re-encoding needs the codec, and the page says when it does not have it.
• Which formats appear depends on your browser, and it is asked rather than assumed. The codecs come from the browser itself. Chrome, Edge and Safari ship H.264 and AAC, so MP4 works. Some builds of Chromium, and Firefox on some systems, ship only the open codecs, and there MP4 can only be written with AV1 or VP9 inside it. Rather than offer a format and fail three minutes in, the page asks the browser what it can actually encode and offers that.
• “Fit under 10 MB” is arithmetic, not a slider. A bitrate is a size divided by a duration, so the target sets it directly rather than being guessed at. The sound is subtracted first, because it is spent whatever happens to the picture, which is why a short clip at a small target can be impossible, and the page says so instead of producing something broken. Whether the result will look like anything is judged in bits per pixel, which is the only measure that means the same thing at 480p and at 4K.
• A sharp small picture beats a smeared large one. Squeezing 4K into 10 MB does not give you 4K, it gives you mush at 4K's dimensions. Where dropping the resolution would land the same target in the clear, the page names the height and offers to apply it.
• The GIF encoder is written out here, because there is nowhere to fetch one from. No CDN script, no ffmpeg, no WebAssembly: a colour quantiser, a ditherer and an LZW compressor, in the tab. The palette is chosen with median cut from frames sampled across the whole clip, so the colours do not lurch when the scene changes, and it is picked from the colours your video actually contains rather than a fixed grid, which is why so many GIFs look like 1997.
• Only what moved is stored. A GIF frame may cover part of the canvas and let the rest show through, so everything that did not change between one frame and the next is marked transparent and simply is not encoded. On a static shot with something moving in it, later frames come to a few per cent of the picture. It is where nearly all the size saving in a good GIF comes from.
• Dithering trades banding for speckle. Snapping each pixel to the nearest of 256 colours turns a smooth sky into stripes. Floyd–Steinberg pushes each pixel's rounding error into its neighbours instead, which the eye much prefers, at the cost of a larger file, because the speckle is noise to the compressor. It is on by default and can be turned off.
• A GIF is roughly twenty times the size of the same clip as video, has no sound, and cannot hold more than 256 colours at once. It is a 1987 format kept alive by the places that will not accept anything else. If you have a choice, use the video.
• Re-encoding is real work. It decodes and re-encodes every frame, using the same hardware video engine a video call uses. It is fast for a phone clip and slow for an hour of 4K, and it will make a laptop's fan audible. Trimming without re-encoding does not.
• Large files are held in memory. The result is assembled in the tab before you download it, so a very large output can run a tab out of memory. Trimming first is the fix.
• What it does not do: subtitles, chapters, multiple audio tracks, joining two videos, or anything creative. It cuts, converts, resizes, rotates, mutes, extracts and animates.
• It downloads about 620 KB the first time, once you open a file: mediabunny, which reads and writes the container formats. The codecs themselves are the browser's own WebCodecs. There is no ffmpeg here and no WebAssembly, which is why it is quick.

Hosted on Cloudflare · Made with spite for bloat
image tools | pdf to word | edit a pdf | excel to csv | source

Nothing here is for sale, nothing is tracked, and there is no account to make. If something saved you an hour:
83TQcTwusSQ4WKbPQE5osrF3cR4GWe2zmcNWeozK6BSqHSaeLvjUVe476ouVwLKn1uVwEFcbJQvnme7W6dTV5SB93x45DEy
You can check that address here before sending anything.