A video resizer is a tool that changes the pixel dimensions of a video file by re-encoding each frame at a new width and height, producing a new file that plays back at the requested size. The browser-based Video Resizer performs this re-encoding locally in your tab using HTML5 video decoding, a canvas, and MediaRecorder, so the source never leaves the device. It accepts MP4, WebM, MOV, M4V, and Ogg files up to 500 MiB and five minutes long with source dimensions no larger than 4096 pixels per side and 3840×2160 pixels in area, and writes a WebM output capped at 1920 pixels per side. Geometry is controlled by two simple toggles: Fit treats the entered numbers as a bounding box and preserves aspect ratio, while Stretch uses the exact width and height independently and can therefore distort the picture. Because the re-encode runs in real time on the page, processing normally takes about as long as the video plays back.
What "Resizing a Video" Actually Means
Resizing a video means changing the count of horizontal and vertical pixels that make up each frame. The width and height shown in a player describe the frame's pixel grid: a 1920×1080 frame has 1,920 columns and 1,080 rows. When a resizer changes those numbers, it must re-render every single frame at the new grid, because pixels cannot simply be deleted or added without redrawing the picture. That re-render is a real re-encode, not a metadata edit. It re-samples the source image, blends neighbouring pixels to fit the new size, and writes a new encoded bitstream that a player can decode again. The result is a brand-new video file whose pixel dimensions match the request.
Two geometric ideas sit underneath every resize request. The first is aspect ratio, the proportional relationship between width and height. A 1920×1080 frame is 16:9, a 1080×1080 frame is 1:1, a 1080×1920 frame is 9:16. The second is the distinction between a bounding box and an exact rectangle. A bounding box is a maximum container: anything inside it must fit, so the smaller of the two axis scales governs the output. An exact rectangle is what its name implies — every requested pixel is honoured, even if that means squashing the image.
How a Browser-Based Resizer Differs From a Server Tool
Many "online" video resizers upload the source file to a remote server, process it on cloud hardware, and send back a download link. That model works but creates clear trade-offs: the file leaves the device, sits on third-party infrastructure during processing, and depends on upload bandwidth. For long clips, large originals, or confidential material, those trade-offs can matter.
The Video Resizer follows a different model. The browser itself becomes the encoder. The selected file is read by an in-page video element, decoded frame by frame, drawn onto a canvas at the new dimensions, captured by the canvas's captureStream method, and recorded with MediaRecorder using the browser's built-in VP9 or VP8 WebM codec. Because every step happens in the current tab, the source never travels across the network. The only network activity is the initial page load. The privacy mechanics behind this approach are walked through in Is an Online Video Resizer Safe? What Really Happens.
This architecture also explains the output format. The tool outputs WebM because that is the container the browser can natively produce through MediaRecorder. Trying to write MP4 from the same pipeline would require shipping a heavy media encoder library, which is exactly what the design avoids.
Inside the Video Resizer: The Pipeline
The internal pipeline runs in eight recognisable steps:
- The chosen file is loaded into an HTML5 video element so the browser can decode its frames.
- Browser metadata — duration, pixel dimensions, supported codec — is read and validated against the documented limits.
- The user's width and height are clamped to the 2–1920 even-integer range, with odd values reduced by one pixel for codec safety.
- Geometry is computed: either contain-style aspect-preserving math for Fit, or exact-request math for Stretch.
- Decoded frames are drawn onto a canvas sized at the computed dimensions.
- Any audio track exposed by the browser is captured alongside the video stream.
- MediaRecorder writes a WebM file at up to 30 fps using a supported VP9 or VP8 configuration.
- After recording completes, the finite duration is patched into the WebM via the shared audited Matroska duration writer, and a revocable object URL is exposed for download.
The canvas captureStream behaviour and MediaRecorder lifecycle are documented in the MDN canvas captureStream reference and the MDN MediaRecorder reference. Understanding those two browser APIs explains every behaviour the tool exhibits, from why frame timing can drift slightly to why the output is WebM and not MP4.
How to Resize a Video Locally With Video Resizer
The workflow takes three explicit decisions from you and one wait:
- Open the Video Resizer page and select a single supported local file. Supported types are MP4, WebM, MOV, M4V, and Ogg. Wait until the browser finishes loading metadata; if the file is too large, too long, or too high-resolution, the tool fails visibly rather than producing a misleading file.
- Enter a maximum width and a maximum height, both whole numbers. Choose Fit if you want the source aspect ratio preserved inside a bounding box, or Stretch if you want the exact width and height used regardless of distortion.
- Select Resize video. Encoding happens in real time, so keep the tab open and foregrounded until the recorder stops.
- When the recording finishes, the page exposes a download link for the generated WebM. Save it locally; the URL is revocable.
If the output looks wrong, re-check the mode. Stretch can squash circles into ovals; Fit will always preserve the source's proportional shape.
Fit vs Stretch: A Side-by-Side Comparison
The two modes solve different problems. The table below contrasts them on the axes a reader usually cares about.
| Property | Fit mode | Stretch mode |
|---|---|---|
| Treats inputs as | A bounding box (maximum width, maximum height) | Exact dimensions |
| Aspect ratio | Preserved from the source | Can be changed intentionally |
| Output size | Smaller of the two axis scales applied to source | Exact requested width × exact requested height |
| Distortion | Never distorts; never crops | Can distort the picture |
| Best for | Matching a maximum size while keeping proportions | Filling a fixed frame exactly, e.g. a 1920×1080 master |
A worked example makes the Fit math concrete. Take a 1920×1080 (16:9) source and request a 1280×1000 bounding box.
- Width scale = 1280 ÷ 1920 = 0.6667
- Height scale = 1000 ÷ 1080 = 0.9259
- Fit applies the smaller scale: 0.6667
- Output width = round even(1920 × 0.6667) = 1280
- Output height = round even(1080 × 0.6667) = 720
Fit therefore produces a 1280×720 file. The 1000-pixel ceiling is never reached because the height scale was larger; Fit shrinks to the more constraining axis. Had the ceiling been 1280×600, Fit would have applied the height scale (0.5556) and output 1066×600 instead. Stretch would have ignored both scale ratios and produced a literal 1280×1000 file, with the 16:9 source visibly stretched vertically.
Limits and Inputs You Must Respect
Every constraint below is part of the product contract; if any is violated, the tool fails visibly instead of producing a corrupt file.
| Constraint | Value |
|---|---|
| Source container | MP4, WebM, MOV, M4V, Ogg |
| Source size | Up to 500 MiB |
| Source duration | Up to 5 minutes |
| Source resolution per side | Up to 4096 pixels |
| Source area | Up to 3840 × 2160 pixels |
| Target width | 2–1920, even integer |
| Target height | 2–1920, even integer |
| Output container | WebM (VP9 or VP8) |
| Output frame rate | Up to 30 fps |
Odd target values are rounded down by one pixel because codec-safe even dimensions are more reliable in common browser encoders. This is a safety reduction, not a bug: a request for 1281×721 lands at 1280×720. Unsupported codecs, invalid dimensions, excessive source metadata, empty recorder output, and browser capability gaps all fail visibly rather than creating a misleading download.
When a Desktop Encoder Is the Better Choice
Browser-based resizing is fast, private, and dependency-free, but it does not replace a professional encoder. The contract is explicit: the tool does not upscale detail, remove black bars, crop a subject, preserve subtitles or multiple audio tracks, bypass DRM, or promise professional mastering. Real-time encoding introduces quality, bitrate, frame-timing, audio-layout, colour-metadata, and file-size differences from the source. The output is a real re-encode, not a metadata-only dimension change, which is why a freshly resized file can land at a noticeably different byte size than the original.
For frame-accurate delivery, long footage, required MP4 output, colour-managed workflows, or exact bitrate control, the right move is to use a dedicated desktop encoder such as FFmpeg, HandBrake, or Shutter Encoder. Video Resizer is the right choice when you need a quick local resize into WebM with predictable geometry, no upload, and no installation. Use only media you own or have the right to edit; that single rule sits underneath every other guarantee the tool makes.