Nothing is uploaded
The file is read from disk by the page, decoded by the browser's own image decoder, drawn into a canvas element and re-encoded. All of that happens inside the tab. There is no server involved, no request goes out when you pick a file, and the tool works with the network cable pulled — which is the honest way to check it if you would rather not take the claim on faith. The download link points at a data URL built in memory, not at a remote address.
The practical consequence is that the limit is your device, not a service quota. A 60-megapixel raw export will work on a desktop with memory to spare and may simply fail on a three-year-old phone, because the decoded bitmap alone wants four bytes per pixel before any scaling happens.
How the missing dimension is derived
Enter a width and the height comes from original height times new width divided by original width. Enter both with the proportions checkbox on and the image is fitted inside the box you described, which means whichever constraint binds first decides the scale — ask for 1000 x 1000 and a 3:2 photograph comes back 1000 x 667.
If you genuinely need exactly 1000 x 1000, you have two options and the tool only does one of them. Turning the checkbox off gives you those dimensions with the picture stretched, which is almost never what anyone wants. The other option is cropping to a square first and then resizing, which needs an editor because the tool cannot know which part of the frame matters.
Downscaling in steps
Drawing a 4000-pixel-wide image straight into a 400-pixel canvas makes the browser sample roughly one pixel in ten and throw the rest away. Fine repeating detail — brickwork, mesh, woven fabric, small text — aliases badly and you get moiré patterns and jagged edges.
To avoid that, this halves the image repeatedly until one more halving would overshoot the target, then does the last step directly. Each halving averages four pixels into one, so nothing is discarded unsampled and the result is far cleaner than a single jump. It is not as sharp as a proper Lanczos resample in dedicated software, and it does not apply any output sharpening, but it beats what a naive single draw gives you.
DPI is not a resize
Requests for "the same image at 300 DPI" come up constantly and they are asking for the wrong thing. DPI stored in a file is a note about intended print size; changing it moves no pixels and adds no detail. What determines print quality is the pixel count against the physical size you are printing at. Four inches wide at 300 DPI needs 1200 pixels. Work out the pixels you need, resize to that, and let the print software handle the DPI tag — and if the source does not have enough pixels, no amount of resizing will create them.
The 8192-pixel ceiling on each side here is a canvas limit, not an arbitrary one. Beyond it browsers start refusing to allocate, and mobile Safari gives up considerably earlier. Work of that size belongs in desktop software.
Questions people ask
Where does my image go?
Nowhere. It is read locally, decoded by the browser, drawn to a canvas and re-encoded in the page. No network request is made at any point in that chain, and you can verify it by opening the network tab in your dev tools before picking a file, or by disconnecting from the internet and using the tool anyway. The result is handed back as a data URL held in memory, which is why very large outputs feel sluggish — the whole encoded file is sitting in a string.
My transparent PNG came back with a white background.
The output format was JPEG, which has no alpha channel. Transparent areas have to become something and white is the least surprising choice. Set the output format to PNG or WebP and the transparency survives. If you are matching this to a coloured page background rather than a white one, a JPEG with white fill will show as a visible box, so PNG is the right answer there too.
Is the metadata preserved?
No, and that is worth knowing in both directions. Going through a canvas discards EXIF entirely — capture date, camera model, lens, exposure, and GPS coordinates if location tagging was on. For anything you are publishing that is a privacy improvement. For an archive copy it is data loss, so resize a duplicate and keep the original. Embedded colour profiles usually go the same way, which can shift colours slightly on wide-gamut source material. Current browsers apply EXIF orientation before drawing, so the result is not sideways; older engines did not, and that is the classic cause of rotated output.
Why is the resized file bigger than the original?
Two common causes. Saving a heavily compressed JPEG as PNG will usually multiply the size, because PNG is lossless and photographic noise is expensive to store exactly. Or the quality is set high — 90 and above re-encodes a lot of detail the original had already thrown away, and re-encoding never recovers what a previous compression pass removed, it only spends bits describing the artefacts. Drop the quality to around 80 and stay in JPEG or WebP.