The trimmed result is WebM because the tool re-encodes your selected range through the browser's built-in MediaRecorder API rather than copying the original stream, and the tool selects WebM as the output container. Your MP4, MOV, M4V, or Ogg source is decoded into playable frames inside the current tab; the tool seeks to your start time, captures the decoded video as it plays back, and asks MediaRecorder to save that capture as a new file. The tool picks the first supported VP9/VP8 WebM recorder configuration from the browser's MediaRecorder and writes the clip to that container. That is why a file that started as .mp4 can come back as .webm after trimming, and why a familiar extension on the source does not guarantee the source itself will decode successfully.

why is the result webm when i trim video
Why Your Trimmed Video Comes Out as WebM

How a Browser Produces a WebM Trim

When you load a local file into the Video Trimmer, three things happen before any video is written to disk. First, the file is held in the current browser tab as a decoded media element, which means the source is never uploaded to Lizely. Second, the browser inspects the codecs inside the container, not just the filename extension, to decide whether it can actually decode the file. Third, when you select a time range and trigger the trim, the tool seeks the media element to your requested start, asks the browser for the live media stream from that element, and passes that stream to a MediaRecorder configured for WebM.

MediaRecorder is the browser's built-in video recorder. According to the MDN reference for MediaRecorder, the API exposes only the container and codec combinations the current browser supports, and WebM with VP9 and VP8 is the combination that ships in every major engine, while Opus is an optional audio codec the browser may include. The companion guide on Recording a media element explains that capturing from a playing HTMLMediaElement is the standard pattern when you want to record a portion of a video already on the page, which is exactly what trimming in the browser requires. The trim is therefore a real-time re-encode: the tool plays back the selected range and records what plays, rather than slicing the source at the packet level like a desktop non-linear editor would.

Trim a Video and Save the WebM Output

  1. Open Video Trimmer and choose one supported local file (MP4, WebM, MOV, M4V, or Ogg up to 500 MiB). Wait for the duration field to populate, which confirms the browser has decoded the file successfully.
  2. Enter the start time and end time in seconds, keeping the range inside the decoded duration. The start can be zero, the end must be later than the start, and the selected clip must be at least 0.1 seconds. Millisecond precision is allowed.
  3. Select Trim video and watch the reported clip duration appear. If the request is invalid, the tool fails visibly rather than guessing or clamping.
  4. Download the resulting .webm file. The reported duration is written into the WebM Segment Info so compatible players display a finite timeline that matches what you requested.

For more on what to inspect in the file once it lands on disk, the guide What Should You Review After You Trim a Video walks through the verification steps that follow the download.

What Stays the Same and What Changes in the WebM

Because the WebM is produced by re-encoding during playback, only one property of your source is guaranteed to survive unchanged: the output dimensions. Quality, keyframe placement, color metadata, audio channel layout, and file size are all subject to the codec the browser picks and the bitrate it chooses. A 1080p H.264 MP4 with a tight bitrate can grow in size after trimming if the browser's WebM encoder is less efficient on that particular footage; the same source can also shrink if the encoder happens to be more efficient. The practical rule is that you cannot predict the exact output size from the source size, which is why the UI reports the actual file size after recording.

PropertySource (e.g. MP4)Trimmed WebM Output
ContainerMP4, MOV, M4V, WebM, or OggWebM (always)
Video codecSource codec (H.264, HEVC, VP9, etc.)VP9 or VP8, whichever the browser prefers
Audio codecSource codec (AAC, Opus, etc.)Opus, if the browser supports it
DimensionsSource resolutionSame as source
File sizeSource sizeRe-encoded, depends on codec choice
Reported durationFull sourceSelected clip, written into Segment Info

When WebM Output Is Fine and When It Is Not

WebM is well supported on the open web. Most current desktop browsers and modern Android phones play VP9 WebM without extra software, and playback support on smart TVs and set-top boxes varies by device. If your destination is an embed on a web page, a Discord message, a Slack thread, a Mastodon post, a Telegram send, or a generic file share, the WebM result is what you want. Tools that post-process the clip downstream (for example, Video Compressor, which re-encodes the same way to shrink size, or Video Cropper, which re-encodes after a pixel crop) all read WebM natively, so handing them a WebM keeps the pipeline simple.

There are situations where WebM is the wrong deliverable. Some chat apps, older media players, and certain broadcast pipelines still expect MP4 with H.264. Professional editors that need exact keyframe cuts, multitrack audio, subtitle passthrough, or full color metadata preservation also do not benefit from a playback-capture trim, because MediaRecorder cannot deliver any of those guarantees. In those cases the right move is to use a dedicated desktop editor and inspect the exported timeline. The tool never claims to replace that workflow, only to cover the common case where you want a quick, local cut.

Limits of the WebM Trim You Should Know

A few hard limits govern whether the tool can finish the job at all. The decoded source must be no longer than five minutes, no wider or taller than 4096 pixels, and no greater than 3840 × 2160 pixels in total area. The source file itself must be no larger than 500 MiB. A familiar extension does not guarantee success because the browser must actually decode the codecs inside the container; a filename ending in .mp4 that wraps a codec the browser cannot play will fail just the same as an unrecognized format. Boundary precision is another limit to set expectations on: MediaRecorder samples playback time and does not expose frame-accurate editing, so the last encoded frame can land a small fraction around the requested boundary. The tool also does not bypass DRM, fetch remote media, remove watermarks, or preserve every metadata field. Use only video you own or have permission to edit.

For a deeper look at the format and quality behavior covered above, the companion guide Trim Video Output: What Format and Quality to Expect expands on the same boundary and codec choices from a different angle.