Whole-pixel crops with the rectangle typed or dragged, checked by decoding the output and comparing it with the pixels that went in. Quarter turns and mirrors are exact permutations, so nothing is clipped.
Initializing in your browser…
Turn an image into a data URL whose payload is decoded again and compared byte for byte with the file, with the media type taken from the file's own signature rather than its extension and the size cost of embedding stated in full.
Compare two images with a perceptual engine (pixelmatch) that ignores anti-aliasing, or an exact byte engine. Groups changes into regions with bounding boxes, reports SSIM, and handles size mismatches with an explicit policy.
Resize with the filter named (Lanczos, Mitchell, Catmull-Rom, bilinear, box or nearest) and the option to average LIGHT rather than stored bytes, which is worth 1.24 stops on a detailed picture.
Take a 150 by 150 square out of a 400 by 300 picture, and find out whether the pixels survived.
Input
xy-grid.png 400 x 300 · rectangle 150 x 150 at (125, 75) · PNG out
Output
Every pixel inside the rectangle came out exactly as it went in largest single-channel difference: 0 · 150 x 150 · image/png Same rectangle as JPEG at 92: differs by up to 70 levels on 17,691 of 22,500 pixels
The rectangle is copied out of the decoded picture, encoded, and then decoded again and compared with what went in, so the verdict is a measurement. PNG comes back with a largest difference of exactly 0. JPEG does not, and the page says which pixels moved and by how much rather than repeating the usual claim that cropping is lossless. Turn the picture a quarter first and the working picture becomes 300 by 400: sizing it from the operation is what stops the old behaviour, which squeezed the turned image back into a 400 by 300 frame and left a crop at the edge 33.3 percent empty.
A crop discards the pixels outside the rectangle and keeps the ones inside it unchanged. That is the claim, and this page checks it rather than asserting it: the rectangle is copied straight out of the decoded picture, the output is encoded, and then the output is DECODED AGAIN and compared with the rectangle pixel by pixel. When the largest single-channel difference is 0, the page says every pixel came out exactly as it went in. When you choose a lossy format it says the opposite, with the number of pixels that moved and by how much. The rectangle is always a whole number of pixels. That sounds obvious and it is where the old version of this tool went wrong: on a 301 by 199 picture the default selection was 99.5 pixels wide, the panel rounded it to "100px" on screen, and the canvas truncated it to 99, so the number displayed and the file delivered were two different pictures. Width, height and both coordinates can now be typed as well as dragged, which is what "pixel-precise dimension input" has to mean.
Crop to the exact dimensions a platform expects, with the rectangle typed rather than dragged towards.
Quarter turns and mirrors are exact, so orienting a picture costs nothing at all.
Trim to a standard frame and confirm from the verdict panel that the pixels inside it are untouched.
Circle, hexagon, star and four more, saved as PNG or WebP so the area outside the shape stays transparent.
Quarter turns and mirrors are exact permutations of the pixels: every output pixel IS an input pixel, moved, so nothing is averaged or interpolated. The page performs them as permutations and sizes the working picture from the operation, which is the part that matters. A quarter turn swaps width and height, and the old version rotated inside a canvas that kept the source dimensions: a 400 by 300 turned a quarter became a 300 by 400 picture squeezed into a 400 by 300 frame, so 50 columns were lost from each side and a crop at the edge came out 33.3 percent empty. The working picture is now 300 by 400 and all of it can be reached. Four quarter turns return the original bytes exactly, and every turn and mirror is checked against Pillow's own transpose with zero pixels different.
Three output formats are offered, and only three, because a browser canvas can write only three: PNG, WebP and JPEG. PNG is the default and is the lossless path. WebP and JPEG re-encode, and the verdict panel says so with the measurement rather than leaving you to assume.
For a JPEG source there is one more thing worth knowing, and the page says it. A JPEG stores 8 by 8 blocks grouped into minimum coded units, 16 by 16 pixels when chroma is subsampled 4:2:0, which is what cameras and browsers write. A crop whose origin lands on that grid can be performed in the CONTAINER, moving the entropy-coded blocks without decoding them, which is what jpegtran does and is genuinely lossless in the JPEG sense. This page re-encodes rather than doing that, so it tells you whether your rectangle would have allowed a container crop, because that is the difference between "no lossless option existed" and "one existed and this tool did not take it".
A colour profile does not survive, and neither does any other metadata: the picture goes through a canvas and comes back as bare pixels. The browser converts a wide-gamut source into sRGB as it draws, so the appearance is kept and the gamut is not.
Not in PNG. The rectangle is copied out of the decoded picture and the output is compared with it after encoding: the largest channel difference is 0 and the page says so. In WebP or JPEG the pixels inside the rectangle are re-encoded, which does change them, and the page reports how many moved and by how much.
Yes, all four numbers: width, height, X and Y. They are whole pixels by construction, so what the panel shows and what the file contains are the same numbers.
Because a quarter turn swaps width and height. A 400 by 300 becomes a 300 by 400. The working picture is resized to fit the turned image, so nothing is clipped and all of it can be cropped.
It can be, but not here. A crop whose origin sits on the JPEG minimum coded unit grid (16 by 16 pixels with the usual chroma subsampling) can be done in the container by moving the coded blocks, which is what jpegtran does. This page decodes and re-encodes, so it tells you whether your rectangle would have allowed a container crop rather than leaving the question unasked. For a lossless result here, save as PNG.
They are lost, because the picture goes through a canvas. If the source carries an EXIF Orientation tag the browser has already applied it, so the working picture is the right way up and any turn you add is on top of that; the page names the tag when there is one.
Images are decoded, edited, and exported entirely inside this browser tab. No originals, exports, or metadata are uploaded.