A browser-based video trimmer does not produce a frame-accurate cut at the requested boundary; the encoded end of the downloaded clip can land a small fraction of a second away from the time you typed. When a tool seeks to a start time, records the media stream during playback, and stops at an end time, the actual encoded frames depend on how the browser samples playback, not on packet-level inspection of the source. The Video Trimmer from Lizely works exactly this way: it captures the browser-exposed media stream, records in real time, and writes a new WebM file with the selected duration patched into its Segment Info. So while you can enter start and end values down to the millisecond and the tool will report the requested duration, the last encoded frame may sit slightly before or after the timestamp you asked for. That distinction, between convenient and private on one side and frame-exact on the other, is the heart of the question and it shapes every expectation you should set before downloading the result.
What "Frame-Accurate" Means When You Trim a Video
Frame accuracy is the property of an edit whose first encoded frame lines up with the source frame at the requested time and whose last encoded frame lands on the source frame at the requested end. In a non-linear editor this is achieved by parsing the container and the keyframe index, then cutting at GOP boundaries or at the exact frame that the playback head points to. The output is either a stream copy of those packets or a precise re-encode aligned to the chosen frame, and the editor can prove the alignment by reading the timeline back.
Browser trimming cannot do that by default. A web page can play a local video, seek to a timestamp, and capture the decoded output through the MediaStream Recording API, but it cannot read the source packets, the keyframe index, or the per-frame container structure. The recording that the browser produces is tied to the playback clock, not to the container's edit points. According to MDN's MediaRecorder documentation, the recorded data comes from a captured MediaStream during playback, which means each chunk is timestamped against real time as the browser is asked to play.
The practical result is that the first encoded frame of the WebM matches the first frame the browser painted after seeking to the start, and the last encoded frame matches the last frame painted before the recorder was stopped near the end. The last encoded frame can be off by a small fraction of a second in either direction, depending on keyframe placement, codec behavior, and how aggressively the browser flushes its recording buffer. The reported duration in the UI is the duration you requested; the encoded duration in the file is whatever the browser actually captured.
Why the Encoded Boundary Drifts from the Requested Time
The drift has three main causes, and they all come from how the recording pipeline is built rather than from any one knob in the tool.
The first cause is real-time capture. The Video Trimmer seeks to the requested start, captures the media element's stream, and records until playback reaches the requested end. The recording runs at real-time speed, so any pause, hitch, or playback rate change would shift where the encoder stops. On a healthy machine with a short clip this is usually invisible. On longer clips or underpowered devices it is the most likely source of slippage and it is not something the tool can compensate for after the fact.
The second cause is codec flush behavior. When the recorder stops, the browser finishes encoding whatever frames are currently in its pipeline. That trailing chunk can include a few extra frames or stop just short of the exact boundary, depending on the codec. VP9, VP8, and the optional Opus audio path can all behave slightly differently here, and the browser does not expose a hook to rewind and trim the trailing frames. The Segment Info of the WebM is then patched with the requested duration so compatible players report a finite timeline, but the encoded frames themselves are not rewound or trimmed to match.
The third cause is seek precision. Decoded video in a browser is positioned by time, not by frame number. If the source has keyframes at irregular intervals, the browser may have to play from the previous keyframe to reach your requested start, which can introduce a few frames of slack before the visible content actually begins. Combined, these three effects are why a "cut at 12.500 s" can show up as 12.43 s or 12.57 s in the encoded WebM, and why the requested duration shown in the UI and the actual duration inside the file are close but not identical.
How to Trim a Video Locally in Your Browser
For most everyday trimming tasks — sharing a clip, cutting a section out of a recording, posting a short excerpt — the boundary drift is small enough to ignore. This is the workflow for using the Video Trimmer when you accept that the result is a real-time re-encode rather than a frame-exact cut.
- Choose one supported local video file (MP4, WebM, MOV, M4V, or Ogg) up to 500 MiB and wait for its duration to populate in the UI. The file is never uploaded; decoding happens in the current browser tab.
- Enter the start time in seconds, allowing decimals for milliseconds, with a value of zero or greater. Enter the end time in the same format, ensuring it is later than the start and no later than the decoded duration.
- Confirm the requested range covers at least 0.1 seconds and that the source itself is no longer than five minutes when decoded, no wider or taller than 4096 pixels, and no greater than 3840 × 2160 pixels in total area.
- Select Trim video. The tool seeks to the start, captures the media element stream, and records until playback reaches the end.
- Review the reported clip duration and output size shown by the UI. Cancel is available while the work is active.
- Download the resulting WebM file. The output uses VP9, VP8, or an optional Opus combination selected from the browser's supported configurations, with the selected duration written into the Segment Info.
Note that a familiar extension does not guarantee success: the browser must support the actual codecs inside the container, not only recognize the filename. If a step fails visibly — for example an invalid or reversed range, an unsupported codec, or an empty recording — the tool reports it instead of guessing or clamping your values.
Input, Output, and Limit Constraints
Trim accuracy is not the only thing that changes between inputs and outputs. The following table summarizes the constraints the Video Trimmer enforces and the properties of the resulting file. If any row is violated, the tool cannot complete the task and will surface the failure rather than silently degrade the result.
| Constraint | Accepted value |
|---|---|
| Container formats | MP4, WebM, MOV, M4V, Ogg |
| Source file size limit | Up to 500 MiB |
| Decoded duration limit | No longer than five minutes |
| Decoded dimensions | No side over 4096 px; total area at most 3840 × 2160 px |
| Codec requirement | Browser must support the actual codecs in the container |
| Start value | Zero or greater; may include milliseconds |
| End value | Later than start; no later than decoded duration |
| Minimum selected clip | At least 0.1 seconds |
| Output container | WebM (VP9, VP8, or Opus combinations) |
| Dimensions in output | Preserved from source |
| Quality, keyframes, color metadata, audio layout | May differ from source |
| File size of output | May differ from source |
| Processing location | Local browser tab; nothing uploaded |
Reversed or out-of-range inputs — start after end, end past the decoded duration, or a selected clip shorter than 0.1 s — fail visibly rather than being clamped or shifted silently. That visible failure is part of why the requested duration and the encoded duration can diverge: the tool reports the duration you asked for, and the encoded frames land where the browser happened to put them.
When Frame-Accurate Cuts Matter and What to Use Instead
There are situations where the small boundary drift described above is genuinely unacceptable, and the Video Trimmer is not the right tool for them. Knowing these boundaries up front saves you from redoing work later.
- Broadcast or theatrical delivery. Editorial decisions like "cut exactly on the clap" or "cut on the downbeat" require frame-aligned output. Use a dedicated desktop non-linear editor and inspect the exported timeline frame by frame.
- Exact keyframe cuts. If you need the new clip to begin on the source's keyframe so that downstream tools can stream-copy without re-encoding, a browser capture cannot give you that. You need packet-level access, which means a tool that parses the container.
- Subtitle, chapter, or marker preservation. The trimmed WebM does not promise to preserve every metadata field. If your source carries embedded subtitles, multi-track audio, or chapter markers, the new file is likely to drop them.
- Required MP4 output. The Video Trimmer always writes WebM. If your downstream tool, platform, or device requires an MP4 container, re-encode the trimmed WebM in a desktop editor.
- Long source material. Anything longer than five minutes of decoded video is outside the tool's accepted range. Trim in segments, or move to a desktop workflow.
- DRM-protected media. The tool does not bypass DRM, fetch remote media, or remove watermarks. Use only video you own or have permission to edit.
For everything outside that list — sharing a short clip, cutting a section out of a meeting recording, grabbing a snippet for a message, extracting a quick excerpt for review — the boundary drift is small enough that the convenience, the privacy of local processing, and the speed of an in-browser trim outweigh the loss of frame-exact alignment. Treat the requested duration as a target, the encoded duration as an approximation, and the WebM as a freshly re-encoded preview rather than a frame-perfect cut.
If you're weighing options, What Can Go Wrong When You Extract a Video Frame covers this in detail.
If you're weighing options, What Every Beginner Should Know Before Trimming Video covers this in detail.