Privacy
No sign-up image compressors — and which of them still upload your files
7 min readUpdated 29 September 2026By QANEN
Short answer: “no sign-up” and “no upload” are two different promises, and almost every free compressor that ranks for the first one breaks the second. A tool can let you work without an account and still transmit your photo to its server on every compression. If the account is your problem, any of them will do. If the upload is your problem, you need a tool that decodes and encodes in your browser — and that is a much shorter list.
The two questions people merge into one
- Does it need an account? Determines whether you hand over an email address, get marketing afterwards, and whether your compression history is stored against your name.
- Does it need your file? Determines whether the image itself travels to a server, gets processed there, and sits there for some period of time.
The second one matters considerably more. An email address is a nuisance; a photo of an ID, a signed contract, a medical scan, a client’s unreleased artwork, or your family’s holiday pictures is content you may never want on somebody else’s machine. Yet the two get sold as though they are the same feature, which is why searching for an image compressor free with no sign-up mostly returns tools that upload.
What the popular free compressors actually allow
These are the limits each vendor publishes about its own free tier, read from their pricing pages, FAQ text or page source in late September 2026. They are worth knowing because the ceiling — not the privacy policy — is what usually decides whether a tool is usable for you.
| Tool | Sign-up | File leaves device? | Published free limits |
|---|---|---|---|
| TinyPNG / TinyJPG | No | Yes — states files are retained up to 48 hours | 5 MB per image, 20 images per session, 3 free conversions |
| iLoveIMG | No | Yes | 200 MB and 30 files configured; ads on the free tool page; paid tier “removes ads” |
| Adobe Express | Required to download some outputs | Yes — its own terms notice covers the upload | 40 MB, JPEG/PNG input only |
| Compressor.io | No | Yes | 10–20 MB depending on mode |
| ezgif | No | Yes — says uploads are auto-deleted after one hour | 200 MB |
| compressjpeg / compresspng / imagecompressor.com | No | Claims browser-side processing; 50 MB per file, 20 files | 50 MB, 20 files |
| Squoosh (GoogleChromeLabs) | No | No — runs locally | Single file at a time; batch processing is an open request, not a feature |
| OptiSqueeze | No | No — decodes and encodes in your browser | 50 MB per file, batch queue, no session cap |
Two things fall out of this. First, the biggest names are not account-gated — you can compress on TinyPNG today without registering anything, so “no sign-up” on its own is not a competitive claim. Second, the free ceilings are genuinely low: a 6 MB camera JPEG is already over TinyPNG’s published 5 MB limit, and the moment you exceed one you are being steered towards a paid tier.
Why a free tool needs something from you
Server-side compression costs money per byte. Somebody has to pay for the bandwidth, the decode cluster and the storage, which is why the free tiers above are capped so tightly and why the pages carrying them often run advertising. It is an honest trade — you get an engine far more powerful than your laptop — but it means the business model depends on your files and your attention, and that shapes what the product does: upload queues, session limits, an “upgrade to remove ads” prompt appearing exactly when you are in a hurry.
A local compressor has no such cost structure. The work happens on hardware you already own, so there is no per-file bill to recover, no queue to monetise, and nothing about your images to store even accidentally. That is the actual reason a browser-based tool can credibly promise no account and no limits — not a marketing choice, a consequence of where the computation runs.
How to check what a tool really does, in about a minute
This is the part worth learning, because it works on every tool including this one, and it turns a claim into something you observed yourself.
- Open the compressor in a desktop browser and press
F12(or right-click → Inspect). - Go to the Network tab, then type
imgor pick Fetch/XHR to filter. - Choose a photo that is unmistakably yours and unmistakably sensitive — not one you would mind leaking.
- Run the compression and watch the entries appear.
- Look for any POST request whose payload size resembles your file. A 4 MB photo producing a 4 MB upload is the answer, regardless of what the page says about privacy.
On a genuinely client-side tool, you will see requests for scripts, fonts and images already on the page — and nothing carrying your file. If you want the longer version of this procedure, including what to make of the requests you do see, the guide on compressing without uploading walks through it.
Be suspicious of a claim you cannot test. A privacy policy that says “we delete your files after an hour” is an assertion about a server you cannot inspect. “No request leaves your device carrying your image” is a claim you can verify yourself in the DevTools panel — which is the only kind of privacy promise worth much.
What no-upload compression costs you
It is not strictly better. Being straight about the trade-offs matters more than winning the argument:
- Your hardware does the work. Encoding is slower than a datacentre, and it is the same tab drawing your email and your music. Large images on a low-RAM laptop can fail where a server would shrug.
- There is a real size ceiling. This tool caps input at 50 MB because the browser has to hold the decoded bitmap in memory — a 200 MB file that a server-side tool streams would simply exhaust it.
- AVIF is the slow option. It is encoded by a WebAssembly build of libavif, which is markedly heavier than the JPEG and WebP paths.
- No cross-device continuity. Nothing is stored anywhere, so a queue started on your laptop is not waiting on your phone. That is the feature and the limitation at once.
- You need a modern browser. Reading AVIF depends on your browser being able to decode it; older Safari and Firefox builds cannot.
When an upload-based tool is the right answer
If the images are not sensitive — stock photography, product shots for your own store, screenshots of public pages — a server tool is often the better experience. It will be faster on very large batches, it can offer features local code cannot practically match, and its limits are somebody else’s problem. Optimising a hundred gigabytes of a CDN’s catalogue on a scheduled job is not a browser’s job. “No upload” is the right default for files you would not email to a stranger, not a rule for everything.
Which one to use
- Documents you should not be distributing — IDs, contracts, medical images, tax paperwork, client work under NDA: use something that runs locally, and verify it the way above. Also strip the metadata first; see removing EXIF from photos.
- A hard byte limit from a form — a portal that says “maximum 200 KB”. That is a search problem, not a slider problem: set the target size and let it find the best quality that fits.
- Many images at once — batch is where local tools are strongest, because a queue of two hundred files never touches a network. Load them all and process with one set of settings.
- Smallest files for a website — modern formats beat any clever quality tweak. AVIF where you can rely on current browsers, WebP as the safe default. The format comparison covers when each pays off.
- Huge or unusual files, or heavy repeat volume — a paid server-side service is honestly the right tool. You are buying someone else’s hardware; just know what you are selling for it.
Does avoiding sign-up actually protect you?
Partly, and it is worth being precise rather than absolutist. Skipping registration means no email address, no marketing list, and no profile your compressions hang off — all real benefits. It does nothing about the file itself, and it does not make you anonymous: your browser still sends an IP address and a user-agent string to whichever server is handling the image, which is enough to associate the request with you even with no account in the picture.
The most useful protection is the boring one: pick a tool where the sensitive thing never arrives anywhere. Then the retention policy, the staff with database access, and the breach that has not happened yet all stop being your problem — because there is nothing there to leak.
