About this instrument

Image size is usually presented as a form with two boxes in it. That framing works when the answer is already known and fails the moment the question is physical — a print at a stated width, a scan at a stated density, a photograph reduced by half. In those cases the pixel count is not the input; it is the result of an arithmetic the interface has hidden.

This site puts the arithmetic on the surface. Pixels, print size and resolution are shown together, one of them is held while another is edited, and which one is held is a visible choice rather than an assumption. The kernel that computes the new pixels is named, selectable, and explained where the explanation belongs, next to the control.

Typing an exact pixel width and height as the primary action is not something this site will add. It is a good operation, it is served properly elsewhere, and adopting it here would collapse the distinction that makes both worth having. The same applies to reconstructing detail in a small image, to processing a folder against a rule set, to extending a canvas into a new aspect ratio, and to reaching a target file length. Each of those is a separate instrument with its own depth.

Refusing work is how a single-purpose tool stays good at the thing it does. The measure of this one is whether a printer’s preflight accepts what it produces, not how many operations it accumulated.

A static site with no server behind it. The resampler is separable convolution over premultiplied alpha with an area-average prefilter, written in TypeScript and executed in a Web Worker so the panel keeps responding while a large file is filtered. The metadata writer operates on the original container bytes: JFIF and Exif segment editing for JPEG, pHYs insertion for PNG, with the compressed image payload copied through untouched.

Everything runs in the page. There is no upload endpoint, no account, no image storage and no queue, because the arithmetic is small enough to do where the file already is, and a round trip to a server would add latency, a privacy question and an outage mode in exchange for nothing.

Two open questions, recorded here rather than in a changelog nobody reads. The default kernel changes at the 100% line — Lanczos going down, bicubic going up — which is defensible and will read as an inconsistency to anyone comparing against a tool that always uses one. And the panel reports the print size it achieved rather than the one that was requested, so a round number typed in can come back with a decimal on it. Both are deliberate. Neither is obviously right.