A crop is reproducible when the rectangle, the source file, and the browser decoder are all unchanged between runs. The Video Cropper applies one fixed X/Y/width/height rectangle to every decoded frame, records only that region to an opaque Canvas at 30 frames per second, and saves the stream as a WebM, so feeding the same source file with the same coordinates produces the same cropped region in the output every time. Two extra conditions make the run truly repeatable: the rectangle must stay fully inside the decoded source so no frame is rejected or shifted, and the browser must stay the same because the MediaRecorder encoder is the first browser-reported WebM among VP9, VP8, and generic WebM. If any of those conditions change — the source file, the coordinates, the browser, or the codec the browser prefers that day — the bytes can shift even when the visible picture looks identical. The recorder's output is also patched with a finite Matroska Duration so the file plays with a stable duration across runs, and that writer is the same standards-tested one shared with the Video Compressor pipeline.
Why a Fixed Rectangle Is the Key to Repeatable Crops
Repeatability starts with geometry, not settings. The cropper draws one rectangle from the source frame's top-left corner: X moves the rectangle right, Y moves it down, width sets the horizontal extent, and height sets the vertical extent. Every value must be an untrimmed nonnegative whole pixel count, and width and height must each be at least two pixels. Because the rectangle is identical on every frame, a second run with the same numbers draws exactly the same pixels. If you need a rectangle that follows a moving subject, this is the wrong tool — the rectangle does not track people or objects, it applies the same crop to every frame for the entire decoded duration.
Coordinates also have to fit. The sum of X plus width and Y plus height must remain inside the decoded source, and the output area may not exceed 3840 × 2160 pixels. Any rectangle that fails one of these checks is rejected without shifting, clipping, rounding, or producing a partial file. That hard rejection is what keeps a repeat run from silently producing a different crop the second time around.
Inputs That Must Stay Identical Between Runs
Reproducing the same WebM means keeping several inputs locked. The cropper re-encodes the source locally, so any change in the source bytes or in how the browser decodes them can change the bytes the recorder writes. The table below lists the inputs that have to stay the same and what each one actually controls in the output.
| Input | What stays the same when you hold it constant |
|---|---|
| Source file (bytes, codec, duration) | The decoded frame sequence and the audio track the browser can capture |
| X, Y, width, height values | The exact pixel rectangle drawn into the Canvas on every frame |
| Browser and version | The MediaRecorder encoder choice (VP9, VP8, or generic WebM) and capturable audio behavior |
| Tab staying open during processing | Real-time recording duration, since a one-minute source takes about one minute to re-record |
| Source limits being respected on every run | The same decoded dimensions and duration available to the cropper |
The same coordinates on a different source do not produce the same picture. The same source in a different browser can still draw the same rectangle but record with a different WebM encoder, which changes the bytes even when the cropped picture looks identical.
How to Repeat the Same Crop Result in Your Browser
- Choose the same browser-decodable video you used before — an MP4, WebM, MOV, M4V, or Ogg file — and wait for its decoded dimensions to load in the Video Cropper.
- Enter the same X and Y pixel offsets and the same width and height values you used in the first run. Keep the values untrimmed, nonnegative, whole pixels, with width and height of at least 2, and the rectangle entirely inside the decoded source.
- Select Crop video and keep the tab open during real-time processing. Closing or backgrounding the tab can interrupt the MediaRecorder and produce a different file.
- When the recording finishes, download the WebM and review the full output before deleting the source.
- Confirm duration, crop, audio, and compatibility in the destination player. If a detail is off, follow the verification checklist in the Video Cropper accuracy guide before assuming the run drifted.
Repeating those steps with the same source, the same browser, and the same coordinates is what produces a repeatable WebM output. Anything that varies — a re-export of the source, a different browser tab profile, a different browser, or even a coordinate rounded to the nearest pixel — breaks the repeatability chain and is usually where "I got a different result this time" actually comes from.
What Changes When You Change Just One Number
A single change can keep the picture the same while shifting the bytes, or it can change the picture entirely. The cropper requests a bitrate derived from the cropped pixel area at 30 frames per second, bounded from 180 kbps through 8 Mbps. Make the rectangle smaller and the requested bitrate drops; make it larger and it climbs, up to the cap. The encoder is whatever the browser reports first among VP9, VP8, and generic WebM, so a different browser version may pick a different codec and produce a different file even with the same source and the same rectangle.
Audio is the other moving part. When the browser exposes an audio track through media capture, the tool appends it to the Canvas stream; when it does not, the output is silent. Support varies, the source may play audibly during real-time processing, and a repeat run on the same browser can include or drop audio depending on how the browser exposes the track that session. Subtitles, chapters, rotation tags, HDR signaling, color metadata, and most container features are not preserved, so the absence of those fields is not a sign of a bad crop — it is the documented behavior of the tool. Fast motion, noise, grain, source codec, and the browser encoder can all change size and quality between runs even when the rectangle is identical, which is why the tool's own documentation describes its bitrate setting as a disclosed single-pass browser setting rather than a guarantee of target size or visual quality.
Limits That Will Block a Repeatable Run
Some inputs stop the cropper before it starts, and a failed run is not a repeatable run. The tool shares an explicit video safety budget with Video Compressor, and every limit on that budget has to hold for every run you want to compare.
| Limit | Maximum allowed value |
|---|---|
| Source file size | 500 MiB positive |
| Decoded duration | Above zero and no more than five minutes |
| Source side | No side above 4096 pixels |
| Source area | No more than 3840 × 2160 |
| Output rectangle | Width and height each at least 2; X + width and Y + height inside the source |
| Output area | No more than 3840 × 2160 |
An accepted extension does not guarantee codec support, because decoding depends on the current browser. If a second run fails on a file the first run accepted, the difference is almost always the browser's codec support that day, not the cropper.
When the Same Settings Still Produce a Different File
Two WebM files from the same rectangle on the same source can still have different bytes when the browser encoder is different, the source is re-encoded between runs, the rectangle area pushes the bitrate to a different step inside the 180 kbps to 8 Mbps band, or the audio track is exposed differently that session. The fix is to record in the same browser version with the same source bytes, confirm the rectangle is byte-identical, and review both files end to end in the destination player before declaring them different in any meaningful way. The cropper does not promise byte-for-byte equality across runs; it promises the same drawn region when the inputs match, which is the practical definition of a repeatable crop.
Keep the original source until the entire output has been reviewed on every run. Object URLs, timers, recorder tracks, and playback are released by the tool on replacement, error, stale completion, or unmount, so a half-finished run cannot leak resources into a later one and quietly change what the next repeat run produces.
Related reading: How to Troubleshoot Problems When You Use Video Crop.