Browser-local image compression
Most free compressors need your file on their server. This one decodes and re-encodes inside your tab. Here is what that changes — and when uploading is still the right call.
The one difference that matters
Almost every free image compressor on the web is a thin page in front of a server. You drop a photo, the browser uploads it, a server somewhere runs the encoder, and the result comes back as a download. That is a perfectly reasonable way to build the tool — it is just not the only one.
This site does the encoding the other way round. There is no upload endpoint in the page at all. Your browser decodes the file into a canvas, re-encodes it at lower quality until it fits the byte target, and hands the result straight back to you. The file is not transmitted, because there is nowhere for it to be transmitted to.
That single architectural difference is the whole product. Everything else — the target-size input, the binary search, the resolution fallback — is an implementation detail on top of it.
How the mainstream compressors compare
It is worth being concrete rather than vague, so here is where the file is actually processed:
| Tool | Where your file is processed | What that implies |
|---|---|---|
| TinyPNG / iLoveIMG | Their servers | The file is uploaded before compression starts, so free use needs caps |
| compressjpeg / iresizer | Their servers | Upload first; free tiers limit how many files you can do |
| Adobe / Canva free tools | Their servers | An account is required before you can compress anything |
| ImgPress | Your own browser tab | No upload step exists, so there is nothing to cap, watermark or retain |
Specific free-tier limits change over time and are worth checking at the source. The structural point — whether your file has to leave your device at all — does not change.
Why the difference shows up in practice
Documents you would rather not hand over. A passport scan, an ID card, a signed contract, a medical letter. These are the files people compress most often, because government and visa portals cap them hardest at 20KB and 50KB. Uploading them to an unfamiliar server is a small risk taken for convenience — one that does not have to be taken.
Photos that carry more than pixels. A phone photo contains EXIF metadata: GPS coordinates, camera serial number, timestamps. Re-encoding through a canvas rebuilds the file from pixels alone, so that metadata does not survive — whether the encoding happens locally or on a server. The difference is that with a server, the un-stripped original is uploaded first.
Work files under embargo. An unreleased product photo, an unpublished chart, a screenshot of internal tooling. The usual objection to online tools in this situation is not the compressor — it is the upload.
No account, no quota, no watermark. A browser-local tool has no per-image server cost, so it has no commercial reason to meter you, brand your output or ask you to register. Caps exist to pay for servers. Remove the server and the caps go with it.
What this design gives up
Being honest about the tradeoff is more useful than pretending there is none. Browser-local compression is the right default for one file at a time, but it loses in a few places:
Batches in the hundreds. Your tab does the work, so a five-hundred-image job will keep a tab busy and a phone warm. A server farm is genuinely better at that.
Formats browsers cannot decode. HEIC from an iPhone is the common one. Decoding it in the browser needs a WebAssembly decoder measured in megabytes, so this tool does not take HEIC. Convert to JPG first.
Features that need a model. Background removal, upscaling, subject-aware cropping — those need compute a tab should not be asked for. Use a server tool, and upload deliberately.
Knowing which side of that line you are on is more useful than any single tool's marketing claim, including this one.
Confirming it takes thirty seconds
You do not have to take the claim on trust. Open DevTools, switch to the Network panel, drop a photo, and watch: no request carries your image. Then reload the page once with the network on, disconnect, and compress again — it still works, which it could not do if a server were involved.
The full walkthrough, including what to look for in the request list and how to read /assets/app.js yourself, is on the security page.
Questions
What does “browser-local” mean?
It means the file is read, decoded, resized and re-encoded by JavaScript inside your own browser tab. No bytes are sent anywhere, because the page contains no upload endpoint to send them to.
Is this actually different from other free compressors?
The mechanism is. Most online compressors — TinyPNG, iLoveIMG, compressjpeg and the free tools inside Adobe and Canva — compress on their servers, which is why your file has to be uploaded first and why free tiers need caps and sometimes watermarks. A browser-local tool has no server cost per image, so there is no reason to cap or watermark.
Does “no upload” mean it is private?
It means the image cannot be stored, logged, mined or leaked by this site, because it never reaches this site. It does not mean your device or network is private in general — that is a separate question from what this page does with your file.
Can I really use it offline?
Yes. Load the page once, then cut your network and compress a photo. Everything the encoder needs is already in the tab. A server-side compressor cannot do this.
When should I use a server-side compressor instead?
Large batches, unusual formats like HEIC from an iPhone, or when you need AI features such as background removal. Those genuinely need more compute than a browser tab should be asked for, and they are honest reasons to upload.
Does it work on mobile?
Yes — iPhone Safari and Android Chrome both expose the Canvas encoder the tool uses. Very large photos may take a few seconds longer on a phone than on a desktop.