A browser trim is a re-encode, not an MP4 atom rewrite

captureStream plus MediaRecorder writes a new WebM/MP4 of what played; Safari historically ships neither API, so the page feature-detects instead of failing silently.

Video Trimmer does not rewrite MP4 atoms. It cannot. A browser has no lossless "cut this range out of the bitstream" API. The tool seeks to your in point, plays the range, captures the element's stream, and records whatever is on that stream into a new file — usually WebM (VP9/Opus or VP8/Opus), sometimes MP4 if the browser will encode AVC. Cuts land near your in/out, not on source keyframes. The picture is re-compressed. That is the product.

A new file of what played

The sequence is mechanical. The tab checks HTMLVideoElement.prototype.captureStream (and the moz / webkit aliases). It checks MediaRecorder. If either is missing, you get a sentence, not a spinner after you pick a file. If both exist, you set in and out (minimum 0.1 seconds), the element seeks, MediaRecorder starts, the range plays, the recorder stops, and you download a blob.

That blob is not your source with a shorter duration flag. It is a recording of playback. Codec, container, and quality come from what the browser ships, not from the file you dropped. A ProRes take becomes WebM. A 4K source becomes whatever resolution the element actually displayed. Audio is whatever the captured stream contained: mute the element and you mute the recording, because there is no separate audio graph.

The clip also plays out of the speakers while it records. That is not a courtesy preview. MediaRecorder is listening to the same playback you hear. Headphones on, or the room hears the take twice.

Safari is a missing API, not a silent fail

Safari has historically shipped neither a usable captureStream on video elements nor a MediaRecorder path that can re-encode a captured stream. The page does not pretend otherwise. Feature detection runs first. If canCapture() is false, the copy is: this browser does not expose captureStream on video elements (Safari is the usual case); there is no way to clip a video in-page without that API, so the tool stops here rather than failing after you pick a file.

That is the whole Safari story. There is no WASM fallback, no server round-trip, no "upload and we'll cut it." The trimmer is free because it never leaves the tab. A browser that cannot capture cannot trim here. Use Chrome or Firefox for this utility, or leave the tab for an editor cut.

Chrome and Firefox still fail on some containers. If MediaRecorder produces no chunks, the error is that this browser's captureStream often fails silently on this container — not that your in point was wrong. Another container, or another browser, is the next test. Playback blocked without a user gesture is a third failure: click Trim again; the tab needs a gesture to play audio into the recorder.

What a re-encode changes

You lose lossless. You lose source keyframe alignment. You often lose the original codec. You gain a file that starts near your in point instead of at zero with a skip. Generation loss is real if you trim, download, trim again. Treat the browser trim as a one-pass rough cut of a take you will not re-cut in this tab.

You also do not get frame-accurate editorial. The element seeks to a decodable frame, then plays. timeupdate fires, and the recorder stops when currentTime passes the out point (or a watchdog at duration plus two seconds fires). That is "near," not an EDL. If the job is "cut on the clap," this is the wrong surface.

The sibling on the same chunk is video-to-GIF: frames sought, drawn to canvas, quantised, packed as GIF89a. Different encoder, same constraint — the tab can only emit what it can paint or record. Neither is a studio.

When to leave the tab

If you need a clean trim that keeps the source codec, or a cut in the middle that preserves both ends, that is the editor path. Trim a video is cut_video: one [start, end) range, billed as an editor operation, uploaded result. That is a generate-adjacent file job with a credit meter, not a Canvas toy. The video editing hub is the rest of those jobs — captions, speed, assemble.

Use the free trimmer when the job is "I have a take in this tab, I want a shorter file, I accept WebM, I am not on Safari." Use the editor when the job is "this file has to stay an MP4 of the original encode" or "I will keep cutting." Do not prompt a video model to "make a shorter version of this clip." That spends a clip rate to invent a new performance. It is not a trim.

The free tools index is the same rule as the trimmer: if the browser can do it locally, it is here; if it needs a model or a real cut, it is not.

FAQ

Why is the output WebM instead of a smaller MP4?

Browsers record in a codec they ship. The tool prefers video/webm with VP9 or VP8 plus Opus, then MP4/AVC if isTypeSupported says so. It does not rewrite your MP4 atoms. WebM is the usual result because that is what Chrome will encode.

Why does this page refuse to run in Safari?

Safari has historically not exposed a usable captureStream on <video> plus MediaRecorder for this path. The page checks the prototype before you pick a file and tells you. There is no in-tab clip without that API.

Are the in and out points frame-accurate?

No. Cuts land near the times you set, not on source keyframes. Seeking lands on a decodable frame; the recorder stops on timeupdate. Close enough for a rough cut. Not an EDL.

Does muting the player give me a silent file?

Yes. The captured stream is the element's playback. Mute the element and the recording has no audio. Unmute if you need the take's sound in the download.