What happens between the box you drag and the file you get

The editor draws on a preview; the cut is made on the original. Here is how the two are kept in step.

4 min read

The preview is never the thing being cut

A ten-megapixel photograph does not fit on a laptop screen, so the editor shows you a scaled copy. The temptation is to crop that copy and hand it over, and it is the wrong answer twice: you would lose almost all of the resolution you started with, and the result would be a picture of a preview.

Instead the box is stored in the coordinates of the original file from the moment you let go of the mouse. The canvas is the only place preview pixels exist, and it converts at its own edge — everything downstream of it, including the numeric fields you can type into, is already in full-size pixels.

That is also what makes the numbers on screen worth reading. The width shown beside the box is the width of the file you are about to download, not of a rectangle on your monitor.

Sideways photographs

A phone rarely rotates a photograph when it saves it. It writes the pixels the way the sensor read them and adds a tag saying which way up the result should be shown. Browsers honour that tag, which means the image you dragged a box across may not match the image as it is stored.

So the orientation is applied before anything is cut. The pipeline turns the picture the way a viewer would, and only then extracts the region — because that turned picture is the one the box was drawn on. Extracting first and turning afterwards cuts a photograph in a coordinate system nobody ever saw.

The four orientations that swap the sides are handled explicitly rather than hoped for: when the tag says the width and height are exchanged on display, the bounds the box is checked against are exchanged too.

One box, many images

Select several files and the same rectangle is applied to all of them, which is the point when you are cropping a set of screenshots or a series shot on a tripod. It also means the rectangle can hang off the edge of a file that is smaller than the one you drew it on.

Rather than fail the batch, each file gets the box intersected with its own bounds: rounded to whole pixels, trimmed at the edges, and used as far as it reaches. Only when nothing at all overlaps is that one file refused, with a message saying the area lies outside it. The rest of the batch is unaffected.

The same check runs regardless of where the request came from. Coordinates arrive over HTTP and could say anything at all, so the editor clamping as you drag is a convenience rather than a defence.

Undo that steps over gestures

Dragging a corner fires dozens of updates a second. Recording every one of them would make undo a frame-by-frame rewind of your own mouse movement, which is not what anybody means by undo.

So the box in flight is a draft and is drawn live but never recorded. It becomes a step only when the gesture ends, and a gesture that finishes exactly where it started records nothing. One press of undo therefore takes back one deliberate change.

Accepted formats
JPEG, PNG, GIF and WebP.
Batch size
Up to thirty files, fifty megabytes each and two hundred in total.
Animations
An animated GIF is cropped frame by frame and stays animated.

Frequently asked questions

Is the output quality reduced?
The cut itself removes nothing from what remains — the kept pixels are the original pixels. A JPEG has to be written out again afterwards, which is one encode, and nothing else about the image is touched.
Can I crop to a fixed shape?
Yes. Lock a ratio and the corners drag both sides together, so a square stays square and a 16:9 box stays 16:9 however you resize it. Switch back to a free crop and the lock is dropped without disturbing the box you already have.
Why can I not type a width larger than the image?
Because there would be nothing there. The box is kept inside the picture as you type as well as as you drag, so the values in the fields are always a region that exists.