Trim a video, save it as MP4 or GIF

What happens to your file

Opening a file gives this tab a private blob: address for it, the same way a local video player opens it. The browser decodes the picture and sound in memory, and the new MP4 or GIF is built in memory too. Download saves it like any other download. This page has no upload code and no server to upload to; it does not use browser storage either, so closing the tab forgets everything. The only network request after the page loads is an anonymous, cookie-free page-view count (GoatCounter), which never sees your video.

How to use it

• Open a video with the button, or drop it anywhere on the page. From the recorder, the “Trim or make a GIF” button under a finished recording opens this page with that recording already loaded.
• Choose the part to keep. Drag the two handles, type exact times into Start and End (1:05.3, 65.3 and 0:01:05.3 all mean the same), or pause the video where you want a cut and press “Set start here” or “Set end here”. “Play the cut” plays just that part.
• Save. Save MP4 or Save GIF. A progress bar shows how far it has got, and Cancel stops it. The finished file is listed below the trimmer with its size and a Download button.

MP4: a fresh encode, not a copy

The kept part is re-encoded as H.264 video, which every phone, editor and player opens. Sound becomes AAC where the browser has an AAC encoder (Chrome and Edge on Windows and macOS have one) and Opus inside the MP4 where it does not, for example Chrome on Linux. Opus-in-MP4 plays in browsers, VLC, Windows and Android, but QuickTime may play it silent. The line above the Save MP4 button tells you which one this browser will write before you press it.

Because it re-encodes, the result is a little softer than the source. The target bitrate is 0.09 bit per pixel per frame at 30 fps: about 2.5 Mbit/s (19 MB per minute) for 1280×720 and 5.6 Mbit/s for 1920×1080. Anything larger than 1080p is scaled down to fit it. The picture is captured while the clip plays in the tab, so a 40-second cut takes about 40 seconds. If the device is busy, a frame can occasionally be skipped; the one before it simply stays on screen a thirtieth of a second longer, so timing and sound stay in sync. Keep the tab in front: browsers pause video in background tabs. To get the sound, the page decodes the whole file's audio track in memory. That is quick for normal recordings, but a file of several gigabytes can make a phone tab run out of memory.

Some browsers cannot encode H.264 from a web page. Where the video can still be recorded as it plays (Chrome-based browsers, Firefox), the page records the cut instead. It writes MP4 where the browser can, otherwise WebM, and says which one before you save. WebM plays in every browser and VLC, but not in QuickTime.

GIF: why 30 seconds, and what to expect

A GIF stores every frame as its own 256-colour picture. It has no sound, and it cannot reuse one frame to describe the next the way video does. A 480×270 frame is 129,600 pixels; 30 seconds at 15 fps is 450 of them. How well they compress depends almost entirely on the picture. Measured with this page's encoder at 480×270, in bytes per pixel per frame: a slowly scrolling code editor 0.02, a moving test pattern 0.1, a zooming fractal 0.3, and grainy camera-like footage 0.98. The estimate under the GIF options uses 0.35 and shows the range. At 0.35, that 30-second GIF is about 21 MB; grainy footage would be nearer 58 MB. The same 30 seconds as a 480×270 MP4 at this page's bitrate is about 2 MB, sound included. The GIF grows in memory while it is encoded, so the page stops at 30 seconds rather than let a long GIF exhaust a phone. While it encodes, the progress line projects the final size from the frames done so far.

• Width is 320, 480 or 640 pixels, never wider than the source, and the height keeps the proportions. 480 is sharp enough to read on-screen text in most screen recordings.
• 10 fps is fine for screen recordings and gives smaller files. 15 fps looks smoother for people and motion. GIF timing is stored in hundredths of a second, so 15 fps alternates 70 ms and 60 ms frames to keep the total length exact.
• Each frame gets its own 256-colour palette, so colours stay faithful frame by frame, but smooth gradients show banding. The GIF loops forever.

What it cannot do yet

• One cut per file: it keeps a single stretch from a start to an end. It cannot remove a piece from the middle or join clips.
• No cropping, rotating, text or speed changes. The GIF width is the only size control.
• No lossless cut. Every save re-encodes, even when only a second is trimmed off.
• It opens only what this browser can play. HEVC (H.265) video from iPhones plays only where the system has an HEVC decoder, so it may not open in Firefox or on Linux, and no browser plays ProRes. Audio-only files are not supported here.

What works where

Version numbers are the first release with the feature, from MDN browser-compat-data for VideoEncoder, AudioEncoder, requestVideoFrameCallback and captureStream, checked 2026-09-23. They are not test results. *MDN tracks the encoder API, not which codecs it offers. H.264 and AAC depend on the operating system and the build. The “This browser” column asks the browser you are using now, for the exact settings this page uses. Without an encoder or captureStream (for example Safari before 16.4), the MP4 button is switched off and says why. Without requestVideoFrameCallback, the page seeks through the cut frame by frame instead, which is slower. The GIF needs only canvas and Web Workers, which all of these browsers have had for over a decade.

What has actually been tested

One browser: headless Chrome 150 on Linux, driven by the automated test in this site's repository on 2026-09-23. It opened a 3-second WebM, typed 1.0 and 2.0 as the start and end, and saved a 320-pixel, 10 fps GIF (10 frames) and an MP4 through WebCodecs: H.264 picture lasting 1.00 s and Opus sound lasting 1.02 s, Opus because Chrome on Linux has no AAC encoder. It saved the same MP4 again with requestVideoFrameCallback switched off (the seeking route), and once with WebCodecs switched off: the page announced the recording fallback in advance and produced an MP4 of about 1.06 s. It also checked that a webcam recording made on the front page opens here through the hand-off. Firefox, Safari and phones have not been tested; their columns above come from MDN only.