Image Upscaler

No, and it is worth being clear about what that means. This is interpolation: the output has more pixels than the input, and each new pixel is estimated from its neighbours using a resampling kernel. It produces a clean, sharp enlargement — markedly better than what a browser or a basic resizer gives you — but it cannot show you detail that was never captured. An AI upscaler generates plausible detail instead, which looks impressive and is genuinely useful for some jobs, but it is inventing rather than recovering. For a document, a product photo or anything where accuracy matters, invented detail is a liability.

Not literally, but closer than most tools manage. Quality per pixel always falls when you enlarge — you are spreading the same information over a larger area. What a good method does is make that loss as graceful as possible: edges stay defined instead of turning into stair-steps or mush, and gradients stay smooth. At 2× a decent photo holds up very well. At 8× you will see the limits of the original no matter what any tool claims.

It is the resampling kernel image editors reach for. When you enlarge, every output pixel sits between input pixels, and the kernel decides how to weigh the neighbours around it. Bilinear — what a browser does with drawImage — weighs only the nearest few and produces the soft result people associate with enlarging. Lanczos uses a wider window with a windowed sinc function, which preserves edge definition much better. The difference at 4× is not subtle.

Lanczos 3 for photographs; it is the default and the sharpest. Mitchell for anything noisy or heavily compressed, because it is smoother and will not amplify JPEG blocks and grain into something worse. Lanczos 2 for clean illustration and line art, where the wider kernel can ring along hard edges. Nearest neighbour only for pixel art. Bilinear is included so you can see what you would otherwise have got.

Choose the Pixel art preset, which uses nearest neighbour — it does no blending at all, so each original pixel becomes a clean block. Every other method averages neighbouring pixels, which is exactly what you do not want when the hard edges are the artwork. Use a whole-number scale (2×, 4×, 8×) as well: a fractional scale makes some source pixels land on more output pixels than others, so the blocks come out unevenly sized.

Because it is showing you real pixels at 100%. If an enlargement is scaled back down to fit a panel, all the detail the tool just produced is thrown away in the display — which is why every method looks identical in tools that preview that way. The 1:1 view with a draggable split is the only way to actually see what changed. Use the arrows to move around the image.

No. The resampling runs in your browser on your own machine, which is also why the progress bar exists — the work is happening locally rather than on someone else's hardware. Nothing is transmitted, nothing is stored, and once the page has loaded it works with the network off. For anything sensitive — documents, ID photos, private pictures — that is a meaningful difference from a tool that requires an upload.

Memory. Resampling holds an intermediate buffer alongside the input and output, so an 8× enlargement of a large photo can want well over a gigabyte and simply crash the tab. The limit is 40 megapixels of output, and the tool tells you the resulting dimensions before you run anything so you can pick a scale that fits. Browsers also refuse any canvas larger than 16,384 pixels on a side.

Applies an unsharp mask to the enlarged result. Enlarging always costs a little acutance, because the kernel is averaging real pixels to invent positions between them, and a light sharpen puts that apparent crispness back. It is standard practice in any print workflow. Turn it off for noisy images, where it will amplify the noise along with the edges, and keep the amount low unless you want visible halos.

DPI on its own is only a tag in the file — changing it without adding pixels does nothing to the print. What matters is pixel dimensions relative to the physical size. For a 300 DPI print at 8 × 10 inches you need 2400 × 3000 pixels, so enter those in the exact size fields. If your original is 1200 × 1500, that is a 2× enlargement, which will print well. If it is 400 × 500, you are asking for 6× and should expect a visibly soft print.

It should not, and that is deliberate. Resampling here happens in linear light rather than on the gamma-encoded sRGB values directly. Averaging encoded values darkens the result wherever neighbouring pixels differ in brightness — most visibly as a dark fringe along high-contrast edges. Many browser-based resizers skip this step, which is why their output can look subtly muddier than the original.

Yes, correctly. Colours are premultiplied by alpha before filtering and divided back out afterwards. Without that step, resampling colour and transparency independently drags the colour of fully transparent pixels — usually black — into the edges of the visible ones, giving you a dark halo around the subject. Save as PNG or WebP to keep the transparency; JPEG has no alpha channel.

A couple of seconds for a modest enlargement, longer for a large one — it scales with the number of output pixels, and it is running on your machine rather than a server. The progress bar is real. The work is split into passes that yield back to the browser so the page stays responsive instead of freezing.

It reads anything your browser can display: JPG, PNG, WebP, GIF, AVIF and BMP. It writes PNG, JPEG or WebP. PNG is the default because it is lossless — putting an enlargement through JPEG compression can throw away exactly the edge detail the upscale produced.