How to Upscale Images Without Uploading Them: AI Super-Resolution in Your Browser

You have a small image. It might be a downloaded stock photo that needs to fill a hero banner, a screenshot you want to print, an old camera phone shot from 2010, or a game asset destined for a high-DPI screen. The classic options are all bad: nearest-neighbour makes it blocky, bilinear makes it blurry, and every cloud upscaler wants you to upload the file first and then pay per image.

AI super-resolution is the alternative that actually reconstructs detail — not perfectly, but visibly better than resampling. And it now runs in a browser tab. This guide covers what the model is doing, why 2× and 4× behave differently than you might expect, and where the technology honestly fails.

What “super-resolution” actually means

Traditional upscaling — the kind your image editor or browser does automatically — interpolates. It looks at neighbouring pixels and blends between them, producing a smooth gradient where there should be an edge. The result is larger but softer; no information has been added.

AI super-resolution is different. A neural network trained on millions of image pairs (low-resolution and high-resolution versions of the same photo) has learned what sharp edges, skin texture, brickwork, foliage, and fabric typically look like. Given a low-resolution input, it does not interpolate — it hallucinates plausible high-frequency detail that fits the patterns it sees. The output is sharper, and in a specific sense more detailed, because the model is inventing texture that was never captured by the original sensor.

This is the central trade-off to understand: the model is not recovering lost information. It is generating a plausible guess at what the missing detail could have been. On natural photographs that guess is usually convincing. On text, line art, or anything with precise geometry, the guess can produce artifacts — the model does not know what a letter should look like, only what texture patterns are common at that scale.

The model: Swin2SR

The tool runs Swin2SR — specifically the swin2SR-realworld-sr-x4-64-bsrgan-psnr variant — through Transformers.js. Swin2SR is a transformer-based super-resolution network built on the Swin Transformer architecture, which processes images in shifted window patches rather than globally. That makes it tractable for larger inputs without the memory explosion of a pure global-attention model.

The model name tells you three things about how it was trained:

• realworld-sr — trained on real-world degradations (blur, noise, compression artifacts), not clean downsampled pairs. This is why it works on JPEG-compressed phone shots and screenshot artifacts, not just on pristine source material.
• x4 — the network is a 4× super-resolution model. It always upscales by four, regardless of which mode you select. More on that below.
• bsrgan-psnr — trained with BSRGAN degradation simulation and optimized for PSNR (peak signal-to-noise ratio), meaning it favours faithful reconstruction over stylistic flair. The alternative, GAN-optimized variants, produce sharper but sometimes less faithful results.

The model is roughly 200 MB and downloads once on first use, then is cached by the browser like any static asset. On WebGPU-enabled Chrome or Edge it runs as fp32 on the GPU; everywhere else it falls back to q8 quantization on WebAssembly, which is slower but produces equivalent output.

Why the model is always 4×, even when you ask for 2×

Here is an engineering detail that confuses everyone at first: the network graph is hardwired for 4× upscaling. There is no “2× mode” inside the model itself. The three options in the tool — 2×, 4×, and Denoise — are all the same 4× inference pass, with different post-processing:

• 4× keeps the model’s native output. A 500×500 input becomes 2000×2000.
• 2× runs the full 4× pass, then rescales the result back down to 2× using a high-quality canvas draw. The reason is quality: downscaling a 4× output to 2× produces a crisper 2× image than a native 2× model would, because the 4× model had to commit to more detail and the downsample preserves the useful part of that commitment.
• Denoise runs the same 4× pass, then rescales back to the original resolution. Super-resolution models trained on real-world degradations are excellent denoisers — the network has learned to distinguish noise from signal as a side effect of learning to upscale. This mode cleans up JPEG artifacts and sensor noise without changing the image size.

The input cap, and why it exists

There is a hard limit on the input image’s longest edge. It is not arbitrary: it is the difference between the tool working and crashing the tab.

Swin2SR’s internal attention mechanism produces intermediate tensors that scale roughly as height × width × 180. ONNX Runtime, which executes the model in the browser, uses 32-bit integers for tensor element counts. A 12-megapixel photo (roughly 4000×3000) would generate intermediates that overflow that counter — not because the math is wrong, but because the bookkeeping breaks. The error is an unhelpful Integer overflow crash with no recovery.

