Documenting a video resize procedure means writing down every input, constraint, and decision you make between loading a source file and downloading a finished WebM, so the same workflow can be repeated or audited later. A documented resize procedure for short clips is a four-part record: the source file's limits, the target width and height, the resize mode you chose, and the verification you perform after encoding. With the Video Resizer, all four parts happen in your current browser tab because the tool decodes, scales, and records the WebM locally rather than uploading the source. That local design is what makes the steps worth documenting in the first place, since anyone who runs the procedure later will reach the same output, on their own machine, without sending a file to a server. The rest of this guide explains each part of that record, the exact steps to perform, and what to write down so the procedure survives contact with a different video next week.
Why a documented resize procedure is worth keeping
A resize procedure is a small runbook, and like any runbook it is only useful if it captures the implicit decisions that would otherwise live in someone's head. When you write the steps down, you make the implicit explicit: which file format you accept, which dimensions you target, which mode you pick, and which verification you trust. Without that record, two people can produce very different WebM files from the same source by guessing at odd dimensions, picking the wrong mode, or skipping a size check. Documentation also lets you debug: when an output looks wrong, you can scan the written record to see whether the source, the requested dimensions, the mode choice, or the verification step was the source of the problem. The longer a procedure stays unwritten, the more it drifts as browsers update and as the people who run it change.
Source constraints to record before you touch any controls
Before the resize controls are useful, your procedure should record what the tool will and will not accept, because the answer determines whether the resize step is even the right step. The Video Resizer accepts MP4, WebM, MOV, M4V, and Ogg video. The source can be up to 500 MiB, up to five minutes long, no more than 4096 pixels per side, and no greater than 3840 × 2160 pixels in area. A documented procedure captures these as a single checklist line so the reader knows to convert or trim the source before reaching the resize controls. If the source fails any of those checks, the next step in the log should hand the file to a trimmer, cropper, or compressor rather than to the resizer, because no amount of documentation will make the tool accept a file that exceeds its own limits.
Pick the resize mode and write it into the procedure
The single biggest decision in any resize procedure is Fit versus Stretch, and the procedure should name the mode explicitly next to the dimensions so nobody has to guess later. Fit mode treats your width and height as a bounding box, applies the smaller of the two scales, preserves the source aspect ratio, and never crops. Stretch mode uses your requested width and height independently, so it produces the exact pixel dimensions you entered but can intentionally distort the picture. The trade-off is simple and worth recording: Fit is the safe default when the source ratio matters, and Stretch is the right choice only when the target dimensions are mandatory and any distortion is acceptable.
| Aspect of the run | Fit mode | Stretch mode |
|---|---|---|
| What your numbers mean | A bounding box | Exact target dimensions |
| Source aspect ratio | Preserved | Can change, may distort |
| Crops the picture | No | No |
| Distorts the picture | No | Yes, intentionally |
| Output dimensions vs requested | Smaller or equal | Equal only when both inputs are even, otherwise each odd value is rounded down to even |
| Best for | Social posts, mixed sources | Strict pixel specs, banners |
How to resize a video and document each step
- Open the Video Resizer in a fresh browser tab and choose one supported local file in MP4, WebM, MOV, M4V, or Ogg format. Wait for the browser metadata to finish loading before moving on, then record the file name, byte size, duration, and source dimensions at the top of the procedure log.
- Enter a maximum width and a maximum height, both as whole numbers between 2 and 1920 pixels. Odd values are rounded down to the nearest even pixel by the tool to keep the WebM encoder reliable, so the log should record the values the tool actually accepted, not only the values typed.
- Decide whether the run will use Fit or Stretch and write that decision into the procedure next to the dimensions. Fit is the default if the source ratio must stay intact inside a bounding box; Stretch is the right choice when the target dimensions are mandatory and any distortion is acceptable.
- Select Resize video and keep the tab open during the real-time encode. The browser draws decoded frames onto a canvas, captures the canvas at up to 30 fps, and records a WebM with any audio tracks it can read from the source. The procedure should state that processing takes about as long as the video itself, since this is a real re-encode rather than a metadata-only change.
- Download the finished WebM from the link the tool exposes, then run the verification checks immediately: confirm the file plays back, record its new byte size, note its actual width and height, and compare the source and target dimensions side by side in the log.
- Sign and date the procedure log entry. A single line such as "2025-03-14: clip-04.mp4, 1920x1080 source, Fit into 1280x720, output 1280x720 WebM, verified" is enough to make the run auditable later and to seed a reusable runbook.
Why even dimensions matter and how to record them
The Video Resizer reduces odd dimensions by one pixel before encoding, and that behavior belongs in the procedure rather than being left as folklore. If you enter 1281 as the width, the tool stores and encodes at 1280; if you enter 719 as the height, the encoder runs at 718. The reason is straightforward: common browser video encoders are more reliable with even pixel sizes, so the tool rounds down to the nearest even value rather than risk a misaligned output. Writing that rule into the procedure is more useful than skipping it, because the next person who reads the log will know that "what you typed" and "what the tool stored" can differ by a pixel when odd numbers slip in.
Worked example for the log:
- Source: 1920 × 1080 landscape clip
- Requested width: 1281
- Requested height: 720
- Step 1: 1281 is odd, so the tool reduces it to 1280.
- Step 2: 720 is even, so it stays at 720.
- Final encoded dimensions: 1280 × 720.
Documenting the rounding step means the next reader does not waste time looking for a missing two pixels.
Verification steps to record after the WebM lands
A procedure without a verification step is a wish, not a workflow. After the WebM downloads, the procedure log should capture four facts: the output file size, the actual output dimensions rather than the requested ones, the audio track count, and a one-line note about playback. The tool generates a finite-duration WebM through a shared audited Matroska duration writer, so the file should open in any modern player and end where the source ended. If any of those checks fail, the documented procedure now records a failure mode alongside the success cases, which is exactly what makes the runbook worth keeping for the next clip. For cross-checking canvas capture behavior in your own browser, the MDN canvas captureStream reference describes the underlying stream that the resize pipeline uses.
When to stop documenting this procedure and hand off to something else
This procedure covers the common case: a short, locally encoded video that needs new pixel dimensions and a WebM output. It does not cover frame-accurate delivery, long footage, a required MP4 output, color-managed workflows, or exact bitrate control. The tool also does not upscale detail, remove black bars, crop a subject, preserve subtitles or multiple tracks, or bypass DRM, and the procedure should not pretend otherwise. If the task needs any of those, the documentation should hand the job off to a dedicated desktop encoder rather than quietly hoping the browser tool will cover it. For everything else, the steps above are short enough to print, paste into a ticket, or keep beside the source folder as a reusable runbook. If the workflow starts to repeat across several projects, the same procedure can be lifted into a checklist that includes trimming, cropping, and compression alongside resizing, with the Video Resizer staying as the dedicated step for changing pixel dimensions.
For a deeper look, see Document the Steps to Extract a Video Frame.
For a deeper look, see Fix a Video Result That Looks Wrong After Resize.