The result is WebM because a browser-based video resize re-encodes your clip using the codecs already installed in your browser, and those codecs write the WebM container by default. When you resize a video locally with a tool such as Video Resizer, the source is decoded frame by frame inside your current tab, each frame is drawn at the new dimensions onto an HTML canvas, and that canvas is captured back into a video stream that MediaRecorder can package as a WebM file. No server is involved, no extra media dependency is loaded, and the encoder path is the same one the browser already uses to play video inline. The format is a property of the encoder, not a choice the tool makes about your content, so MP4 and MOV outputs require a different pipeline entirely.
Why the resized result is a WebM file
The short answer is that VP8 and VP9 are the video codecs available inside a standard browser tab. They were standardized for web playback, the Matroska-based WebM container was built around them, and every modern browser exposes them through the MediaRecorder API as ready-made recordable configurations. A local tool that wants to ship without a server, a download, or a heavy native dependency has to use whatever the browser already offers. WebM with VP8 or VP9 is exactly that.
This is the answer Video Resizer gives in its own FAQ: the tool uses built-in browser codecs and avoids a large media dependency or server processing. The same logic applies to other in-browser re-encoders that resize, crop, or trim clips without uploading them, which is why a reader who has just resized a video for the first time is often surprised to see a .webm file in their downloads folder no matter what the source format was.
How a browser resize turns any source into WebM
The pipeline is the same whether the source is MP4, WebM, MOV, M4V, or Ogg. First the browser decodes the chosen file using its own decoder and reads the metadata for width, height, duration, and available audio tracks. HTMLCanvasElement.captureStream is then used to attach a live video stream to a canvas that has been sized to your target dimensions, and decoded frames are drawn onto that canvas at up to thirty frames per second. Finally, MediaRecorder records the captured stream using a VP9 or VP8 WebM configuration the browser reports as supported, which is why the file that lands in your downloads is always WebM regardless of how the source began.
The whole loop runs inside your current browser tab, which means your video is never uploaded to a server and the re-encode runs at roughly real-time speed. You can read more about what happens to your file in this explanation of local resizing and privacy.
Resizing a video locally with Video Resizer
The actual workflow is short because the heavy lifting happens inside the browser. Open the tool, pick a file, enter the numbers, choose a mode, and download the WebM.
- Choose one supported local video (MP4, WebM, MOV, M4V, or Ogg) and wait for the browser to finish loading its metadata before changing any fields.
- Enter the maximum width and maximum height you want, then choose Fit to preserve the source aspect ratio inside that bounding box or Stretch to force the exact width and height you entered.
- Select Resize video and keep the tab open during the real-time encode; closing or backgrounding the tab can interrupt the recording.
- When processing finishes, download the WebM result from the link the tool exposes, and rename or move it as needed.
Fit vs Stretch: choosing the right output behavior
Both modes produce a WebM, but the geometry they produce is different. Fit treats your numbers as a bounding box and applies the smaller width or height scale so the source aspect ratio is preserved without cropping. Stretch uses your width and your height independently and can therefore distort the picture, which is useful only when the exact dimensions matter more than the shape of the image.
| Behavior | Fit (aspect-preserving) | Stretch (exact) |
|---|---|---|
| Treats inputs as | Maximum bounding box | Exact width and height |
| Source aspect ratio | Preserved | Can be distorted |
| Cropping applied | No | No |
| Best for | Keeping the picture looking normal inside a target size | Filling a target slot where distortion is acceptable |
If the WebM comes back looking wrong, the cause is almost always the Fit-versus-Stretch choice rather than the encoder. This troubleshooting guide walks through the usual culprits.
What the WebM resize changes and what it keeps
Because the WebM is produced by a real-time re-encode rather than a metadata edit, several visible properties can shift even when the dimensions look right. Knowing what is preserved and what is not helps set expectations before you download.
| Property | Status after the WebM resize |
|---|---|
| Pixel dimensions | Changed to your Fit or Stretch target, rounded down to even pixels |
| Container format | Always WebM (VP8 or VP9) |
| Source aspect ratio | Preserved in Fit, possibly distorted in Stretch |
| Audio | Browser-exposed audio tracks are attached when available |
| Quality, bitrate, frame timing, file size | Can differ from the source because it is a fresh encode |
| Subtitles, multiple tracks, color metadata, DRM | Not preserved; the tool does not handle them |
If you need bitrate control, color-managed output, subtitles, or an MP4 container, a desktop encoder is the appropriate tool. The in-browser approach is optimized for speed, privacy, and getting a usable WebM on your device without a server.
Limits that can stop a WebM result from being produced
Several constraints can cause the resize to fail visibly rather than silently. Each width and height must be a whole number between two and 1920 pixels; odd values are reduced by one so the encoder receives codec-safe even sizes. The source itself is limited to about 500 MiB and five minutes, with no side larger than 4096 pixels and no area larger than 3840 × 2160 pixels. Unsupported codecs, invalid dimensions, excessive source metadata, an empty recorder output, or a browser that lacks the required APIs all fail in a visible way instead of producing a misleading download. Because the resize uses the browser's own codecs, the result is only as capable as the browser you happen to be running.
When WebM is the right format for the resized clip
WebM with VP8 or VP9 is widely accepted for web playback, social platforms that accept WebM uploads, Discord, email attachments, and most modern media players. It is also the format that pairs naturally with HTML5 video. When the destination is one of these, the WebM result is exactly what you want and you can stop thinking about the file extension. If the destination is a legacy workflow, a broadcast tool, or a system that strictly requires MP4, plan for a second step with a dedicated desktop encoder to repackage the WebM rather than expecting the browser-based resize to produce MP4 directly.