Resizing a video re-encodes it from scratch, so anything tied to the encoding pipeline — pixel dimensions, bitrate, frame timing, audio layout, and color metadata — can shift in ways the source file never promised. Downscaling trades detail for smaller files, upscaling cannot invent the pixels it adds, Fit mode can letterbox inside a bounding box, and Stretch mode can visibly stretch faces and lines when the aspect ratio is wrong. The output container can also change: many local workflows save to WebM rather than MP4 because WebM is what the browser's built-in VP9 and VP8 codecs natively produce. Subtitles, multiple audio tracks, and chapter markers rarely survive because they sit outside the canvas-based re-encode. None of these are bugs in a single tool — they are properties of how re-encoding works, and the safest way to avoid the worst surprises is to know which switches control which outcome before you press the button.
Where Resizing Breaks Down
Every resizing job pulls the video through five steps that each carry their own failure mode: decode the source, scale each frame on a canvas, capture that canvas, encode the result with a browser codec, and write a downloadable file. A problem at any one of those steps shows up differently.
- If the decoder cannot read the codec, you see a blank frame instead of an error message.
- If the scale asks for odd dimensions, the encoder silently rounds down and your output is one pixel smaller than you typed.
- If the capture stage drops audio, the file plays silently even though the preview looked perfect.
- If the recorder returns nothing, some tools still hand you a zero-byte download.
- If the writer mishandles the duration, the file imports at the wrong length or refuses to seek.
The list is not exhaustive, but it explains why a "simple resize" can produce a confusing result. Video Resizer treats each of those steps as a checkpoint: unsupported codecs, invalid dimensions, empty recorder output, and capability gaps fail visibly rather than handing you a misleading file.
Quality, Bitrate, and the Re-encode Tax
Re-encoding is lossy by definition. The source was encoded once with a specific bitrate, color space, and quantization matrix, and every time you decode and re-encode it, you pay another round of compression noise. Downscaling — making a 1920×1080 video fit into 1280×720 — is usually the gentlest operation because you are throwing away detail that already existed. Upscaling — making a 640×360 clip fill 1920×1080 — cannot add the information it does not have, so the encoder is forced to interpolate, soften, or sharpen whatever pixels it finds.
This is also why quality, bitrate, frame timing, audio layout, color metadata, and file size can differ from the source. The browser pipeline picks a target frame rate, a VP9 or VP8 codec configuration, and a bounded bitrate that suits the captured canvas. Those defaults are tuned for portability, not for archival fidelity, so the output is best treated as a delivery copy rather than a master.
Aspect Ratio Mistakes That Distort the Picture
The single most common resize mistake is forcing a non-matching aspect ratio. If your source is 1920×1080 (16:9) and you ask for exactly 1080×1080 in Stretch mode, the encoder will squeeze the wide image into a square and faces will look pinched. Fit mode prevents that by treating the requested width and height as a bounding box: it picks the smaller of the two scale factors, applies it uniformly, and never crops.
Concretely, with a 1920×1080 source and a 1280×720 bounding box in Fit mode, the smaller scale is min(1280 ÷ 1920, 720 ÷ 1080) = 0.6667. Multiplying each source dimension by that scale gives 1280 × 720, which lands exactly inside the box because the source already matches the box's 16:9 ratio. Switch the source to 1920×1200 and ask for the same 1280×720 box: the smaller scale becomes min(1280 ÷ 1920, 720 ÷ 1200) = 0.6, so the result is 1152 × 720, sitting inside the box without distortion. Stretch mode would have given you 1280 × 720 and a visibly wider picture, by design.
The distinction matters because Fit is the safe default for almost every social platform, while Stretch is the right choice when a fixed slot — a banner, a slide, a thumbnail slot — demands exact dimensions.
Format, Codec, and Container Surprises
Most local browser tools output WebM because the MediaRecorder API can only write what the browser can encode natively, and VP9 and VP8 WebM are the formats every modern browser supports. MP4 with H.264 is a different encoder and almost always lives behind a large WASM dependency or a server. That is why Video Resizer delivers a WebM file and not an MP4: the canvas is captured through HTMLCanvasElement.captureStream and recorded straight to whatever supported WebM profile the browser exposes.
Two consequences follow. First, if your downstream tool only accepts MP4, you will need a separate conversion step. Second, anything that lives outside the video and audio elementary streams — embedded subtitles, chapter markers, multiple language tracks, GPS metadata, color profiles — is dropped on the floor because the recorder simply has nowhere to put it. The browser pipeline adds back the audio tracks it can find through standard decoding, but it does not preserve sidecar metadata.
How to Resize a Video Locally Without Triggering These Problems
- Pick a single supported local file — MP4, WebM, MOV, M4V, or Ogg — and wait for the browser to finish reading its metadata before moving on.
- Enter a maximum width and a maximum height, each as a whole number from 2 to 1920 pixels, and decide whether you want aspect-preserving Fit or exact Stretch.
- Choose Resize video, leave the tab focused, and let the real-time encoder finish — processing typically lasts about as long as the clip itself.
- Download the resulting WebM when the prompt appears, and test it in the player or platform you actually care about before deleting the source.
The trick is to set expectations in advance: pick Fit unless a fixed slot forces Stretch, accept WebM as the output format, and remember that odd pixel values will be reduced by one so the encoder stays codec-safe.
Limits That Decide Whether a Resize Succeeds
The tool can only succeed if every source-side and target-side limit is satisfied at the same time. The table below lists the boundaries Video Resizer checks before encoding.
| Constraint | Allowed range | What happens at the edge |
|---|---|---|
| Target width | 2 to 1920 pixels, even integer | Odd values rounded down by one pixel |
| Target height | 2 to 1920 pixels, even integer | Odd values rounded down by one pixel |
| Source file size | Up to 500 MiB | Larger files rejected before decoding |
| Source duration | Up to five minutes | Longer clips rejected before decoding |
| Source width or height | Up to 4096 pixels per side | Wider or taller sources rejected |
| Source pixel area | Up to 3840 × 2160 pixels | Higher-resolution sources rejected |
If a resize still misbehaves after those checks pass, the troubleshooting guide for resizing problems walks through the next layer of diagnosis in the same order a browser pipeline would.
When a Local Resize Is Not the Right Tool
A browser resize is honest about its limits. It does not upscale detail, does not crop a subject, does not preserve subtitles or multiple tracks, does not bypass DRM, and does not promise professional mastering. If your delivery needs any of those — frame-accurate cuts for broadcast, a color-managed master, required MP4 output for an older player, long-form footage above the five-minute cap, or exact bitrate control — the right move is to hand the source to a dedicated desktop encoder like FFmpeg, HandBrake, or a paid NLE.
Inside the same browser toolbox, cropping, compression, and trimming are each their own task with their own failure modes, and choosing the right one usually produces a cleaner result than trying to bend a resizer into doing all of them at once. A two-minute clip trimmed to a different in-frame rectangle is a crop, not a resize; a 400 MiB file that needs to fit a 50 MiB attachment is a compression, not a resize. Matching the task to the right tool is the simplest way to make sure nothing goes wrong when you resize video.
For a deeper look, see What Details Matter When You Resize Video.