Video cropping in a browser tab can fail at five distinct points: coordinate validation, source-file decoding, real-time recording, WebM container assembly, and metadata preservation. A crop operation that looks successful may still produce a WebM without a finite duration, lose every subtitle track, drop audio the browser will not expose through media capture, or run afoul of a 3840 × 2160 pixel ceiling on the cropped area. The fastest way to predict what goes wrong is to read the failure surface in order: what the tool checks before it records, what the browser can decode, how long real-time processing takes, what the WebM recorder emits, and what the crop operation explicitly does not preserve. Because the source plays locally during recording, any tab refresh, navigation, or backgrounding breaks the stream mid-file and produces a partial download. Understanding this chain lets you avoid the most common failure modes before you press Video Cropper's Crop video action.
Why a Browser-Based Crop Changes the Failure Surface
Most public guides about video cropping describe desktop editors, server-side processors, or upload pipelines. A browser-based crop tool draws on a different failure surface because the entire pipeline — decode, Canvas draw, MediaRecorder capture, container fix-up — runs inside the current tab on top of HTML Canvas drawImage. There is no server round trip, but there is also no error recovery beyond what the browser exposes. A failure that a desktop app would surface as a non-zero exit code can manifest as a partial WebM blob, an unset duration, or a silent audio drop. Reading the failure surface in order — input checks, decode, real-time record, container write — turns a vague "what went wrong" into a specific layer you can target.
Coordinate Errors That Stop the Crop Before Recording
The crop is applied as one fixed rectangle to every frame, and the tool refuses to shift, clip, or round when the rectangle does not fit. Every coordinate is parsed as an untrimmed whole pixel, which means a stray space, a half-pixel value, or a leading minus sign fails the rectangle without producing a partial file. X and Y are offsets from the source frame's top-left corner; X moves right, Y moves down. Width and height must each be at least two pixels, and X plus width and Y plus height must stay inside the decoded source rectangle. The output area may not exceed 3840 × 2160 pixels, even when the source is larger.
| Parameter | Meaning | Hard limit |
|---|---|---|
| X | Horizontal offset from top-left | Nonnegative integer; X + width ≤ source width |
| Y | Vertical offset from top-left | Nonnegative integer; Y + height ≤ source height |
| Width | Horizontal extent of the crop | Integer ≥ 2; X + width ≤ source width |
| Height | Vertical extent of the crop | Integer ≥ 2; Y + height ≤ source height |
| Output area | Width × Height of the result | ≤ 3840 × 2160 pixels |
An invalid rectangle fails before recording starts. If the form accepts the numbers but the action button refuses, the failure is almost always one of these constraints, not a codec issue. Re-check the four fields, not the file.
Source File Limits That Silently Block Decoding
The crop shares the same input safety budget as other local video tools. A file is accepted by extension only; the actual decode depends on what the current browser can read. The MP4, WebM, MOV, M4V, and Ogg containers are all permitted, but an accepted extension does not guarantee codec support, and the tool exposes decoded dimensions only after the browser finishes parsing the file. Sources larger than 500 MiB, sources with a decoded duration longer than five minutes, sources with a side longer than 4096 pixels, and sources whose total area exceeds 3840 × 2160 pixels are all rejected up front. A source whose decoded duration is zero is also rejected. If dimensions never appear after you pick a file, the most likely cause is a codec the browser cannot decode rather than a malformed rectangle.
| Source input budget | Limit |
|---|---|
| Positive file size | ≤ 500 MiB |
| Decoded duration | Above 0 and ≤ 5 minutes |
| Source side | ≤ 4096 pixels |
| Source area | ≤ 3840 × 2160 pixels |
Output Container Risks: Duration, Audio, and the WebM Stream
Recording happens in real time against a Canvas stream at 30 fps, then the result is handed off to the first browser-reported WebM recorder among VP9, VP8, and generic WebM. Because MediaRecorder output may omit a finite container duration on its own, the tool follows the recorder with the same standards-tested WebM duration fixup used by the Video Compressor: it parses Segment Info and TimestampScale, then inserts a big-endian Matroska Duration value in timestamp-scale ticks so the file reports a real playback length. The Matroska container format defines those fields, and the resulting WebM must remain nonempty and decode at the requested dimensions, otherwise the result is rejected. Requested bitrate derives from the cropped pixel area at 30 fps and is bounded from 180 kbps through 8 Mbps; this is a single-pass browser setting, not a guarantee of target size or visual quality. Fast motion, noise, grain, source codec, and the browser encoder can shift the actual size in either direction. Audio is included only when the browser exposes a capturable audio track through media capture, which means a silent source may stay silent and a capturable track may still be dropped on a browser that refuses to route it. The source may play audibly during real-time processing, so use headphones or mute the tab if you do not want it to bleed into a recording.
What Video Cropping Deliberately Does Not Preserve
The crop changes the visible frame region; it is not a trim-by-time, resize, compress-only, redact, blur, or object-removal tool. Subtitles, chapters, attachments, rotation tags, HDR signaling, and most color metadata are not preserved. One fixed rectangle is applied to every frame, so the tool does not track a moving subject or change the rectangle over time. That single-rectangle behavior is the right choice when the unwanted edges are static throughout the clip or when a platform requires a known frame, but it is the wrong choice when the subject drifts or when the unwanted region grows or shrinks during the clip. Review both sound and picture, and confirm duration, crop, audio, and compatibility in the destination player before deleting anything. When a crop comes out wrong rather than failing, the recovery path usually lives in fixing the output rather than retrying the same coordinates.
How to Crop a Video Locally With Exact Pixels
The pipeline that avoids most of the failure modes above is short. Pick a file the browser can decode, calculate coordinates that stay inside every frame, leave the tab open during real-time processing, then download and review the WebM before deleting the source.
- Choose a browser-decodable video (MP4, WebM, MOV, M4V, or Ogg) and wait for its source dimensions to load into the form.
- Enter whole-pixel X, Y, width, and height values that stay inside every source frame, with width and height each at least two pixels and a total area at or below 3840 × 2160 pixels.
- Select Crop video, keep the tab open during real-time processing, and plan for the recording to take roughly the same time as the source duration.
- Download the resulting WebM and fully review duration, crop, audio, and compatibility in the destination player before deleting the original.
Verifying the WebM Before You Delete the Source
Verification is the last line of defense against silent metadata loss. Open the WebM in the player that will actually host it and confirm the playback length, the cropped region, the audio presence, and the absence of platform-specific surprises such as a missing finite duration, a stripped subtitle track, or an unsupported codec. Keep the original file until the entire output has been reviewed. Object URLs, timers, recorder tracks, and playback are stopped or released on replacement, error, stale completion, or unmount inside the tool, so leaving the tab does not leak resources, but a partial file from a closed tab will not recover. Treat the source as the only guaranteed-good copy until you have watched the output end to end in its destination player.
For a deeper look, see Fix a Result That Looks Wrong After Trimming a Video.