Circle Crop

Or drop one here, or paste from the clipboard. Nothing is uploaded — the crop happens in your browser.

A circle keeps 78.5% of the square, exactly

A circle inscribed in a square covers π ÷ 4 of it, so a circular crop discards 21.46% of the pixels. That figure is fixed — it does not depend on the image, the resolution, or anything you can adjust.

It is worth knowing when you are composing rather than after. The part that disappears is the four corners, and corners hold more of a photograph than they feel like they should: over a fifth of it. Anything you want kept — the top of someone's head, a hand, the edge of a logo — needs to be inside the inscribed circle before you crop, not merely inside the frame.

And the edge matters far more at avatar sizes

Classifying every pixel of an n × n crop as fully inside the circle, fully outside, or straddling the boundary:

The count of boundary pixels grows with the circumference while the image grows with the area, so the share falls as roughly 4 ÷ n. At 512 pixels the boundary is 0.78% of the image and you could round every pixel to in or out and nobody would see it. At 32 pixels — an ordinary avatar — 12.1% of the image sits on that boundary.

That is why antialiasing is not a refinement at small sizes. It is most of what the viewer actually sees of the shape, and it is the whole difference between a clean avatar and a stair-stepped one. If you are producing a 32-pixel circular icon, render it larger and scale down rather than cropping at the target size — the downscale does the averaging for you.

Which is what the output-size control above now does, rather than leaving it as advice. Pick a size and the crop is rendered at 4× that and scaled down, so every output pixel averages 16 rendered ones — capped when the source is too small to supersample honestly, because enlarging past the detail an image holds invents nothing. At 32 pixels that averaging is doing most of the visible work.

There is a neat check hiding in that table. Counting only the fully-inside pixels underestimates the area badly at small sizes — 64.1% at 16 × 16 against the true 78.54%. Counting the inside pixels plus half the boundary converges quickly and correctly, reaching 78.529% by 512 × 512. That half-weighting is, in effect, exactly what antialiasing computes — which is a pleasant way of seeing that the technique is not a visual trick but the arithmetically right answer.