Image Upscaler: What 2x AI Super-Resolution Does to a Photo

By Andrew Christianson · Los Angeles, CA

Enlarging a photo used to mean one of two things: paying for a large print of a soft file, or paying a retoucher to fake sharpness by hand. An image upscaler changes that equation, but only partly. The tool on this site doubles the width and height of an image with a super-resolution model that runs inside the browser tab, accepts 46 formats, and hands back a lossless PNG. This article explains what happens to the pixels during that pass, what the model can and cannot restore, and how to work out whether the doubled file is actually enough for the print you have in mind.

What 2x Super-Resolution Changes in a Photo

Ordinary resizing does not add information. Bilinear scaling looks at two neighbouring pixels and averages them, bicubic looks at sixteen, and both produce a bigger grid where every new pixel is some blend of the old ones. Edges that were one pixel wide become a two pixel ramp. Text turns grey at the boundaries. A 2000 pixel photo enlarged to 4000 pixels looks exactly like a 2000 pixel photo displayed twice as large, because that is what it is.

A super-resolution network is trained on pairs of images: a sharp original and a deliberately degraded copy of it. During training the network learns which arrangements of light and dark pixels are typical of hair, brick, fabric, foliage and skin at a given scale. When it sees a small image, it does not average the neighbourhood. It predicts what the missing pixels most likely looked like and writes them in. The result is not a blurrier version of the same data with more rows and columns. It is a plausible reconstruction of detail that the camera never recorded.

The practical difference shows up in two places. First, at normal viewing size the doubled image holds contrast at edges: window frames, eyelashes and lettering keep their borders instead of fading into grey. Second, the file survives later processing. If the plan is to crop, sharpen or print, starting from a reconstructed image gives the next step real pixels to work with instead of interpolated ones.

There is a cost, and it is worth stating plainly. The model is guessing. On a photograph of a face, a garden or a plate of food, the guess is usually convincing because the network has seen thousands of similar textures. On anything with exact geometry, the guess can produce soft or invented strokes.

What the Browser Model Can and Cannot Invent

This particular tool runs a Swin2SR model, the classical 2x variant trained on clean downsamples rather than on real camera degradation. That choice matters. Because the network was trained on images that were shrunk with a known filter, it does well on files that were resized down at some point, which covers a lot of web images, thumbnails and exported artwork. It is less specialised for heavily compressed phone photos with visible JPEG blocking, where a real-world degradation model trained on such artefacts would have the edge.

The architecture explains why this can run in a browser at all. A transformer that attended to every pixel at once would need memory that grows with the square of the image size. Swin2SR instead divides the picture into windows and shifts them between layers, so local detail is processed locally and the working set stays small enough for a graphics card that already sits in the machine. On a laptop with WebGPU the pass takes seconds. On a machine without it, the same model runs through WebAssembly on the CPU and takes noticeably longer, which is why the page shows a progress bar.

What the model will not do is just as important. It does not recover a blurred licence plate, because that information was never captured. It does not sharpen an out-of-focus shot into a sharp one, because focus is lost at the optical stage, before any pixels exist. It does not fix motion blur of a moving subject. And it does not understand typography: small text in a screenshot is a poor fit for a network trained on photographs, and the letters can gain soft or invented serifs. If the goal is a legible enlargement of a text screenshot, re-rendering the text at the target size beats any upscaler.

Two more limits follow from the design. The factor is fixed at 2x, since the model was trained for that single scale. And running the same image through it twice does not double quality: the second pass treats invented detail as evidence and compounds the guess, so a stacked result often looks sharper in the thumbnail and waxy at 100%.

Resolution Math: How Much Print a 2x Pass Buys

Printers think in pixels per inch, not in megapixels. A file is print-ready at a given size when its pixel dimensions divided by that size land near the density the job needs: 300 PPI for anything held in the hand, 200 PPI for a poster read from a step away, 100 to 150 PPI for a banner on a wall. The formula is short:

$$ \text{PPI} = \frac{\text{pixel width}}{\text{width in inches}} $$

A 1200 by 900 photo doubled becomes 2400 by 1800. At 300 PPI that covers 8 by 6 inches, which is a standard photo print. At 200 PPI it covers 12 by 9 inches. At 150 PPI it covers 16 by 12 inches. The same arithmetic runs in reverse when the target size is known: an A4 page at 300 PPI needs about 2480 by 3508 pixels, so a source photo of 1240 by 1754 arrives there after one 2x pass.

