AI Image Upscaler & Enhancer — Auto-Enhance Photos Online

Why AI upscaling beats a plain resize

Enlarging a photo the ordinary way — bilinear or bicubic interpolation — just averages neighbouring pixels. Doubling a 400 × 300 image to 800 × 600 that way creates 480,000 pixels out of the original 120,000, and every one of the 360,000 new pixels is a blur of its neighbours, so the picture gets bigger and softer at once. AI super-resolution takes a different route: a neural network trained on millions of low- and high-resolution pairs predicts the high-frequency detail a plain stretch throws away, reconstructing edges, textures, and fine structure instead of smearing them.

This tool runs Swin2SR — a super-resolution network built on the Swin Transformer architecture from Microsoft Research — at a ×2 scale factor, so a 500 × 500 crop becomes a reconstructed 1000 × 1000. Version 4.2.0 of the Hugging Face Transformers.js library loads the ONNX-exported model Xenova/swin2SR-lightweight-x2-64 and executes it through ONNX Runtime, entirely on your device. The lightweight variant is deliberate: its embedding dimension is 60 and it uses 4 transformer stages, against 180 and 6 in the classical model, so the ONNX weights are about 8MB instead of 54MB and each inference uses roughly a third of the memory — a far quicker first load and no tab crash on large photos.

The automatic enhancement pass, step by step

Super-resolution alone gives you a sharper big image, but not necessarily a punchy one, so a second stage runs on every result. First, per-channel auto-levels: the tool builds a 256-bin histogram for each of the Red, Green, and Blue channels, ignores the extreme 0.5% tails at each end, and stretches the remaining range to the full 0–255 scale. That single step fixes the flat, hazy, grey look of an under-exposed photo by restoring true blacks and whites.

Then colour and crispness: saturation is lifted by a factor of 1.18 (about 18%) around each pixel's luminance, computed with the standard Rec. 601 weights of 0.299 Red, 0.587 Green, and 0.114 Blue, followed by a 3 × 3 sharpen convolution at strength 0.35. The result is the "pop" you expect from a phone enhancer like Remini or Google Photos — but every one of these operations runs locally on your pixels, and you can still layer manual brightness, contrast, saturation, and sharpen offsets on top.

WebGPU, WebAssembly, and why this page has special headers

A transformer doing super-resolution is heavy arithmetic, so the runtime matters. When your browser exposes a usable WebGPU adapter, the model runs on your graphics card and finishes in a few seconds. When it does not, the tool falls back to WebAssembly on the CPU — identical model, identical output, just slower at roughly 10–60 seconds, and occasionally 1–2 minutes for a large image on a single core.

To make the fast path possible, this one route sends two HTTP headers — Cross-Origin-Opener-Policy set to same-origin and Cross-Origin-Embedder-Policy set to credentialless — which put the page in a cross-origin isolated state. That unlocks SharedArrayBuffer, and with it multi-threaded WebAssembly across up to 8 worker threads, so even the CPU fallback uses every core. The credentialless value is deliberate: the stricter require-corp blocked the same-origin ONNX Runtime worker, so it was rejected.

Memory limits and the size ladder

The one hard constraint is memory. Self-attention cost in a transformer grows with the number of pixels, so a 12-megapixel photo fed in whole would blow the WebAssembly heap with a std::bad_alloc. To stay safe, the model input is capped at 640 pixels on the long edge, and if an allocation still fails the tool rebuilds a clean session and steps down a ladder — 640, 512, 384, 256, then 192 — until the image succeeds. On the CPU path it starts at 384 to avoid the slowest, most fragile sizes.

Because the internal base can be smaller than your original, the ×2 result is then resampled up with high-quality smoothing so the final image is never smaller than what you uploaded and always at least twice the model output, capped at 2560 pixels on the long edge (1600 on low-memory devices) so the browser never builds an oversized canvas that would exhaust memory and crash the tab. The practical upshot: a small 500-pixel image is genuinely reconstructed at 1000 pixels, while a giant 5000-pixel photo is enhanced from a 640-pixel base and scaled to fit — still sharper and cleaner, just not a full 2× of an already-large file.

What it does well, and where it will not save you

Super-resolution is strongest when the detail it needs to rebuild is plausibly implied by what is already there. A 480 × 640 phone snapshot, a compressed 720p thumbnail, an old 1-megapixel profile picture, a screenshot scaled down to 400 pixels — these have real structure the model can sharpen and extend, and the ×2 pass genuinely recovers crispness on faces, text edges, and product outlines. Restoring a batch of 30 low-resolution catalogue shots to roughly 2× is exactly the job it is built for.

It cannot invent information that was never captured. A photo blurred by camera shake stays blurry, because motion blur destroys the high-frequency detail rather than merely shrinking it; a face at 20 × 20 pixels has too few of the original 400 samples for the model to reconstruct a real likeness rather than a plausible guess; and heavy JPEG compression at quality 30 bakes in 8 × 8 block artefacts that upscaling will faithfully enlarge. For those, no browser model — and no cloud one either — will fully rescue the shot. Treat this as a fast, private 2× enhancer for recoverable images, not a forensic reconstructor.

A practical workflow: for a product catalogue, upload 20 or 30 shots at once, let the batch run, and download the single ZIP; for one hero image, upscale, then nudge the manual sliders — brightness 50–150%, contrast 50–150%, saturation 0–200%, and an extra sharpen from 0 to 100 — on top of the automatic pass. Every output is a lossless 24-bit PNG, so re-editing it later loses nothing, unlike a re-saved JPEG that sheds quality on each save.

Quick reference

• Model: Swin2SR lightweight (Swin Transformer super-resolution), Xenova/swin2SR-lightweight-x2-64, ×2 scale, ~8MB weights.
• Engine: Hugging Face Transformers.js 4.2.0 on ONNX Runtime — WebGPU, or multi-threaded WebAssembly (up to 8 threads).
• Model source: Hugging Face CDN, fetched once, then cached for offline reuse.
• Input formats: JPG, JPEG, PNG, WebP; single or batch.
• Output: lossless PNG, up to 2560 pixels on the long edge (1600 on low-memory devices).
• Input ladder: 640 → 512 → 384 → 256 → 192 pixels, stepping down only on out-of-memory.
• Auto pass: 0.5% auto-levels, 1.18× saturation, 3 × 3 sharpen at 0.35.
• Typical time: a few seconds on WebGPU; 10–60 seconds on WebAssembly.
• Privacy: your image is processed on-device and never uploaded; only the model crosses the network.
• Cost: $0, unlimited, no watermark, no sign-up.