Trimming a video locally with the Video Trimmer produces a new WebM clip whose runtime matches the time range you selected, even when your source file is an MP4, MOV, M4V, Ogg, or WebM container. The pixel dimensions of the frame are preserved exactly, but the file is re-encoded in real time through the browser's MediaRecorder, so quality settings, keyframe placement, color metadata, audio channel layout, and total file size may all differ from the source you started with. The downloaded WebM carries your selected length in its Segment Info so compatible players show a finite timeline that matches what you requested, and the cut is not frame-accurate — the last encoded frame can land a small fraction of a second past or short of your chosen end. Decode, capture, and re-encode happen entirely in the current browser tab, so the source video never leaves your machine, and you can trim private recordings without a network connection.
What Container and Codec Come Out
No matter which container you start with, the result is always a WebM file. The tool accepts MP4, WebM, MOV, M4V, and Ogg inputs up to 500 MiB, but the final download uses the WebM container format. The codec inside that WebM is chosen at runtime from the browser's supported combinations, generally VP9, VP8, or VP8 paired with Opus audio. This design avoids shipping a large media processing dependency with the page and removes the need for any server-side re-encoding.
The choice of WebM does not change the visible pixel dimensions of your clip. If your source is 1920 × 1080, the trimmed WebM is also 1920 × 1080. What changes is the internal representation: a fresh VP9 or VP8 encoding replaces the original video stream, and any embedded audio is rewritten into an Opus track that the browser's MediaRecorder accepts. If you started with an MP4 that contained H.264 video and AAC audio, neither of those codecs survives into the download.
How the Output Differs From Your Source File
Trimming in the browser is not a packet-level lossless cut where the original encoded frames are copied into a new container. The tool seeks the media element to your start time, captures the browser-exposed media stream, and records until your end time — a real-time re-encode that writes new frames as the video plays. That process explains almost every property difference you will see between source and output.
The table below summarizes how each major property of the video moves from your source file to the trimmed WebM.
| Property | Source file | Trimmed output |
|---|---|---|
| Container | MP4, WebM, MOV, M4V, or Ogg | WebM only |
| Pixel dimensions | Original | Preserved exactly |
| Video codec | Whatever the source uses | VP9 or VP8 (browser choice) |
| Audio codec | Whatever the source uses | Opus when present |
| Quality settings | Original bitrate and encoding | Re-encoded by MediaRecorder |
| Keyframe placement | Original GOP structure | Re-encoded, new GOP layout |
| Color metadata | Original color tags | May be normalized or dropped |
| File size | Depends on source | Depends on new encoding |
A few rows deserve extra attention. Keyframes are repositioned because the recorder writes a fresh GOP structure, so scrubbing through the trimmed clip in another player will not land on the exact keyframe boundaries your source had. Color metadata such as HDR transfer characteristics or color primaries may not survive, because the recording pipeline writes through the standard WebM video track rather than the color-aware track. File size typically drops because a short, freshly re-encoded WebM is usually smaller per second than the equivalent slice of a multi-megabit H.264 MP4, but the exact size depends on what the browser's encoder decides for the scene content.
Boundary Accuracy: How Close Is the Cut?
Because the recorder samples playback time and the underlying HTMLMediaElement does not expose frame-accurate seeking, the trimmed clip is not frame-accurate. The encoded boundary can differ from your requested end by a small fraction of a second — typically well under a tenth, but visible if you are inspecting a single-frame edit decision. The UI reports the requested duration so you know the value you asked for, but the last written frame on disk reflects what the recorder actually captured.
This is a deliberate trade-off: recording from playback is fast, runs locally, and works inside the browser without external tooling. The pipeline uses the browser's MediaRecorder API to capture the playing media element, which is documented by MDN's MediaRecorder reference, and the recorded stream ends when the playback clock reaches the requested end. It is not a substitute for a keyframe-aligned cut in a desktop non-linear editor. If you are cutting for broadcast, frame-stepping through animation, or any workflow that demands frame-perfect boundaries, treat the result as a rough draft and re-export from a dedicated application.
Trim a Local Video Step by Step
Open the Video Trimmer in your browser and follow these steps to produce a WebM clip from a local source.
- Choose one supported local video from your device. The tool accepts MP4, WebM, MOV, M4V, and Ogg containers up to 500 MiB.
- Wait for the duration to populate in the interface. If the duration never appears, your browser cannot decode the codecs inside the container even if the extension is recognized.
- Enter the start time and end time as decimal seconds. You may include milliseconds (for example, 12.500). The start must be zero or greater, the end must be later than the start, and the final clip must be at least 0.1 seconds long. All values must sit inside the decoded source duration.
- Select Trim video. The UI will display the requested clip duration as soon as the recorder starts writing frames.
- Review the reported clip duration against your intended range. If it does not match, cancel and re-enter the times.
- When the recording finishes, download the WebM file. The WebM's Segment Info carries your selected duration, so compatible players will report a finite timeline.
Limits That Can Stop the Trimmer
Several interacting limits decide whether the trim completes or fails visibly. The source file must be 500 MiB or smaller. The decoded source — what your browser can actually play — must be no longer than five minutes, no wider or taller than 4096 pixels, and no greater than 3840 × 2160 pixels in total area. Any of those bounds being exceeded causes the tool to refuse the file rather than silently truncate it.
Equally important, the browser must be able to decode the codecs inside the container. A familiar extension does not guarantee success, because an MOV can hold H.264, HEVC, ProRes, or other codecs, and only the codecs your browser supports will play. If the duration never populates after you choose the file, that is usually a decode failure rather than a tool bug.
The trim range itself is validated, not clamped. A reversed range, an end time before the start, a start equal to the end, or any value past the decoded duration fails visibly so you can correct the input. You can include milliseconds in both fields, which is helpful for cutting on the frame just before a transition. Cancel is available if you need to stop an in-progress recording without waiting for it to finish naturally.
When the Local Output Is Not Enough
There are clear situations where the browser result will not match your needs. If you need a true frame-accurate cut at a specific frame number, the real-time recorder cannot deliver that — it is sampling playback time, not editing frames. If your deliverable requires an MP4 container with H.264 video, the tool produces WebM only; remuxing back to MP4 needs a separate step. Subtitle tracks, multi-language audio, chapter markers, and other metadata are not preserved, because the recording pipeline writes a single video track and at most one Opus audio track.
For broadcast delivery, exact keyframe cuts, subtitle preservation, multitrack audio, footage longer than five minutes, or a workflow that requires MP4, use a dedicated desktop editor and inspect the exported timeline before you trust the result. Many readers land on the browser tool first to rough out a cut, then refine in a full editor — that is a reasonable two-stage workflow, and the WebM the tool produces is a usable intermediate. If you are starting from an MP4 specifically, the workflow is essentially the same as trimming any other supported source — see how the local pipeline handles an MP4 trimmed in the browser for a format-specific walk-through.
If you're weighing options, Why Can the Output Be Larger With Video Compression covers this in detail.