ID photos, contract screenshots, unreleased product designs, pictures of your children: you may not want any of these passing through someone else's server. The real worry about online tools has never been whether they work, but where your file goes. The good news is that modern browsers are powerful enough to compress, resize, convert and even run AI background removal on your own device, so the image never has to leave it. This article explains how that works, how to verify it yourself, and where it genuinely stops working.
How "no upload" is actually achieved
When you choose a file on a web page, the browser reads it through the File API into an in-memory Blob that page scripts can access directly, with no network request involved. After that, all processing is local computation built on three capabilities.
- Canvas 2D: the image is decoded and drawn onto a canvas, then redrawn at the target size, which covers scaling, cropping and rotation. Calling toBlob with a MIME type and a quality value re-encodes it as JPG, PNG or WebP.
- WebAssembly and Web Workers: algorithms that used to need native programs (compression, colour quantisation, decoding) are compiled to run in the browser, on background threads so the page stays responsive.
- On-device models: for background removal, enhancement and object erasing, the model file is downloaded to the browser and run with an ONNX runtime on your CPU or GPU (WebGPU). The model must be fetched first, but your image is not sent anywhere.
One distinction is often blurred: "the page downloads a program and a model from the server" is a different thing from "your image is uploaded to the server". The first is one-way: the server only receives a request for a script. The second is the actual privacy risk.
Do not trust the marketing: verify in three steps
- Open your browser developer tools (F12 on Windows and Linux, Cmd+Option+I on Mac), switch to the Network panel and clear the log.
- Choose an image on the page and run the operation, then watch the new requests.
- Look at method and size. A request that sends your image is normally a POST or PUT whose body is about the size of the original, with multipart/form-data or binary content. If you only see GET requests for scripts, fonts and model files, and their size does not change with your image, the image is not being sent.
A stricter test: let the page finish loading, models included, then go offline and process. If compression, resizing and conversion still work, the processing is clearly local. Note that AI tools need a connection the first time to download their model, which the browser usually caches afterwards.
Which tool for which job
| What you want | Tool | Notes |
|---|---|---|
| Image too heavy for a page or email | Image Compressor | Keeps the original format by default; optionally output everything as WebP; keeps the original file when no safe compression exists |
| Too many pixels | Image Resize | Enter a width or height and keep the ratio; output as JPG, PNG or WebP |
| Only part of the image | Image Crop | Drag the crop frame; you can set an output size too |
| JPG, PNG or WebP conversion | Image to WebP / JPG / PNG | Batch supported; transparent areas are filled white when converting to JPG |
| Remove location and device info before sharing | EXIF Viewer & Cleaner | Inspect what is there, then strip it in one click |
| Transparent PNG from a photo | Remove image background | Open-source segmentation model; balanced mode by default, plus faster and more detailed modes |
| Enlarge a small image with less blur | Image Enhance / Upscale | AI-generated detail is an estimate, not fact or evidence |
| Wipe an object out of a photo | Image object eraser | Paint over the area and a local model fills it in |
A worked example: preparing a phone photo for publishing
Say you have a 4000x3000 phone photo for a blog post and you do not want to reveal where it was taken. A sensible order is:
- Open EXIF Viewer & Cleaner first. You will typically see capture time and device model, and GPS coordinates if location was on. Confirm, then strip.
- If the blog column is 800 pixels wide, you do not need 4000. Use Image Resize to set the width to 1600 (headroom for high-density screens) with the ratio kept; the height becomes 1200.
- Use Image to WebP or Image Compressor to tune quality, starting high and lowering gradually, inspecting gradients and text edges at real display size.
- Open the final file in the real page to confirm it looks right, and keep a JPG copy if some readers will download it into older software.
Why resize before compressing? Pixel count is a main driver of file size. 4000x3000 is 12 million pixels; at 1600x1200 it is 1.92 million, 84 percent fewer, and downscaling barely hurts how it looks. Lowering only the quality value instead keeps every pixel and degrades each one, which normally looks worse at the same file size.
The real limits of local processing
Local processing is not magic. Knowing its edges saves time.
| Limit | Why | What to do |
|---|---|---|
| Very large image fails | A decoded pixel takes about 4 bytes: 40 million pixels is roughly 160 MB, plus intermediate canvases | Reduce the size first; the current tools cap a file at 50 MB and about 40 million pixels |
| Canvas limits differ by browser | Browsers cap the size of a single canvas, notably on mobile | Use a desktop browser, or shrink the image first |
| First use of AI tools is slow | A model must download first (for example about 32 MiB for Image Enhance and about 94 MB for the HD background model), and speed depends on your device | Use a stable connection and let caching finish; later runs rarely need to download again |
| Speed depends on your hardware | The work runs on your CPU or GPU | Large images and AI features can be slow on an older phone; try a computer |
| Some formats cannot be exported | Depends on whether the browser can encode that format | The page reports an unsupported output; try another browser or format |
| Results vanish when the tab closes | Data lives only in page memory | Download results as soon as they are ready |
Quality and metadata: what re-encoding means
Re-encoding through a canvas is decode, redraw, encode. JPG and lossy WebP lose a little each time, so avoid saving the same image repeatedly; for several edits, always start from the original and export once to the final size. After re-encoding, the original EXIF metadata is normally not written to the new file. That is good for privacy but a problem if you need to keep capture time or copyright data. Transparency needs care too: PNG and WebP keep it, JPG cannot, and converting to JPG fills transparent areas (white in this tool).
Browser-local, desktop software and cloud APIs compared
| Approach | Privacy | Setup cost | Best for |
|---|---|---|---|
| Browser-local processing | Image stays on the device, verifiable | Open a page, nothing to install | Everyday compression, resizing, conversion, quick background removal |
| Desktop software (Photoshop, GIMP) | Image stays on the device | Install and learn | Detailed retouching, colour management, professional print |
| Cloud processing service | Image is sent to a server; depends on provider policy | Usually the easiest | You trust the provider, the image is not sensitive, and you need heavy compute |
| Command-line tools (ImageMagick) | Image stays on the device | Requires command-line skill | Scripted batches of hundreds or thousands of images |
Common pitfalls and how to diagnose them
| Symptom | Likely cause | Fix |
|---|---|---|
| Output is larger than the original | A PNG photo set to lossless or high quality; re-encoding an already heavily compressed JPG | Lower the quality, or keep the original (the compressor keeps the original when it cannot safely shrink it) |
| Wrong orientation | Phones record rotation in metadata and some software ignores it | Fix with Image Rotate, then export |
| Colours look different | Colour profile dropped or converted during re-encoding | Use professional software for colour-critical print or photography |
| Format not supported message | The browser cannot decode or encode it | Switch browser or target format |
| AI tool spins forever | Model still downloading or the device is underpowered | Check the connection, shrink the image, or choose a faster mode |
When not to use browser-local processing
- Extremely high-resolution or huge files such as panoramas or scans of hundreds of megapixels. Browser memory and canvas limits become the bottleneck; use desktop software.
- Colour-critical print work. Canvas processing does not promise to preserve ICC profiles; use a professional workflow.
- Images that must be legally or forensically unmodified. Any re-encode changes pixels, and AI enhancement generates estimated content that must not serve as evidence.
- Thousands of images. Browsers are a poor fit for long, large batches; a command-line tool is better.
- Archival work that needs EXIF and GPS intact. Re-encoding normally drops them; copy the original file instead.
In short, for most everyday tasks local processing strikes the best balance between privacy and convenience, while extreme sizes, exact colour and evidence-grade needs call for more specialised tools. Whichever tool you use, the habit of opening the Network panel before deciding to trust it is more reliable than any promise on a landing page.