A video resizer test online runs in the current browser tab, never on a remote server: the file is read locally, frames are drawn to a resized canvas, the canvas stream is recorded as a WebM, and a download link is created from a revocable blob URL. The resize is a real re-encode rather than a metadata-only dimension change, which means the resulting file can differ from the source in size, bitrate, frame timing, color metadata, and audio layout. The output is always WebM because the tool leans on the browser's built-in VP9 or VP8 video encoder, avoiding any heavy media dependency or server-side processing. Output dimensions are rounded down to even pixel counts because common browser encoders are more reliable with codec-safe even sizes, so odd input values lose one pixel per side. Because the resize happens in real time, a five-minute source usually takes about five minutes to finish.
A test tells you three things at once: whether the tool accepts your source, whether the requested geometry behaves the way you expect, and whether the downloaded WebM plays in the player you care about. The Video Resizer page is designed for that loop — pick a short local clip, set a target width and height, choose a mode, and watch what comes out without ever leaving the browser tab or moving the source off your device.
What Testing a Video Resizer Online Actually Shows
The phrase "test online" gets used loosely, and three different behaviors often get lumped under it. A genuine local test reads a file from your device, decodes it in the browser, draws each frame to a canvas at the new dimensions, and produces a fresh WebM you can download. A metadata-only test rewrites the resolution field in the container without touching the pixels, and the output often refuses to play or plays back at the wrong size. A server test uploads the source to a remote machine, processes it there, and sends back a result — which works, but moves the file off your device during the run.
Video Resizer sits firmly in the first group. The browser does the decoding, the resizing, and the recording, and the source bytes never leave the device. The result is a WebM with a finite duration, written through a shared audited Matroska duration writer so players do not report it as an infinite stream. For a deeper walkthrough of what the local pipeline actually does, see Video Resizer Explained: How Local Resizing Works, which lays out the same flow in more detail.
What Video Resizer Does Before You Press Resize
The first thing the page does after you select a supported local video is read the file's metadata. The browser exposes the source dimensions, duration, and basic codec information.
The tool then validates the two numbers you type. Each dimension has to be a whole number from 2 to 1920 pixels, and the source itself must fit the file and codec envelope: up to 500 MiB, five minutes or shorter, no more than 4096 pixels per side, and no greater than 3840 × 2160 pixels in total area. If any limit is breached, the tool fails visibly rather than producing a misleading download. Unsupported codecs, invalid dimensions, excessive source metadata, empty recorder output, and browser capability gaps all surface as on-screen errors instead of corrupt files. Eight independent geometry fixtures cover landscape, portrait, square, same-ratio, bounding-box, stretch, and odd-dimension cases, which is how the tool keeps that visible-error behavior consistent across shapes.
How to Test a Video Resizer Online
This is the practical sequence for a clean local test.
- Open Video Resizer and click the file chooser. Pick a short MP4, WebM, MOV, M4V, or Ogg clip from your device. The supported list is fixed to those five containers because the browser has to be able to decode the source.
- Wait for the page to finish reading the file's metadata. The width, height, and duration appear next to the source label once the browser is ready, and the resize controls only become active after that.
- Enter the maximum width and height you want. Each value must be a whole number between 2 and 1920 pixels. The target is treated as a bounding box in Fit mode and as exact dimensions in Stretch mode.
- Pick a mode. Fit preserves the source aspect ratio inside the box and never crops. Stretch uses the requested width and height independently, which can intentionally distort the picture.
- Press Resize video and keep the tab open. The browser decodes the source, draws frames onto a resized canvas, captures that canvas at up to 30 frames per second, attaches any browser-exposed audio tracks, and records the result through MediaRecorder as VP9 or VP8 WebM. The underlying canvas captureStream behavior is documented on the MDN — Canvas captureStream reference.
- When the recorder finishes, download the WebM. The duration has been patched so the file reports a finite length, and the download URL is local and revocable. Open the file in your player to confirm the dimensions and aspect behavior match what you asked for.
Fit vs Stretch: Two Different Tests to Run
Fit and Stretch answer different questions, and running both is the fastest way to confirm the tool does what it claims. Fit asks the bounding-box question: apply the smaller of the two scale factors, preserve the source aspect ratio, and never crop the picture. The output ends up at the largest size that fits inside the requested width and height while keeping the original proportions. Stretch asks the exact-dimension question: use the requested width and height independently, which means the output is exactly the size you typed, even if the picture is squashed or stretched to fit.
| Behavior | Fit mode | Stretch mode |
|---|---|---|
| Aspect ratio | Preserved from the source | Follows the requested width and height |
| Distortion possible | No | Yes, when source ratio differs from target |
| Cropping | Never | Never |
| Output size | Largest fit inside the bounding box | Exactly the requested dimensions |
| Odd input handling | Rounded down to an even value | Rounded down to an even value |
| Typical use | Cap a video to a maximum size without distortion | Match a fixed pixel target such as a platform preset |
Both modes round odd dimensions down to even pixel counts because the underlying encoder is more reliable with codec-safe even sizes. That rounding is independent of the mode choice.
Limits That Affect Your Test Result
A few limits quietly decide whether a test runs or fails, and they are worth confirming against your source before you start.
| Limit | Value |
|---|---|
| Supported input containers | MP4, WebM, MOV, M4V, Ogg |
| Maximum source size | 500 MiB |
| Maximum source duration | 5 minutes |
| Maximum source side | 4096 pixels |
| Maximum source area | 3840 × 2160 pixels |
| Width and height range | 2 to 1920 pixels each |
| Dimension rounding | Odd values reduced by one pixel |
| Output container | WebM (VP9 or VP8) |
| Capture frame rate | Up to 30 fps |
| Processing location | Current browser tab only |
These numbers come straight from the published behavior of the tool. Anything outside them produces an on-screen error instead of a file, which is the safer failure mode for a test. The input list also makes clear what the tool will not accept: MKV, AVI, FLV, and other containers the browser cannot decode are rejected up front rather than faked through.
What the WebM Output Contains (and Does Not)
The downloaded file is a real re-encode, which means several properties that are easy to misread as bugs. Quality, bitrate, frame timing, audio layout, color metadata, and file size can all differ from the source, because the canvas redraw and the MediaRecorder pipeline rebuild those values from scratch. Audio is limited to whatever the browser exposes from the source, and multiple tracks and subtitles are not preserved.
The output does carry a finite duration that the player respects, because the file is finalized through a shared audited Matroska duration writer. The capture rate tops out at 30 frames per second, so a 60 fps source becomes a 30 fps WebM. The encoder also rounds output dimensions to even pixel counts, so odd targets drop one pixel per side. None of these behaviors mean the file is broken — they are the predictable shape of a real-time browser re-encode, and they are the same on every supported source that fits inside the input envelope.
When a Desktop Encoder Is the Better Test Subject
The browser pipeline is fast and private, but it is not a substitute for a full encoder in a few cases. Frame-accurate delivery, long footage above the five-minute limit, required MP4 output, color-managed workflows, and exact bitrate control all fall outside what Video Resizer is built to do. It does not upscale detail, does not remove black bars, does not crop a subject, does not preserve subtitles or multiple tracks, does not bypass DRM, and does not promise professional mastering. Use only media you own or may edit, and reach for FFmpeg, HandBrake, or a paid encoder when those constraints matter.
If you're weighing options, Check the Result After Video Crop: Verify Output Locally covers this in detail.