What "Repeatable Video Resize" Means
A repeatable video resize means producing the same output dimensions and the same visual geometry every time the same source file is paired with the same target parameters. When the resize runs locally in the browser with locked-in pixel dimensions, a fixed aspect mode (Fit or Stretch), and codec-safe even pixel sizes, the rescale step itself becomes deterministic. The same Video Resizer reuses the same canvas drawing path and the same MediaRecorder capture pipeline on every run, so the geometry you set is the geometry you get back. Differences between runs typically come from the source file, the encoder selection, or variable settings, not from the geometry math. The eight independent geometry fixtures built into the resizer cover landscape, portrait, square, same-ratio, bounding-box, stretch, and odd-dimension cases, and those fixtures are the reason the same numeric inputs produce the same numeric outputs across runs. That kind of consistency is what makes the resize a verifiable operation rather than a guessing game.
What Inputs Lock the Result In
Four inputs control the determinism of a browser-based video resize. First, the source file must be identical between runs — same codec, same pixel dimensions, same duration. Second, the maximum width and height you enter must be the same integers. Third, the aspect mode must stay the same, because Fit and Stretch produce different output geometry from identical inputs. Fourth, the encoder path must stay the same; because the resizer runs locally in the current browser tab, the encoder is the browser's built-in VP9 or VP8 WebM configuration rather than a server-side choice. Holding all four inputs constant is what lets you compare two outputs and trust that any difference came from the source rather than from the tool.
The tool processes each frame by decoding it, drawing it onto a resized canvas at up to 30 frames per second, capturing that canvas with the HTMLCanvasElement.captureStream API, and recording it through MediaRecorder. As long as those APIs behave the same way in your browser session, the geometry pass is repeatable.
Why Even Pixel Dimensions Matter for Repeatability
Browser WebM encoders behave more reliably when both output dimensions are even. The resizer rounds odd values down by one pixel so that width and height are always even before the canvas is captured. Each dimension must be a whole number from 2 to 1920 pixels, which means the smallest legal output is 2×2, not 1×1 or any odd value, and odd entries are clamped to even pixels before the encode starts. For example, a 16:9 source at 1280×720 entered into a Fit bounding box of 800×600 produces a scale of min(800/1280, 600/720) = min(0.625, 0.833…) = 0.625, giving an output of 1280 × 0.625 = 800 by 720 × 0.625 = 450 — already even, no rounding required. If the same source is paired with a target that would land on odd pixels, the odd values are reduced by one to land on a codec-safe even value. That forced rounding is part of why two runs against the same inputs return the same dimensions.
This is also the rule that keeps odd-dimension cases from drifting between runs. The fixture in the odd-dimension case is exactly the kind of input where, without the even-pixel clamp, a browser encoder could land on slightly different output widths or heights across sessions.
Fit Mode and Stretch Mode Produce Different Outputs
The mode you pick decides whether the source aspect ratio survives the resize. Fit treats the entered width and height as a bounding box and applies the smaller of the two scales, so the output ratio always matches the source ratio and the picture is never cropped. Stretch uses the requested width and height independently, so the output has those exact dimensions even when the source ratio does not match — which can intentionally distort the picture. The output of each run will be different geometry if you swap modes, even with identical source files and identical numeric targets.
| Aspect of the run | Fit mode output | Stretch mode output |
|---|---|---|
| Same-ratio source | Exact box dimensions, no rounding conflict | Exact requested width and height |
| Different-ratio source | Largest box fit, source ratio preserved | Exact width and height, picture may distort |
| Odd-pixel target | Dimensions reduced to even pixels | Both dimensions clamped to even pixel |
| Very small target | Scale approaches zero, source still fits the box | Distortion grows as ratio mismatch grows |
If you want a deterministic resize that does not change between runs, pick the mode once and keep it constant. Switching modes between runs is the most common reason two resizes of the same source produce different output geometry.
Resize a Video Locally and Match the Same Result
- Open Video Resizer in your browser tab and choose one supported local file: MP4, WebM, MOV, M4V, or Ogg. Wait for the browser to finish reading the metadata before moving to the next step.
- Enter the maximum width and height you want. Whole numbers from 2 to 1920 pixels. Note that the source must be at most 500 MiB, five minutes long, no more than 4096 pixels per side, and no larger than 3840×2160 pixels in area — values outside those limits cause the tool to fail visibly rather than produce a misleading file.
- Choose Fit to keep the source aspect ratio inside a bounding box, or Stretch to force the exact width and height. The choice is committed for this run; switching modes after the encode starts will produce a different result.
- Select Resize video. Keep the tab open during the real-time encode. The browser decodes the source, draws frames onto a resized canvas at up to 30 frames per second, captures the canvas, and records the output as a WebM using a supported VP9 or VP8 configuration.
- When the recorder finishes, download the WebM result. The finite duration is patched in by the shared audited Matroska duration writer so the file plays back end-to-end in standard players.
- To repeat the same result, run the same source through the same dimensions and the same mode in the same browser. Output dimensions will match across runs. Quality, bitrate, frame timing, audio layout, color metadata, and file size can still differ from the source and may shift slightly between runs because this is a real-time re-encode, not a metadata-only dimension change.
For a step-by-step walk-through of verifying that two outputs match, the verification workflow covers the same fixtures in more detail.
Verify the Same Result Across Multiple Runs
The fastest way to confirm that a resize is repeatable is to re-run the exact same inputs and compare the resulting geometry. Output dimensions can be read from the player or any container inspector — if the same Fit or Stretch input lands on the same width and height both times, the geometry pass is reproducible. Comparing file sizes is not a reliable check, because the WebM encoder can produce slightly different byte counts from identical geometry. Comparing pixel content at a frame level is a stronger check, but it depends on having a frame extractor and pixel diff tool handy.
The resizer's own eight geometry fixtures — landscape, portrait, square, same-ratio, bounding-box, stretch, and odd-dimension — exist so this kind of repeatability can be tested without hand-picked footage. If a fixture produces one output today and a different output tomorrow under the same inputs, the cause is almost always a different source file or a different browser session, not the resize math.
What Limits a Repeatable Run
A few inputs can quietly stop a repeatable run. Unsupported source codecs, sources with excessive metadata, and browser capability gaps all surface as a visible failure rather than a silent download — but a source that is just barely inside the limits can still produce a result that drifts between runs. Empty recorder output is also rejected rather than downloaded.
| Limit | Threshold | What happens if exceeded |
|---|---|---|
| Source file size | 500 MiB | Tool fails visibly instead of producing a file |
| Source duration | 5 minutes | Same — no misleading partial output |
| Source width per side | 4096 pixels | Same |
| Source area | 3840×2160 pixels | Same |
| Output dimension range | 2 to 1920 pixels, even, whole | Odd entries are reduced by one pixel to an even, codec-safe value |
| Frame rate | Up to 30 fps capture | Higher source frame rates are dropped |
The resizer is also explicit about what it does not do. It does not upscale detail, remove black bars, crop a subject, preserve subtitles or multiple tracks, bypass DRM, or promise professional mastering. It is also a local real-time re-encode rather than a metadata-only dimension change, so processing takes about as long as the video plays back. For frame-accurate delivery, MP4 output, color-managed workflows, exact bitrate control, or footage longer than five minutes, the contract points to a dedicated desktop encoder.
When a Local Browser Resize Is Not Enough
A local browser resize is the right tool when the goal is a repeatable WebM at known dimensions without uploading the source. It is not the right tool when the output has to be MP4, when the source has subtitles or multi-track audio that need to survive the encode, when the frame rate must exceed 30 fps, when the bitrate has to match a specific target, or when color-managed metadata is required. In those cases, the resizer contract recommends a dedicated desktop encoder instead of trying to force a real-time browser pipeline to behave like a mastering tool.
Used inside its limits, the resize step is deterministic enough to repeat. Holding the source, the dimensions, the mode, and the browser session constant is what makes the same result show up every time.
For a deeper look, see How Do I Troubleshoot a Problem When I Resize Video?.