Resizing a video in the browser means re-encoding each frame at new pixel dimensions, so the choices you make before clicking Resize determine whether the output looks sharp, stays proportional, and plays back correctly. Fit mode treats your numbers as a bounding box and preserves the source aspect ratio without cropping, while Stretch mode uses the exact width and height you type and can intentionally distort the picture. The output is a downloadable WebM produced in real time inside the current tab, capped at 1920 pixels per side and limited to sources up to 500 MiB and five minutes. Because the tool decodes, draws, and records frames locally, nothing is uploaded, but the work happens at roughly playback speed — so a five-minute clip takes about five minutes to finish. Knowing these mechanics, and the small habits that trip people up around odd dimensions, codec limits, and audio handling, is what separates a clean resize from a wasted render.

How Fit Mode and Stretch Mode Produce Different Geometry
The biggest decision before any resize is whether the picture should keep its original proportions. The Video Resizer exposes that decision through Fit and Stretch, and the two produce visibly different frames.
Fit treats your width and height as a bounding box. The tool picks the smaller of the two scales (width-to-target-width versus height-to-target-height), applies that single scale to both axes, and pads the rest of the box with empty pixels so the source ratio is preserved without cropping. Stretch ignores the ratio and uses the exact width and height you typed, independently, so a square source forced into 1920 × 1080 will be visibly wider than it is tall.
The product contract is explicit on both: Fit mode "applies the smaller width or height scale, preserves the source ratio, and never crops," while Stretch mode "uses the requested width and height independently, so it can intentionally distort the picture." If the goal is to fit a platform's spec without distortion, Fit is almost always the right pick; Stretch is for cases where the destination box is mandatory and some distortion is acceptable.
A quick worked example makes the math obvious. Take a 1280 × 720 source and Fit it inside a 1920 × 1080 box. Width scale = 1920 / 1280 = 1.5. Height scale = 1080 / 720 = 1.5. The smaller scale (1.5) is applied to both axes, so the output lands at 1280 × 1.5 = 1920 wide and 720 × 1.5 = 1080 tall, filling the box exactly without padding.
Source Limits That Affect Whether the Resize Runs at All
The Video Resizer enforces a small set of hard limits, and most failures come from bumping into one of them silently. Knowing the numbers up front is faster than re-encoding and discovering the source was over budget.
Per the verified limits, the source can be up to 500 MiB and five minutes long, with no side larger than 4096 pixels and no area greater than 3840 × 2160 pixels. Each requested dimension must be a whole number from 2 to 1920 pixels. Sources outside those ranges are rejected before encoding begins, so the tool fails visibly rather than producing a misleading download.
- File size cap: 500 MiB maximum.
- Duration cap: five minutes maximum.
- Side cap: no source side larger than 4096 pixels.
- Area cap: no source larger than 3840 × 2160 pixels.
- Target cap: each dimension must be a whole number from 2 to 1920 pixels.
Codec support is the other silent tripwire. The tool accepts short MP4, WebM, MOV, M4V, and Ogg files, but only those the current browser can decode. If the source uses an unusual codec or container that the browser cannot decode, the metadata load step will stall and the encoder will never start. The contract is explicit: "Unsupported codecs, invalid dimensions, excessive source metadata, empty recorder output, and browser capability gaps fail visibly instead of creating a misleading download." Practically, this means checking the source's playback in the browser before resizing, and trimming or transcoding unusually encoded clips with a desktop tool first.
Resize a Video Locally With the Video Resizer
Once the source passes the limits, the actual workflow is short and entirely browser-side. Nothing leaves the device, the encoding happens in the current tab, and the WebM download lands directly on disk.
- Open the Video Resizer and choose one supported local video (MP4, WebM, MOV, M4V, or Ogg). Wait for the browser to finish reading the file's metadata before touching any controls.
- Enter the maximum width and maximum height you want, using whole numbers from 2 to 1920 pixels. Pick Fit to preserve the source aspect ratio inside the box, or Stretch to force the exact width and height regardless of ratio.
- Select Resize video. Keep the tab open and on screen — the encoder captures frames in real time at up to 30 fps, so processing roughly equals playback duration.
- When the recorder finishes, save the generated WebM. The file is finite-duration, locally produced, and ready to play or upload.
If the source includes audio, the tool attaches any browser-exposed audio tracks to the captured canvas stream. If the source is silent, the resulting WebM has no audio — by design, not by accident.
Mistakes That Ruin a Resized Video
Most resize failures fall into a handful of repeatable patterns. Spotting them before encoding saves a full render.
Choosing Stretch when the platform wants a ratio. Forcing a 9:16 source into 1920 × 1080 with Stretch will produce a horizontally squished portrait clip. If the target is "fits inside this box without distortion," Fit is the correct mode.
Assuming the tool upscales detail. It does not. A 640 × 360 source resized to 1920 × 1080 will be larger in pixels, but the visible detail is still 640 × 360 worth of information stretched across the bigger canvas. Upscaling detail is explicitly outside the tool's scope.
Typing odd dimensions. The encoder rounds odd values down by one pixel because even dimensions are more reliable with common browser video encoders. A request for 1081 × 721 lands as 1080 × 720 in the output. Type even numbers from the start to avoid surprises.
Expecting the result to be MP4. The output is WebM, by design, because the recorder selects a supported VP9 or VP8 WebM configuration. If MP4 is required, the contract points to a dedicated desktop encoder.
Expecting bitrate, audio layout, color metadata, or frame timing to match the source. This is a real-time re-encode, not a metadata-only dimension change. Quality, bitrate, frame timing, audio layout, color metadata, and file size "can differ from the source," per the product contract.
Closing the tab during encoding. The recorder lives in the tab. Closing it, navigating away, or losing focus on some browsers can interrupt capture. Keep the tab open until the WebM download is offered.
Uploading copyrighted media without rights. The tool does not bypass DRM, and the contract reminds users to "use only media you own or may edit."
Picking Dimensions That Survive the Encoder
Because odd dimensions are rounded down, picking even numbers from the start keeps your output predictable. Likewise, picking dimensions inside common platform ratios reduces the chance of accidental letterboxing or distortion.
| Mode | Treats inputs as | Preserves aspect ratio | Can distort | Can crop | Odd dimensions |
|---|---|---|---|---|---|
| Fit | Bounding box | Yes | No | No | Rounded down to even |
| Stretch | Exact target | No | Yes | No | Rounded down to even |
A few additional rules of thumb help the resize finish cleanly. Stay inside 2 to 1920 pixels on each side — anything outside that window is rejected. Keep the source under 500 MiB and five minutes; longer or larger files should be trimmed first. Remember that this is a real-time re-encode, so a five-minute clip takes about five minutes to process, and plan tab time accordingly. The recorder captures frames at up to 30 fps and adds any browser-exposed audio tracks, so the output's frame timing and audio layout can differ from the source.
For a deeper look at how the local decode-canvas-record pipeline works under the hood, the step-by-step breakdown of the in-browser resizing pipeline walks through the same canvas and MediaRecorder mechanics the Video Resizer uses.
When the goal exceeds what a browser-based re-encode can do — frame-accurate delivery, long-form footage, exact bitrate control, color-managed workflows, or required MP4 output — the product contract steers you toward a dedicated desktop encoder instead. The Video Resizer is the right tool for fast, local, bounded resizes; it is not a replacement for a full mastering pipeline.
Related reading: Video Resizer Without App: Resize in Your Browser.