Why compressing in your browser matters
The reason most "free" image compressors ask you to upload your files first isn't technical — a modern phone processor can compress a 12-megapixel JPEG in about 200 milliseconds. The reason is business model: your images on their servers means your images can carry ads, force a signup wall, throttle you into a paid tier at file #6, and get quietly kept in a database somewhere for reasons you don't get to audit. It's the trade every "free" image tool has to make — except the ones that skip the server entirely.
The tool above compresses locally, in your browser. When you drop an image on it, no HTTP request goes out with your file — your browser reads the bytes from your disk, resizes and recompresses them using the same codec libraries built into every operating system, and hands you a download. You can prove it yourself: open DevTools (F12), go to the Network tab, drop a file, and watch the request list stay empty. The image never leaves your device.
That matters most for the files you have the most reason to keep private — scanned documents, screenshots of confidential slides, photos of receipts, images that contain someone's face. The convenience of a browser tool shouldn't require handing all of that to a third party.
The "free tier" trick
Almost every popular image compressor is really an upload service that runs their compressor on their servers. That funds itself two ways: showing you ads (which is why you'll wait through 3 modals to get one 80KB file), and pushing you to a paid plan the moment you hit a hidden limit. Here's what the category actually offers:
| Tool | Where compression happens | Free-tier catch |
|---|---|---|
| TinyPNG / TinyJPG | Their servers | 20 images per batch, files <5 MB. Above that: paid API only. |
| Smallpdf image compressor | Their servers | 2 free tasks per day. Aggressive Pro nag; some features hidden behind "start free trial" (which becomes paid). |
| iLoveIMG | Their servers | Batch limits on free tier; hard cap on file size. Larger files → Premium signup required. |
| Compressor.io | Their servers | 10 MB file limit on free plan. Cap raises with paid plan. |
| Squoosh (Google) | Your browser — honest exception | None on compression itself. UI is designed around single-file tinkering, not batches. |
| This tool | Your browser | None. Batch size, file size, and daily count are all limited only by your device's RAM. |
Prove it yourself: before dropping a file, open DevTools (F12 on desktop) and switch to the Network tab. Compress an image and watch — no request appears for your file. Compare with any of the server-based tools above and you'll see the upload happen in real time.
Which format should the output be?
The right format is a function of what the image contains and where it's going. The three formats this tool exports cover essentially every practical case:
| Format | Best for | Where it fails | Browser support |
|---|---|---|---|
| JPEG | Photos, screenshots of continuous-tone images, anything with smooth gradients. The default for cameras. | Text, sharp edges, transparency (unsupported). Repeated re-saves visibly degrade quality. | Universal (every browser, every email client, every OS). |
| PNG | Screenshots of software, diagrams, logos, anything with sharp edges or transparent backgrounds. | Photos — files come out 5–10× larger than the same photo as JPEG for no visible quality gain. | Universal. |
| WebP | The web. Same quality as JPEG at 25–35% smaller file size. Supports transparency and animation. | Older email clients and some older desktop apps still can't open .webp. Print vendors often reject WebP. | All browsers since 2020. Not universal outside the browser. |
| AVIF (not exported here yet) | The next-generation web format, ~50% smaller than JPEG. | Safari support only landed in 2022; older email/apps don't read it. | Modern browsers. Not universal. |
Practical rule: if the file is going into an email attachment, a Word document, a print job, or someone else's OS you don't control, use JPEG. If it's for a webpage you own and can rely on modern browsers, use WebP. If it needs transparency, use PNG (or WebP for the web).
Quality vs file size — the actual math
JPEG and WebP both have a quality slider from 1 to 100. It is not a percentage of original quality — it's the compression algorithm's setting for how aggressively to discard information the human eye is less sensitive to. The relationship between the number and the file size is not linear at all.
Rough benchmarks for a typical 12-megapixel photo (4000 × 3000 px):
| Quality | Typical file size | What you can tell | Use for |
|---|---|---|---|
| 100 | 7–10 MB | Indistinguishable from original. | Nothing — wasteful. You can't tell 100 from 92. |
| 92 | 2–3 MB | Indistinguishable from original for practically anyone. | Print work; archive copy. |
| 85 | 900 KB – 1.5 MB | Truly indistinguishable at normal viewing. | The "safe default" for web images. Most photos on the internet ship at 80–85. |
| 75 | 500–800 KB | You can find compression only if you zoom in on smooth gradients (sky, skin). | Blog images, product photos, most social uploads. |
| 60 | 250–450 KB | Visible on gradients and fine detail at 100% zoom; still fine at reading distance. | Fast-loading blog images, thumbnails. |
| 40 | 140–260 KB | Obvious "JPEG look" in smooth areas and around text. | Only when total page weight matters more than pretty (very slow connections). |
Above ~85, you're spending bytes on quality nobody can see. Below ~60, quality drops off a cliff. The sweet spot for most web work is 75–85. That's why the tool defaults to 75 — good starting point you can nudge up if the output looks off.
Resize before you compress — the biggest lever
Compressing a 4000-pixel-wide photo to 75% quality shrinks the file. Resizing that photo to 1200 pixels wide and then compressing to 75% quality shrinks it about 10× more. If the final display size is 1200 pixels wide (which it is for most website use), the pixels beyond 1200 are pure waste — they weigh a lot and add nothing.
Rule of thumb by destination:
| Where it's going | Max width worth exporting | Typical final file size |
|---|---|---|
| Email attachment | 1600 px (most inboxes cap attachments at 25 MB anyway) | 200–500 KB |
| Blog / article hero | 1600 px (retina) or 1200 px (standard) | 150–350 KB |
| Product photo on a webpage | 1200 px | 80–180 KB |
| Social upload (Instagram, X, LinkedIn) | 1080 px (they'll re-compress it further anyway) | 150–300 KB |
| Avatar / profile picture | 512 px | 30–80 KB |
| Thumbnail | 300 px | 10–30 KB |
| Print at 6" wide, 300 DPI | 1800 px (do not downsize below this) | 500 KB – 1.5 MB |
Common use cases with exact settings
Attaching photos to email without hitting the 25 MB cap
Drop your photos in, set max width to 1600 px, quality 80, format JPEG. Ten holiday photos that were 5 MB each (50 MB total, over the cap) come out around 3 MB total — well under.
Making a blog post fast
Hero: 1600 px wide, quality 80, WebP (or JPEG for the fallback), aim for ≤300 KB. Inline images: 1200 px wide, quality 75, aim for ≤150 KB. Two 3 MB images on a blog post add a full second of load time on 4G — replace them and Core Web Vitals scores jump immediately.
Uploading to Instagram / TikTok / LinkedIn without them re-crushing it
Every social platform re-compresses your image. If you start with a 4000-pixel oversharpened 8 MB file, their compressor will do rough work on it and it will look muddy. Pre-compress to 1080 px wide (the platform's own display width), quality 90, JPEG. The platform will still re-compress, but from a cleaner baseline — the final render on the feed looks noticeably sharper.
Sending product photos to a print vendor
Print needs 300 DPI at the finished size. For a 6-inch-wide print, that's 1800 px minimum. Do not aggressively compress — quality 92 or PNG. Print exposes JPEG artifacts that a screen hides.
Shrinking screenshots for a bug report or PDF
Screenshots have sharp edges and text — use PNG (quality slider doesn't apply). If the screenshot is a full 4K screen (3840 px wide) and only the bottom-left window matters, crop before compressing. Then resize to 1600 px wide if it's just for reference. A 4K screenshot at 3 MB becomes a 250 KB PNG that still reads clearly.
Getting under a form's "2 MB max upload" limit
Government forms, job applications, some CMS uploads all have hard caps. Start at max width 2000 px, quality 80, JPEG. Check the resulting size — if it's still over, drop max width to 1500 px, then to 1200 px. Almost every 2 MB cap can be met at 1500 px, quality 75, without visible loss.
Making thumbnails for a product catalog
Batch-drop 100 product photos, set max width to 400 px, quality 80, JPEG. Download the ZIP. Every thumbnail is under 40 KB — a whole catalog page loads in under a second.
Compression myths worth killing
"There's a way to compress without losing quality"
Yes and no. Lossless compression exists — PNG, WebP-lossless, and format conversions between them — and preserves every pixel exactly. But the file-size savings from lossless are modest (typically 10–30% for photos). The dramatic 80-90% savings people expect from compression only come from lossy algorithms (JPEG, WebP-lossy), which discard visual information. The trick is that a well-tuned lossy compressor discards information the human eye is bad at seeing — so 85-quality JPEG looks identical to the original to a normal viewer even though it's ~10% of the file size. It's not "no loss," it's "no visible loss," and those aren't the same thing.
"WebP always beats JPEG"
Only on the web. Send a .webp file to a print vendor, an older email client, a Word document, or your accountant's ancient Windows machine and you'll get a "can't open this file" response. If the destination isn't guaranteed to be a modern browser, JPEG is the safer bet.
"Higher quality means bigger file, linearly"
Not remotely. Going from quality 85 to 100 can double the file size for zero visible change. Going from 75 to 85 is usually only a 25% size increase. The knee of the curve is around 80–85 — that's the compression algorithm's sweet spot for most images.
"PNG is 'better quality' than JPEG"
PNG is lossless. For photos, that just means PNG stores every JPEG-invisible detail at 5–10× the file size. For screenshots, diagrams, or anything with hard edges and flat colors, PNG is genuinely better — it stores those pixels exactly instead of introducing JPEG's characteristic edge fuzz. Match the format to the content.
How to prove nothing was uploaded
This is worth doing once for any privacy-sensitive tool, not just this one.
- Open the tool page in your browser.
- Press
F12(or right-click → Inspect) to open DevTools. - Click the Network tab.
- Click the little "clear" button (⊘) to empty the request list.
- Drop an image on the tool. Watch the Network tab.
If files were being uploaded, you would see a POST request with the file's size in the "Size" column — typically several MB. On this tool, no such request appears. The only network activity is the initial page load; after that, everything is your browser talking to itself.
You can also do the same check on any competitor tool to see the upload happen in real time. That single check is the fastest way to know if a "free, private" claim is honest.
Frequently asked questions
What formats can this tool read and write?
Reads: any image format your browser supports — JPG/JPEG, PNG, WebP, GIF, BMP, most cameras' HEIC on newer browsers. Writes: JPEG, PNG, and WebP. Format conversion is automatic when you pick a different output format from the input.
Is there a file size limit or batch limit?
Only your device's RAM. On a laptop with 8 GB of RAM you can comfortably batch 50–100 typical photos; more if you close other tabs. On a phone with 4 GB, 10–20 images per batch is a safer number.
Are my images ever seen by anyone?
No. The compression runs entirely in your browser using its built-in canvas and codec libraries. Nothing about your images — not the file, not a thumbnail, not a hash — is sent anywhere. You can verify this with the DevTools Network tab (see the section above).
What quality setting should I use?
Start with 75. If the output looks visibly worse than the original on the specific images you care about, nudge up to 80–85. Above 90 you're spending file size on quality no viewer can see. Below 60 you'll see obvious artifacts on smooth areas like sky or skin.
Why is my PNG output bigger than my JPEG input?
PNG is lossless — it stores every pixel exactly. If you convert a photo from JPEG to PNG, you're taking an already-lossy compressed file and re-storing it losslessly, which is almost always larger. PNG is the right choice for screenshots, diagrams, and logos; JPEG (or WebP) is the right choice for photos.
Does resizing before compressing lose quality?
Not in the way you're thinking. Making an image smaller than its original resolution is a one-way operation — you can't get the extra pixels back. But if the image will only ever be viewed at 1200 px wide, resizing to 1200 px is neutral (nobody sees pixels you display). What loses quality is enlarging a small image — that has to invent detail that isn't there.
Can this handle transparent backgrounds?
Yes — for PNG input, transparency is preserved when you output as PNG or WebP. If you output as JPEG (which doesn't support transparency), the transparent areas fill with white. Keep the format as PNG or switch to WebP if you need transparency in the output.
Why does the file size sometimes get bigger, not smaller?
Two most common causes: (1) you're converting a compressed photo (JPEG) to a lossless format (PNG); (2) the original is already highly optimized and your chosen quality setting is higher than whatever compressed it before. Lower the quality slider or match the input format.
Can I use this on a phone?
Yes — it works in mobile browsers. Tap the drop zone to choose photos from your camera roll. Compression happens on the phone, so nothing leaves your device. On older phones, work in smaller batches (5–10 images at a time) to avoid running out of memory.
Does resizing preserve aspect ratio?
By default, yes — the "keep aspect ratio" toggle is on. Only set a max width; the height is calculated to preserve the original proportions. Uncheck it only if you deliberately want to distort proportions (rare).