To verify the result after you use a video crop, open the downloaded WebM in a separate player and confirm its dimensions, duration, audio track, and visible region match the rectangle you entered. A successful crop shows the exact in-frame pixel area you requested with no leftover edges, no missing audio, and a finite duration that matches the source. The output is recorded locally in your tab from a Canvas stream, so the file on disk is the same stream the tool produced. Open it in the destination player or editor where it will actually be used, not just the browser tab that generated it, because some players handle WebM duration metadata, audio routing, or codec selection differently. Also confirm the file is nonempty, the width and height reflect your X and Y inputs, and the playback length matches the source's decoded duration. Skipping this verification step is the most common reason a crop looks right during processing but fails when uploaded or shared, which is why the Video Cropper keeps every step local to the tab.
What counts as a verified result after a video crop
A cropped WebM passes verification when four properties line up with what you entered: pixel dimensions, visible rectangle, audio track, and finite duration. Pixel dimensions are the easiest to check and the easiest to get wrong, because width and height must each be at least two whole pixels and the rectangle must stay entirely inside the decoded source. If the source is 1920 × 1080 and you ask for X = 100, Y = 50, width = 800, height = 600, the file should report 800 × 600 with no border. The visible rectangle is checked visually, but the easier signal is whether the file dimensions equal the width and height fields you submitted rather than the source dimensions.
Audio is the property most often missed during verification. The tool appends audio only when the browser exposes a capturable track through media capture, and that support varies by browser and codec. If the source has sound and the result is silent, the browser simply did not expose a track for capture rather than the crop itself failing. There is no setting to force audio inclusion, so silence in the output is a signal that the browser path cannot capture the track. Subtitles, chapters, attachments, rotation tags, HDR signaling, and many container metadata fields are not preserved by design, so review the destination use case to confirm that loss does not matter for the file you are about to keep.
Duration is the property most players complain about. Streaming MediaRecorder output may omit a finite container duration, which is why the tool patches the WebM with a standards-tested Matroska Duration value in timestamp-scale ticks. After the patch, the file should report a finite duration close to the source's decoded duration. If a player shows 0:00, an infinite timeline, or refuses to seek, the file may have been opened before the patch finished writing, or the recorder may have produced a clip that did not pass the nonempty-blob check. For a deeper walkthrough of these accuracy signals, the accuracy guide for pixels, audio, and duration covers each property with concrete examples.
How to check the result after using video crop
The verification workflow follows the same real-time path the tool uses to produce the file, so each step also acts as a check that the previous step succeeded.
- Re-open the original source and wait for the decoded dimensions to load before touching any field, so the rectangle you re-enter is grounded in the actual source width and height.
- Re-enter the same X, Y, width, and height values you used during the crop, keeping the tab open long enough for real-time recording to finish, roughly one minute per minute of source.
- Download the resulting WebM through the link the tool offers once the recorder completes, and do not rename, remux, or rewrap it before inspection.
- Open the downloaded file in the player or editor where it will actually be used, and check the reported width, height, duration, and audio meter against the values you entered.
- Scrub to the first frame, the middle, and the last frame to confirm the rectangle stays inside the source for the entire clip, since the crop applies one fixed rectangle to every frame.
- Compare file size, audio presence, and seek behavior to the source. If the output reports the expected dimensions and a finite duration with sound, verification is complete and the original can be archived or deleted.
This loop catches the two most common failure modes: rectangles that drift outside the source on a later frame, and files that look fine in the recording tab but play as 0:00 in another player because the duration patch did not land. Running the same crop a second time only takes the time it takes to record, and the second pass is the cheapest confirmation that the first pass was reproducible.
Limits that change what the output can show
Several disclosed limits interact, and missing one turns a successful crop into an invalid rectangle at the form stage. The input budget caps positive files at 500 MiB, decoded duration above zero and no more than five minutes, no source side above 4096 pixels, and no source area above 3840 × 2160. The output budget caps the requested rectangle at an area no larger than 3840 × 2160. The X plus width and Y plus height sums must remain inside the decoded source, and every value must be an untrimmed nonnegative whole pixel count. Width and height must each be at least two pixels. An accepted file extension does not guarantee codec support, since decoding depends on the current browser, so a MOV that decodes in one tab may refuse in another.
Real-time processing ties record time to source duration: a one-minute source takes about one minute while the tab stays open. The bitrate the recorder requests is derived from cropped pixel area at 30 frames per second and bounded from 180 kbps through 8 Mbps, so larger rectangles push the bitrate toward the ceiling and smaller rectangles push it toward the floor. Fast motion, noise, grain, source codec, and browser encoder can change the resulting size and visual quality, which is why the bitrate is a disclosed setting rather than a guarantee of target size or quality.
Audio presence depends on whether the browser exposes a capturable track through media capture, and support varies by browser. The source may also play audibly during real-time processing, so verify in a setting where that playback is acceptable. The crop applies one rectangle to every frame; it does not track a moving subject or change the rectangle over time, so any frame where the rectangle leaves the source will produce a clipped or shifted image rather than a tracked crop.
Pre-crop plan versus the downloaded file
A short comparison makes the verification steps concrete. The left column is what you intended, and the right column is what to confirm in the file you downloaded.
| What you requested | What to check in the WebM |
|---|---|
| Rectangle of source pixels defined by X, Y, width, height | File reports width × height equal to those values, with no letterboxing |
| Source decoded dimensions shown after load | X + width ≤ source width and Y + height ≤ source height for every frame |
| Audio from the source clip | An audio track is present and audible in the player where the file will be used |
| Source decoded duration up to five minutes | Finite duration close to source, with seek working past 0:00 |
| First browser-reported WebM codec among VP9, VP8, and generic WebM | Destination player accepts the codec without remuxing or rejecting the file |
| Bounded bitrate between 180 kbps and 8 Mbps | File size and visual quality consistent with the requested rectangle area at 30 fps |
Use the comparison as a checklist rather than a calculation, since bitrate and file size depend on content and encoder. If any row on the right does not match the left, the verification has not passed and the original source should be kept until the gap is resolved.
Why the on-disk file is the real result
The crop is produced inside the browser tab, which is why the on-disk file is the only artifact that survives the verification step. Decode, Canvas crop, WebM recording, duration patching, and download all happen in the current tab, and the Canvas draws only the requested region at the cropped size as specified by the HTML canvas drawing model. After recording, the tool uses the WebM duration writer to parse Segment Info and TimestampScale and insert a big-endian Matroska Duration value, in line with the Matroska container format, and requires the result to remain nonempty and decode at the requested dimensions. Object URLs, timers, recorder tracks, and playback are stopped or released on replacement, error, stale completion, or unmount, so a file that was successfully offered for download is the same file the recorder produced, with no hidden post-processing applied later. That is why checking the result means inspecting the downloaded file rather than re-reading the recording tab.
Keep the original source until the entire output has been reviewed in the destination player, because the crop does not preserve subtitles, chapters, attachments, rotation tags, HDR signaling, or many metadata fields, and a second pass costs roughly the source's duration in real time. Once dimensions, audio, duration, and compatibility all match the values you entered, the verification is complete and the source can be archived with confidence.
For a deeper look, see How to Pick the Right Approach to Video Crop.