The table is the whole argument for upscaling before printing. The 2000 pixel source is the largest this tool accepts, and after the pass it covers an A4 page at roughly 360 PPI, which is more than enough. A 640 pixel photo reaches a 4 by 3 inch print at full density, which is useful for a passport style photo but not for a poster.

Reading the Density Numbers Honestly

Two caveats keep the numbers honest. First, density is not the same as detail: a 300 PPI file that came from a soft source still looks soft, because the ink follows the reconstructed pixels. Second, glossy paper shows artefacts that matte paper hides, so the same file can pass on one stock and fail on another. Inspect at 100% on screen before sending anything to a lab.

Input Formats: Why a Local Decoder Matters

Most upscalers accept JPG, PNG and WebP and stop there. That leaves out the files that actually need enlarging: a museum scan delivered as TIFF, a print layout saved as PSD, a phone photo in HEIC, a JPEG 2000 archive from a camera, a page from a PDF, a Gerber layer from a circuit board plot.

This tool accepts 46 formats across 53 extensions and splits the work in two. Formats the browser already understands, among them PNG, APNG, JPG, WebP, GIF, BMP, ICO, CUR, AVIF and SVG, are decoded natively, with no extra download. Everything else goes through an ImageMagick build compiled to WebAssembly, about 14.7 MB, fetched only when a file of that kind is dropped. The decoder converts the foreign file to a PNG in memory, then the model takes over. That lazy loading matters on a metered connection: someone upscaling a JPG never pays for the decoder at all.

Because the conversion happens on the device, a scanned TIFF or a layered PSD is never uploaded to a remote converter first. The privacy claim is structural rather than a promise: the image is read by the browser, decoded in the same tab, processed by a model running in the same tab, and written to a PNG blob. The only network traffic is the model weights and, for foreign formats, the decoder binary, both fetched from a public hub and cached afterwards.

One limit is deliberate. If a file has a format the browser decodes but the file itself is corrupt, the tool reports an error instead of pulling down the decoder: spending 14.7 MB to confirm that a broken JPG is broken would be a poor trade. Support for exotic formats therefore applies to valid files, not to damaged ones.

Where the Tool Stops: File Size, Pixel Ceiling, PNG Output

A 2x pass quadruples the pixel count, and that has consequences the interface states instead of hiding. The source file may be up to 8 MB. The source image may hold up to 4 million pixels, which is roughly 2000 by 2000. Above either number the tool refuses the file with a message, rather than quietly shrinking it and returning something that looks processed but is not the image you chose.

The pixel ceiling is the real constraint. It caps the output near 16 megapixels, which is plenty for a 13 by 10 inch print at 300 PPI and short of what a double page magazine spread wants. Work within it by cropping first: if only part of the photo is being printed, cut that part out, then upscale the crop. Four million source pixels concentrated on a face is a far better input than the same count spread across a whole street scene.

Output is PNG, always. The model produces raw pixels, and PNG stores them without a second lossy round trip, so the reconstruction arrives intact and transparency survives if the source had any. The trade is size: a doubled photo can easily reach 40 to 80 MB. Convert to JPEG or WebP afterwards if the file is going to the web, and keep the PNG as the archive copy.

There is no batch mode and no URL input. One image in, one image out, which is a deliberate limit of a tool that runs the model in the tab rather than on a queue of servers.

A Practical Workflow from Original to Print

Start from the largest original you have, not from a thumbnail. Every later step inherits the earlier decisions, and a 500 pixel source will not become a detailed 2000 pixel file no matter which model processes it. If the original exists in several formats, take the one with the least compression: a TIFF scan beats a JPEG of the same scan.

Crop before you upscale. Cropping a doubled image throws away half the reconstructed pixels you just paid CPU time for, and the model gets a better look at the subject when the frame is tight. Straighten the horizon and fix exposure at this stage too, because editing afterwards means editing the invented detail.

Run the 2x pass once. Then compare it against the original at 100% zoom on a few areas: hair, fine text, fabric, foliage. If the reconstruction looks waxy or the edges gain halos, the source was probably too degraded for this model, and the honest answer is a different source rather than another pass.

Finish in the format the destination needs. Keep the PNG as the master, resize down for the web with a good resampler, and let the printer handle the rest. When the file goes to a lab, ask what density they want at the final size and check the arithmetic from the table above before paying for a print that will come back soft.

Andrew Christianson

Los Angeles, CA · SO reputation 2000 · Badges: 2🥇11🥈8🥉 · SO member since 2011