The fix is to pre-shrink oversized inputs before feeding them to the model. The tool draws the image onto a canvas capped at the maximum edge, then passes that canvas to the network. A 4× pass on a capped 1024-pixel input still produces a 4096-pixel output — which for most real-world use cases meets or exceeds the original resolution. The cap is a ceiling on the model’s input, not on the result you get.

The practical implication: very large originals do not get “more detail” from the model. A 6000-pixel photo and a 1024-pixel photo feed the network the same amount of information after the cap. The 4× output is then rescaled to your target dimensions, so a 2× pass on a 6000-pixel image still produces a 12000-pixel result — the model just had to work with a downsampled view of it.

WebGPU vs WebAssembly: the speed gap is real

Super-resolution is compute-heavy. The Swin Transformer’s attention layers are dominated by matrix multiplication, which GPUs excel at. WebGPU gives the browser direct access to that hardware. On a machine with a discrete GPU, a 4× pass on a moderate image completes in a few seconds.

The WebAssembly fallback runs the same model on the CPU with 8-bit quantization. The output quality is equivalent — the quantization is light enough that super-resolution, which produces perceptual sharpness rather than pixel-exact values, is barely affected. But the runtime is materially longer. If you find yourself waiting thirty seconds for a single image, you are almost certainly on the WASM path. Chrome or Edge on a machine with a modern GPU is the difference between a coffee break and a few seconds.

The tool tells you which backend is running. If it says WASM and you have a GPU, the usual cause is an older browser version or a WebGPU flag that has not been enabled. Updating the browser is the fix.

Where it honestly fails

• Text and line art. Super-resolution models are trained on natural photographs. They hallucinate texture, and texture is the wrong prior for a letterform. Small text in a screenshot may become slightly distorted — readable but with soft or invented serifs. For upscaling text screenshots, OCR plus re-rendering at the target size is more reliable.
• Faces at extreme zoom. The model can invent skin texture and hair that was not in the source. At normal viewing distances this looks like a genuine improvement. At 400% zoom on a face, the invented detail can look waxy or uncanny. This is the nature of hallucinated detail, not a bug.
• Already-upscaled images. If the source has already been through a super-resolution pass (by a phone camera’s built-in upscaler, for instance), running it again compounds the hallucination. The result may look sharper but further from the original scene.
• Information that was never captured. A blurred licence plate does not become readable. A dark shadow does not reveal hidden detail. The model fills in plausible texture, not ground truth. If you need to recover actual lost information, super-resolution is the wrong tool.

Recipes

Web assets and UI design

A 400×300 stock photo for a card background, upscaled 2×, is the sweet spot. The model reconstructs foliage, fabric, and skin texture convincingly, and the 2× downscale-from-4× pass produces crisp edges. Always compare the result against a bilinear upscale of the same image — the difference is usually obvious.

Old phone photos

A 640×480 photo from a 2010-era phone camera, upscaled 4×, is where the realworld degradation training pays off. The model has seen JPEG artifacts and sensor noise during training and handles them as part of the reconstruction, not as signal to preserve. Use Denoise mode if you want to clean up the artifacts without changing the size.

Screenshots for print

A screenshot upscaled for a printed document is a mixed case. UI elements with hard edges (buttons, icons) may get slightly soft, while photographic content within the screenshot upscales well. If the screenshot is mostly text, consider OCR and re-layout instead.

Privacy, and the thing to check

Upscaling a photo you took is not sensitive. Upscaling a client’s unreleased product photo, a confidential design mock-up, or medical imagery is. Cloud upscalers receive the original image — the low-resolution file is uploaded, processed on a server, and returned. The original and the upscaled version both exist on someone else’s infrastructure.

Running locally, the image is decoded in the browser’s memory, the model runs on your hardware, and the result is composited to a canvas and saved. The only network request is the one-time model download. You can verify this in DevTools: open the Network tab, upscale an image, and confirm that no request containing your file appears after the initial model fetch.

Try it with the AI upscaler — start with a small, noisy photo and run it at 4×. The comparison slider makes the difference between resampling and super-resolution immediately visible, which is the fastest way to calibrate what the model can and cannot do for your specific images.