After you resize a video, the result is a freshly encoded WebM file built inside your browser, so the first thing to review is whether the dimensions, aspect ratio, audio, and playback behavior match what you asked for. The local resize pipeline decodes the source, paints frames onto a resized canvas at up to 30 fps, captures that canvas, and records it through MediaRecorder using VP9 or VP8, which is why the output behaves like a real-time re-encode rather than a metadata-only rewrite. That distinction matters for your review: pixel dimensions can be checked directly, but quality, bitrate, frame timing, audio layout, color metadata, and file size may shift from the source even when the picture looks right. Going through a short checklist — width and height, aspect behavior, audio presence, file playback, and any visible artifacts — turns the resized file from a guess into a confirmed deliverable, and it tells you exactly what to send back through the tool when something is off.
Dimensions and Geometry to Verify
When reviewing a resized video, start with the dimensions themselves, because every other check downstream depends on them. Open the file in a player that shows width and height (most desktop players expose it via a Properties or Get Info dialog) and confirm both numbers are even, fall within the requested bounding box, and match the mode you selected. The local resize rounds odd values down to the nearest even pixel because common browser video encoders are more reliable with codec-safe even sizes, so a requested width of 801 will land at 800 in the output. The source side is bounded at 4096 pixels per side and 3840 × 2160 in area, the target side is bounded at 2 to 1920 pixels per dimension, and each entry must be a whole number — anything outside those ranges fails visibly rather than silently miscalculating. If the numbers are off, the fix is almost always in the inputs, not in the file itself.
How to Resize a Video Locally for Review
This is the concrete workflow that produces a file worth reviewing:
- Open Video Resizer in a browser tab and choose one supported local video (MP4, WebM, MOV, M4V, or Ogg) up to 500 MiB and five minutes. Wait for the browser to finish reading the file metadata before continuing, since downstream checks depend on the dimensions and duration being available.
- Enter the maximum width and the maximum height you want, as whole numbers between 2 and 1920. Pick Fit if you want aspect-preserving geometry inside a bounding box, or Stretch if you want the exact width and height regardless of distortion.
- Select Resize video and keep the tab open during real-time encoding. The browser draws decoded frames onto a resized canvas, captures that canvas, and records the result in real time — processing normally takes about as long as the source itself.
- When the recording finishes, the WebM file is offered as a download with a finite duration patched in. Save it to a known location and move on to the review checklist below.
If you want a second opinion on the result after you save it, see Video Resizer Test Online: Verify the Local Result for the local checks that match this exact pipeline.
Aspect Ratio Behavior: Fit vs Stretch to Check
Fit and Stretch are the two geometry paths the tool exposes, and they have opposite review implications: Fit preserves the source ratio inside your bounding box and never crops the picture, and Stretch uses the requested width and height independently and can intentionally distort. The fix for a wrong-looking aspect is rarely a re-render with the same inputs; it is a choice between picking a bounding box whose ratio matches the source (for Fit) or accepting distortion (for Stretch).
| Review item | Fit mode | Stretch mode |
|---|---|---|
| Source aspect ratio | Preserved exactly | Not preserved |
| Cropping behavior | Never crops | May distort or stretch subjects |
| Bounding box role | Width and height are the maximum allowed box | Width and height are the exact target |
| Scale selection | Smaller of width- or height-bound scale is applied | Each axis scales independently |
| Typical review flag | Empty bands on one axis if source ratio differs | Squashed or stretched faces, text, or geometry |
If a Fit result shows unexpected bands, the issue is almost always a ratio mismatch between source and bounding box, not a bug — and the remedy is either to pick a bounding box with the same ratio or to switch to Stretch when distortion is acceptable.
Audio, Codec, and Format Details to Confirm
The local pipeline attaches any browser-exposed audio tracks and records the result as VP9 or VP8 inside a WebM container, using HTMLCanvasElement.captureStream to feed MediaRecorder. That means three review questions are worth answering on every result.
- Did the audio survive? If your source had a track and your target player reports silent playback, the track was either not browser-exposed or not picked up during capture, and the file is video-only by design. Try a different browser to rule out a track-exposure gap.
- Is the file a WebM? The tool deliberately avoids server processing and large media dependencies by relying on built-in browser codecs, so MP4 output is not produced. If your delivery target requires MP4, route through a dedicated desktop encoder instead — that is the documented handoff point for container mismatches.
- Does it play where it needs to play? Open the file in the player, embed, or browser where it will ship. Some older mobile players and certain professional NLE timelines do not accept WebM at all, and a successful local resize does not guarantee downstream compatibility.
The MDN reference pages for HTMLCanvasElement.captureStream and MediaRecorder describe the same capture and record pipeline this tool relies on, which is useful background when an audio or codec question needs grounding.
File Size, Quality, and Timing Differences to Expect
Because the resize is a real-time re-encode rather than a metadata-only dimension change, several output properties can drift from the source even when geometry is correct. The contract is explicit: quality, bitrate, frame timing, audio layout, color metadata, and file size can all differ from the source. For a review, that means three expectations to set before you declare the result good or bad.
- File size does not necessarily shrink. If your goal was to shrink a file, resize alone is the wrong tool, and the size-reduction path in Video Compressor is the better fit.
- Frame timing is resampled during capture at up to 30 fps, so a 60 fps source can drop to a lower temporal rate. If frame-accurate delivery matters, route the source to a desktop encoder instead.
- Quality can compress slightly differently across runs because MediaRecorder selects a supported VP9 or VP8 configuration on the spot. Treat visible artifacts as a signal to re-run with a different bounding box, not as evidence that the tool is broken.
A simple arithmetic example makes the odd-dimension rounding visible. If you enter a width of 801, the encoder reduces it by one pixel because common browser video encoders are more reliable with even pixel sizes: 801 − 1 = 800. The same rule applies to height, so any odd value you enter will land one pixel lower in the output, and that one-pixel landing is the first number to confirm when you open the saved WebM.
When to Send the Result Back Through the Tool
A review can fail for predictable causes, and the fastest path forward is usually a second local resize with adjusted inputs rather than a manual fix. Re-run the resize when the dimensions came out wrong because the bounding box ratio did not match the source (pick a matching ratio, or switch to Stretch when distortion is acceptable); when the audio track is missing (confirm the source actually had a browser-exposed track, then try a different browser, since codec and track exposure vary by engine); when the WebM will not load in the target player (if the destination demands MP4, color-managed output, or frame-accurate timing, this is the documented handoff point to a desktop encoder rather than a local browser tool); or when the output looks softer than expected (a re-encode through a smaller bounding box will compound softness, so resize alone is not the answer, and pairing it with a quality-targeted workflow is the better path before declaring the result unusable).
The local pipeline is explicit about what it does not promise: it does not upscale detail, remove black bars, crop a subject, preserve subtitles or multiple tracks, bypass DRM, or guarantee professional mastering. A review that holds the result to those promises is the right kind of review; a review that asks the local resize to do things outside that contract is the kind that needs a different tool. Use only media you own or may edit, and treat any visible failure (unsupported codec, invalid dimensions, excessive source metadata, empty recorder output, browser capability gap) as a clear signal to fix the input rather than ship the file.
For a deeper look, see What to Do When You Cannot Resize a Video.