A video crop tool removes the outer area of every frame by re-recording a fixed rectangular region, and almost every export problem starts when those rectangles are not exact. A browser-based cropper like Video Cropper works by drawing the chosen X, Y, width, and height rectangle into a Canvas at 30 frames per second, recording that canvas with the browser's MediaRecorder as a WebM file, and offering the file for download. Because every step happens in real time and uses whole-pixel math, small errors in the inputs become a failed crop, a clipped rectangle, or an output that no player can open. Other problems come from expecting the tool to do what it was never built to do, such as tracking a moving subject or carrying over every metadata field the source had. Knowing where the tool draws its lines, and where it does not, is the difference between a clean WebM that is ready to publish and one that has to be redone. This guide covers the mistakes that show up most often when using Video Crop, why each one happens, and how to avoid it the first time.
How a Browser Video Cropper Actually Works
The crop pipeline has no hidden steps. Video Cropper loads a file the browser can decode, waits for the decoded width and height to populate, and then asks for four numbers: the X offset, the Y offset, the width, and the height. When you press Crop video, the source plays locally and a Canvas is created whose dimensions match the rectangle you asked for. The fixed source rectangle is drawn into that Canvas on every frame, an audio track is appended to the canvas stream when the browser exposes one through media capture, and a MediaRecorder saves the stream as WebM. Once the source finishes playing, the tool patches a finite Matroska Duration into the container so the file has a real duration instead of the streaming placeholder that MediaRecorder normally produces. Object URLs, timers, and tracks are released when the run ends or the component unmounts. Everything happens in your tab, so the same constraints that govern the inputs also govern the output.
Coordinate and Rectangle Mistakes That Fail the Crop
The most common crop failures are not creative decisions at all. They are off-by-one mistakes in the four coordinate fields. Every value must be an untrimmed nonnegative whole pixel count, the width and height must each be at least two pixels, X plus width cannot exceed the source width, and Y plus height cannot exceed the source height. If any of those rules is broken, the rectangle fails without shifting, clipping, rounding, or producing a partial file. People often try to enter decimal values from a design tool, paste coordinates with a trailing space, or copy X and Y from a player that uses center origin instead of top-left origin. The tool reports the failure and stops, so a wrong crop never silently turns into a wrong output. The fields behave as follows:
| Field | Meaning | Common mistake |
|---|---|---|
| X | Pixel offset from the top-left corner, moving the rectangle right | Using a center-origin value instead of a top-left offset |
| Y | Pixel offset from the top-left corner, moving the rectangle down | Confusing Y with height or using a value from a different frame size |
| Width | Horizontal extent of the crop in source pixels | Setting width so X + width overshoots the right edge |
| Height | Vertical extent of the crop in source pixels | Setting height so Y + height overshoots the bottom edge |
Two interacting limits also sit behind those fields. The output area must not exceed 3840 by 2160 pixels, so a rectangle that is fine in pixel terms can still be rejected on a 4K monitor if you push past that ceiling. No source side may exceed 4096 pixels, and no source area may exceed 3840 by 2160 either, which means a very tall vertical clip can be refused even when its width is modest. Reading the decoded source dimensions first, then picking a rectangle that stays inside them, prevents the vast majority of coordinate mistakes.
Input Mistakes: Files, Formats, and Decoded Dimensions
Accepted file extensions do not guarantee that decoding works, because the underlying codec support depends on the current browser. MP4, WebM, MOV, M4V, and Ogg are all allowed, but a QuickTime file with a ProRes or HEVC track may not decode in a browser that lacks those codecs. Picking the wrong file is rarely visible until the dimensions fail to load or stay stuck at zero. There is also a shared safety budget on every accepted source: positive files up to 500 MiB, decoded duration above zero and no more than five minutes, no source side above 4096 pixels, and no source area above 3840 by 2160. A six-minute clip, a 4K side that is taller than 2160, or a two-gigabyte 4K file can all be refused by the same gate. Waiting for the decoded width and height to display before entering coordinates prevents the next common mistake, which is reading stale numbers from a previous run or a thumbnail and trying to crop a file that has not finished loading.
Output Mistakes: Audio, Metadata, and the Real-Time Recording Step
Most output problems come from features the crop is not designed to deliver. The crop is a single-pass browser recording, not a non-destructive edit, so it does not preserve subtitles, chapters, attachments, rotation tags, HDR signaling, or color metadata. Audio is appended to the canvas stream only when the browser exposes a capturable track through media capture, which means support varies and the source may play audibly in the tab during real-time processing. People often expect a silent source to become a silent WebM, or expect a captioned source to keep its captions, and both assumptions lead to a result that has to be redone. If the output already looks wrong and you need a recovery path, the Fix a Cropped Video Result That Looks Wrong walkthrough covers the diagnostic steps.
Recording happens in real time, so a one-minute source takes about one minute, and a five-minute source takes about five minutes, while the tab stays open. Closing the tab, switching profiles, or letting the system lock the screen can interrupt MediaRecorder and leave you with a file that has no finite duration. The recorder picks the first browser-reported WebM codec it can find among VP9, VP8, and generic WebM, so the file is always WebM but the exact codec is not negotiable. Requested bitrate is derived from the cropped pixel area at 30 fps and is bounded between 180 kbps and 8 Mbps; this is a disclosed browser setting, not a guarantee of target size or visual quality, because fast motion, noise, grain, source codec, and the browser encoder all change the final bytes. Treat the original file as the source of truth until you have reviewed the entire output, frame by frame and on the destination player.
How to Crop a Video Correctly With Exact Pixels
Use the same four-step flow and let the tool reject anything that is wrong before you record.
- Open Video Cropper in your browser and choose a browser-decodable video such as an MP4, WebM, MOV, M4V, or Ogg file. Wait for the decoded source dimensions to appear before you touch the coordinate fields.
- Enter the X offset, Y offset, width, and height as whole nonnegative source pixels. Confirm X plus width is at most the source width and Y plus height is at most the source height, then confirm width and height are each at least two pixels and the output area is at most 3840 by 2160.
- Select Crop video. Keep the tab open and do not switch profiles or lock the screen while the source plays back in real time and the Canvas stream is recorded as WebM.
- Download the WebM, play it in the destination player, and verify duration, crop, audio, and codec support end to end. Only delete the original after you have confirmed the full result.
To sanity-check the math, suppose the source is 1920 by 1080 and you want a centered 1280 by 720 rectangle. The horizontal offset is (1920 − 1280) divided by 2, which equals 320 pixels. The vertical offset is (1080 − 720) divided by 2, which equals 180 pixels. X plus width is 320 plus 1280, which equals 1600 pixels, and that is at most 1920. Y plus height is 180 plus 720, which equals 900 pixels, and that is at most 1080. The output area is 1280 times 720, which is 921,600 pixels, well under the 3840 by 2160 limit. Those four fields pass every gate, so the recording step is safe to start.
When the Mistake Means You Need a Different Tool
Some failures are not crop failures at all, they are mismatches between the task and the tool. Crop changes only the visible frame region and applies one fixed rectangle to every frame, so it cannot trim by time, resize the pixel dimensions without cropping, compress a file for size, blur or redact an object, or track a moving subject. A request to cut the first ten seconds belongs to Video Trimmer. A request to shrink a 4K clip to 1080p without losing the edges belongs to Video Resizer. A request to shrink the file size while keeping the full frame belongs to Video Compressor. A request to pull a single frame as an image belongs to the frame extractor. Picking the right tool for the real task is the last mistake this guide is designed to prevent.
If you're weighing options, Common Video Compression Mistakes and How to Avoid Them covers this in detail.