Crop image to box

This validator accepts the source image width and height together with an explicit crop box described by x, y, width, and height. It checks every value, confirms that the complete rectangle stays inside the image, and returns the cropped dimensions when the box is valid. No image upload or decoding is required, so it is useful before invoking an image processor, building a crop preview, or accepting crop coordinates from another service.

Describe the source image and crop box

Start with the source image dimensions in pixels. Set image_width to the full horizontal pixel count and image_height to the full vertical pixel count. Then describe the crop rectangle with x, y, width, and height. The x and y values locate the rectangle's top-left corner relative to the image's top-left corner, which is coordinate 0,0. Width extends to the right and height extends downward. All six values must be integers because the capability models pixel-aligned raster cropping rather than fractional geometry. Image and crop dimensions must be positive, while x and y may be zero. For example, an x value of 240 skips the first 240 pixel columns before the crop begins. A box may touch any image edge exactly. Thus, x plus width may equal image_width, and y plus height may equal image_height. Supply the dimensions reported by the same image asset that will later be cropped; coordinates from a resized preview will not describe the original unless they have first been scaled.

Understand how boundary validation works

The validator first rejects missing values, non-integers, negative coordinates, zero-sized boxes, and values outside the documented numeric range. It then checks the two boundaries that define containment. Horizontally, x plus width must be less than or equal to image_width. Vertically, y plus height must be less than or equal to image_height. If either sum is larger, part of the requested crop lies outside the source and the request returns an invalid input error. This explicit containment rule avoids a common off-by-one misunderstanding: a 100-pixel-wide crop beginning at x 0 occupies columns from the left edge through the complete 100-pixel span, so it fits a 100-pixel-wide image exactly. The capability does not clamp, shift, or shrink an invalid box because silently changing user coordinates can produce the wrong subject or composition. It also does not inspect image bytes. Its decision is determined solely by the dimensions and coordinates supplied, making the result fast, repeatable, and suitable for validation in both interactive forms and automated pipelines.

Use the result before an actual crop operation

A successful response returns the width and height of the resulting crop. Those values match the requested box because this capability validates geometry; it does not resample or alter the rectangle. Use the response as a guard before passing the same coordinates to an image manipulation library, a media service, or a queued rendering job. This separates inexpensive input validation from more expensive image decoding and prevents predictable boundary failures from reaching downstream workers. In a crop editor, validate after the user confirms a selection or after preview coordinates have been converted back to original-image pixels. In a data pipeline, validate crop metadata as soon as it arrives and route invalid records for correction. Keep orientation in mind: if another step physically rotates an image, use the dimensions after that rotation and coordinates expressed in the same orientation. The API request costs $0.002; the browser runner can perform the same deterministic calculation locally. Neither path uploads an image because only numeric geometry is needed for the answer.