A resized video that looks wrong almost always comes down to one of four predictable causes: the wrong Fit-or-Stretch mode, dimensions that force distortion, odd pixel values being rounded down for codec safety, or pre-existing damage in the source that no resizer can undo. The Video Resizer runs entirely inside the current browser tab — it decodes the local file, draws each frame onto a canvas at the requested pixel dimensions, and re-records that canvas as a WebM file you download directly. Because every pass through that pipeline produces the same kind of output, the cure for a wrong-looking result is rarely a different program. It is a second pass with corrected inputs: pick the mode that matches what you wanted the picture to do, enter dimensions that are safe even numbers, and accept that the resizer cannot add detail that was never in the source. If your first result looks stretched, blurred, or off by one pixel, walk back through those three controls before assuming the tool failed.
What typically makes the result look wrong
Before re-running anything, identify which symptom matches what you see. The same fix will not help every problem, and a few of the symptoms look similar but have opposite causes — most notably black bars and stretched faces. The table below pairs each visible symptom with the most likely control that produced it and the change to make on the next run.
| What you see in the WebM | Most likely cause | What to change on the next pass |
|---|---|---|
| People look stretched tall or squished wide | Stretch mode applied to a source whose ratio did not match the requested box | Switch to Fit so the picture scales inside the box without distortion |
| Black bars on the sides or top and bottom | Fit mode applied to a source whose ratio does not match the box | Either accept the bars (Fit preserves the whole image) or switch to Stretch if filling the exact spot matters more than the ratio |
| Output is one pixel smaller in width or height than you typed | Odd dimension was reduced by one pixel for codec-safe even sizes | Re-enter the value as an even number, or accept the rounded output |
| Picture is blurry, blocky, or shows compression smearing | Pre-existing damage carried through; the re-encode did not invent detail | Re-run with the same settings and accept the new bitrate, or clean up the source before resizing |
| No download appears, or an error shows in the page | Unsupported source codec, source outside the size cap, empty recorder output, or a browser capability gap | Re-check the source against the supported formats and limits, then try a different browser if the canvas pipeline is unsupported |
If your symptom is not in that table — for example the colors look washed out or the audio is missing — the cause is usually outside the resize step itself. A local browser resizer does not apply a color transform, and it only carries audio tracks that the browser exposes from the source. Check the source file first before re-encoding.
Re-run Video Resizer with corrected settings
The fastest way to fix a wrong-looking resize is to repeat the same tool with adjusted inputs. Re-encoding produces a brand-new WebM rather than editing the broken one, and every step of the pipeline stays identical so you can compare outputs cleanly.
- Reopen the Video Resizer in a fresh tab and select the same source file from your device. Wait for the browser to finish reading the file's metadata before touching any controls; the tool needs that data to validate the geometry.
- Decide what your result should look like. If the picture must keep its original ratio, choose Fit and treat the numbers you enter as a bounding box. If the picture must fill the exact width and height no matter what, choose Stretch and accept that the source will be distorted when its ratio does not match the box.
- Enter a whole-number width and height between 2 and 1920 pixels. Make both values even — for example 1280 and 720, not 1281 or 721 — so the encoder does not have to round them down for you.
- Click Resize video and keep the tab in the foreground. The encode runs in real time through the browser's MediaRecorder pipeline, so a one-minute clip takes roughly one minute to finish; closing or backgrounding the tab can interrupt the canvas captureStream that feeds it.
- When the download appears, open the new WebM and compare it against the source frame by frame. If the picture now matches what you wanted, you are done. If something still looks off, the verification approach in the local resize result guide walks through how to isolate which control is responsible.
Fit vs Stretch: which one your result needs
Most wrong results come down to picking the wrong mode. The two options sound similar but produce opposite geometry, and the tool's product documentation confirms the difference: Fit preserves aspect ratio inside the requested box, while Stretch uses the exact width and height and can distort the picture. The table below pairs each mode with the goal it serves and the residual problem that can still make the output look off.
| Your goal | Mode to pick | What the picture does | When the result still looks wrong |
|---|---|---|---|
| Keep the source ratio intact inside a size limit | Fit | Scales the source with the smaller of the two ratios so it fits entirely inside the box | Black bars will appear on the side that did not limit the scale — that is by design, not a bug |
| Fill the exact width and height regardless of ratio | Stretch | Uses the requested width and height independently; the picture becomes wider or taller per axis | Faces and shapes will distort when the source ratio is far from the requested one |
| Output a target ratio for a social platform | Fit, with both dimensions set to the platform's maximum | The clip lands at or below the platform's bounding box; the source decides the exact letterbox | You may still need a separate crop step to remove the letterbox bars before posting |
If your goal is to keep the source intact, Fit is the safe choice. If your goal is to fill a specific canvas, Stretch is the correct choice — but you should expect distortion as the deliberate answer, not a stretched image as an accident.
Output limits that shape the result
Several hard limits apply to every run, and most of the "looks wrong" reports trace back to one of them being ignored. The constraints below come from the tool's published limits, and they apply whether you are resizing for the first time or fixing a previous result.
| Constraint | Limit | What it means if your result looks wrong |
|---|---|---|
| Dimension range | 2 to 1920 pixels per side, whole numbers only | A value outside that range is rejected before encoding starts; no download is produced and the page surfaces the error visibly |
| Even pixel sizes | Odd dimensions are reduced by one pixel | The output is one pixel narrower or shorter than you typed — codec safety, not a processing bug |
| Source size cap | Up to 500 MiB and five minutes | A larger or longer source fails validation; the resizer does not silently truncate it |
| Source pixel limits | No more than 4096 pixels per side, no greater than 3840 × 2160 in area | A source above those bounds is rejected; the WebM never gets written |
| Output container | WebM, created in the current tab via MediaRecorder | If you needed MP4 or a specific muxing profile, the local browser resizer is not the right tool |
| Output dimensions formula | Fit mode applies the smaller width-or-height scale to preserve ratio; Stretch uses the values as-is | The visible size is a direct function of the inputs — no hidden sharpening, denoising, or upscaling is applied |
When the local resizer is not the fix you need
The Video Resizer changes pixel dimensions and re-encodes the frames at those dimensions. It does not add detail that was never in the source, remove black bars that were already in the source, crop a subject, preserve subtitles or multiple tracks, bypass DRM, or promise professional mastering. If your wrong-looking result is actually pre-existing damage — soft footage from a low-bitrate original, interlacing from a phone camera, or color shifts baked into the file — no second pass through the resizer will clean it up. Quality, bitrate, frame timing, audio layout, color metadata, and file size can all differ from the source because the output is a real-time re-encode, not a metadata-only dimension change.
For frame-accurate delivery, long source footage, required MP4 output, color-managed workflows, or exact bitrate control, the right answer is a dedicated desktop encoder rather than another browser pass. Within the local browser toolbox, the resizer is the right tool when the source is sound and the picture just needs to land at a specific size; it is the wrong tool when the symptom is actually a property of the source file itself.
If you're weighing options, How Do I Get Started When I Need to Resize Video? covers this in detail.