Video cropper accuracy means producing a downloaded crop whose every frame matches the requested X, Y, width, and height pixel rectangle, plays for the same duration as the source, and includes audio only when the browser can capture it. The rectangle applies to every frame at the same coordinates, so a moving subject cannot be tracked — the cut is a fixed spatial crop, not a time-based trim. Accuracy also covers the integrity of the output container: a recording that streams indefinitely without a finite duration is not a finished file, even if the picture looks correct. Local browser tools like Video Cropper draw the requested region into an equal-size Canvas at 30 fps, record the result as WebM, and patch in a finite Matroska Duration, which is the chain that defines an accurate crop from the moment you press Crop to the moment the file lands on disk. Anything that drifts between the source rectangle and the saved file — a shifted crop, a clipped edge, a rounded coordinate, or a missing timestamp — is a loss of accuracy, even when the picture looks acceptable on a quick preview.

What "Accuracy" Means in a Video Cropper
Pixel accuracy in a video cropper rests on five independent properties, and missing any one of them turns a "good enough" preview into a misleading file. The first property is coordinate fidelity: the saved region must sit at exactly the X, Y, width, and height pixels the user requested, with no rounding, no clipping, and no fractional offsets. The second is rectangle integrity across frames: the same rectangle must apply to every decoded frame, from the first to the last, so a static edge stays static throughout the file. The third is duration integrity: the output must report a finite Matroska Duration in timestamp-scale ticks, not an unbounded recording that loops or plays indefinitely. The fourth is audio fidelity: when the browser can expose a capturable audio track through media capture, the output should carry that audio with the picture; when it cannot, the output should drop audio rather than fabricate silent noise. The fifth is container honesty: subtitles, chapters, rotation tags, HDR signaling, and attachment metadata may not survive, and an accurate tool does not pretend they have been preserved.
These five properties — coordinate fidelity, per-frame rectangle stability, finite duration, capturable audio, and declared metadata losses — define accuracy. A cropper that produces a beautiful preview but rounds half-pixels, loses the final second, drops audio silently, or saves an open-ended stream has been inaccurate even when the picture looks right. Reviewers who only eyeball the center of the screen miss exactly these failures, which is why duration checks, edge-pixel spot checks, and audio spot checks belong in any accuracy review.
How Video Cropper Achieves Pixel-Exact Results
Video Cropper chains five audited gates so the saved file matches the requested rectangle. The first gate is the decoded-dimension gate: the tool waits for the browser to decode the source and report whole-pixel width and height, so the X, Y, width, and height inputs always reference real numbers. The second gate is the coordinate parser: every input is read as an untrimmed whole-pixel integer, with nonnegativity enforced on X and Y, a minimum of two pixels on width and height, and a rectangle that must stay entirely inside the decoded source. Invalid rectangles fail without shifting, clipping, rounding, or producing a partial file, so an inaccurate request cannot leak into the output.
The third gate is the Canvas draw step. The tool draws the requested source rectangle into an opaque Canvas sized exactly to the crop at 30 fps, per the WHATWG HTML Canvas drawImage specification, which means no resampling, no resize, and no sub-pixel positioning. The fourth gate is the MediaRecorder step: the tool requests a bounded video bitrate derived from the cropped pixel area, capped from 180 kbps through 8 Mbps, then asks the browser for the first supported codec among VP9, VP8, and generic WebM. Audio is appended only when the browser exposes a capturable track through media capture. The fifth gate is the duration writer: because streamed MediaRecorder output may omit a finite container duration, the tool parses Segment Info and TimestampScale from the produced WebM and inserts a big-endian Matroska Duration in timestamp-scale ticks, following the structure documented in the Matroska Media Container Format. The result must remain nonempty and decode with the requested dimensions before the file is offered for download.
How to Crop a Video With Pixel Accuracy
- Open Video Cropper and choose a browser-decodable source — MP4, WebM, MOV, M4V, or Ogg — then wait for the decoded width and height to load. The defaults select the full frame.
- Read the decoded dimensions, then enter X and Y as whole-pixel counts from the source's top-left corner and set width and height to the exact rectangle you want. X moves right, Y moves down, width controls horizontal extent, height controls vertical extent; width and height must each be at least two pixels, and X plus width plus Y plus height must all stay inside the source. Output area must not exceed 3840 × 2160 pixels.
- Select Crop video and keep the tab open during real-time processing. Processing plays the source locally and re-records the rectangle, so a one-minute source takes about one minute. Do not switch tabs or close the window until the download is offered.
- Download the WebM and review it in the destination player before deleting the original. Confirm the duration matches the source, the crop sits at the requested coordinates, the edges do not bleed, and audio plays when the browser captured a track.
If the inputs are rejected, fix the coordinates before retrying — the tool fails closed rather than producing a partial file, which is the safer side of accuracy for any clip you plan to keep.
Limits That Affect Accuracy
The accuracy chain has hard edges that change whether the tool can complete the task. Source limits come from the browser's shared video safety budget; output limits come from Canvas sizing and the recorder's bitrate ceiling. Both must be respected for the output to remain pixel-exact.
| Limit | Value | Why it affects accuracy |
|---|---|---|
| Source file size | Up to 500 MiB | Larger files exceed the safety budget and are refused before decoding. |
| Source duration | Above 0, at most 5 minutes | Decoded duration is checked; zero-duration sources are not processed. |
| Source side length | No side above 4096 pixels | Sides beyond the browser's decode ceiling cannot be measured, so coordinates cannot be validated. |
| Source area | No area above 3840 × 2160 | The Canvas and decoder share this area ceiling. |
| Crop dimensions | Width and height at least 2 pixels | Sub-2-pixel crops are rejected; this prevents fractional or zero-area outputs. |
| Offsets | X, Y nonnegative, whole pixels | Negative or fractional offsets are not parsed, which keeps the rectangle inside the source. |
| Output area | No larger than 3840 × 2160 | Caps Canvas size; oversized requests fail before recording starts. |
| Frame rate | 30 fps fixed | The Canvas is drawn at 30 fps, so temporal accuracy is uniform across frames. |
| Video bitrate | 180 kbps through 8 Mbps | Bounded from cropped pixel area; size and visual quality depend on motion, codec, and browser encoder. |
| Container duration | Finite Matroska Duration | Streamed output without this is not a finished file. |
Any request that touches one of these edges returns an error and produces no file. That is intentional: a refused job is more accurate than a shifted, clipped, or partial one.
When Pixel Accuracy Matters Most
Pixel accuracy matters most when the destination expects a known frame region — a social platform with a strict in-frame requirement, an archival workflow that has to match a reference crop, or a deliverable where unwanted edges (letterboxing, watermarks, mic shadows) are static throughout the clip. It matters less when the destination accepts arbitrary framing and the only goal is to remove an outer band; in those cases a coarse crop still works, but the same accuracy discipline keeps the output predictable.
The tool applies one rectangle to every frame, so the rectangle cannot follow a moving subject. If the unwanted edge slides because the camera pans or the subject moves, the rectangle must be sized to cover the worst-case position across the clip — accuracy in a single-frame snapshot is not accuracy across the whole timeline. For repeatable jobs, store the X, Y, width, and height values alongside the output so a second pass produces the same rectangle; the values are the contract, and the file is the evidence.
For reviewers, accuracy is closed by spot checks: play the WebM in the destination player, scrub to the first frame and the last frame, confirm the crop edges do not shift, and confirm the audio plays when the source had sound. Keep the source until every check passes, because streamed recordings can drift in size and quality with motion, noise, grain, source codec, and the browser's encoder, and only a side-by-side review confirms the saved rectangle matches the requested one.