What is the real difference between TinyPNG and Squoosh?

The core difference is where your files get processed and how many you can handle at once. TinyPNG uploads your images to its servers and compresses up to 20 per free session. Squoosh processes everything inside your browser, so nothing leaves your device, but it handles one image at a time. That split drives almost every other difference between them.

Everyone who compresses images eventually hits this question. TinyPNG is the default "make this smaller" tool people reach for. Squoosh is the one developers recommend when someone asks for something private and free. They look interchangeable from a distance, but the differences matter once you pick a workflow.

How do TinyPNG and Squoosh compare side by side?

TinyPNG wins on batch convenience and integrations, while Squoosh wins on codec control, offline use, and privacy. Neither tool lets you type an exact target file size. The table below maps the differences, and the sections after it explain when each row should change which tool you open.

TinyPNG optimizes for convenience: drop a batch and download the results. Squoosh optimizes for control: you get sliders for quality, resize options, palette reduction, and a choice of codecs, plus a side-by-side preview with a draggable divider so you can see exactly what each setting does to quality before you save.

Which one compresses better?

Both compress well enough that JPEG and PNG differences are hard to spot at normal display size. TinyPNG uses its own smart lossy method, so results look clean without touching a setting. Squoosh hands you codecs like MozJPEG and lets you dial quality yourself. Neither wins on quality alone, so pick based on how many decisions you want to make.

TinyPNG is better when you want zero decisions. Squoosh is better when you care about a specific format or want to dial quality against file size yourself. If you just need a photo smaller with no fuss, either one does the job.

Which one is better for privacy?

Squoosh wins on privacy. Everything runs in your browser, so your images never touch a server. TinyPNG uploads every file for processing, which barely matters for screenshots and blog art but settles the question for client photos, ID scans, or anything under a non-disclosure agreement. Where your data goes is the difference most roundups skip.

This matters more in 2026 than it used to. File size comparisons are easy to write, but the interesting difference between these tools is where your data goes. I wrote an earlier post that compares TinyPNG alternatives on privacy.

How much do TinyPNG and Squoosh cost?

TinyPNG is free for 20 images per session at up to 5 MB each, with Web Pro at $39 a year and Web Ultra at $149 a year for larger files and unlimited compressions. Squoosh costs nothing, with no tiers, no accounts, and no paid version. Check TinyPNG's pricing page before you buy, since subscription numbers change.

There is also a developer API with its own pricing on TinyPNG's side. Squoosh is an open-source project from Google Chrome Labs, and the web app is the whole product. I re-checked TinyPNG's pricing page while writing this, and the free limits and annual prices above match what it shows today.

When should you pick TinyPNG?

Pick TinyPNG when you have a batch of images and want them smaller with almost no setup. The 20-image free batch covers occasional work, and the quality is good enough that you can skip the settings panel entirely. TinyPNG also wins when your team needs an API or a WordPress plugin that Squoosh does not offer.

The trade-off is the upload. If your files are sensitive or your connection is slow, sending every image to a server costs you time and bandwidth.

When should you pick Squoosh?

Pick Squoosh when control or privacy matters more than batch speed. Codec choice matters if you are converting to WebP or AVIF and want to preview each setting. Browser-local processing matters if images should not leave your machine. Offline mode matters anywhere the network is unreliable, and the trade-off is repeating the process for every image.

The trade-off is the single-file workflow. Optimizing ten images means repeating the process ten times, which gets old fast. Squoosh is a precision instrument for one image at a time.

What can neither tool do?

Neither TinyPNG nor Squoosh lets you type an exact target size. If an upload form rejects anything over 100KB, you compress, check the result, nudge quality, and try again until the file fits. That loop works for one photo, but doing it for twenty images is slow guesswork that eats an afternoon.

That exact-KB gap is what I built SnapShrink for. It combines the parts of each tool that people actually want: batch processing like TinyPNG, browser-local privacy like Squoosh, and a target-size mode where you type "100" and the encoder hits it automatically. You can read the full walkthrough on how to compress an image to an exact KB size.

Is there a third option worth trying?

If you need a private batch that also hits a hard size limit, neither tool covers the full combination. SnapShrink does: up to 10 images free per session, no per-file size cap, on-device processing, WebP built in, and a target-KB mode. Pro costs $9 once, which is less than a year of TinyPNG Web Pro.

Plenty of write-ups already praise browser-local compression, batching, and watching a KB budget. Fair enough, those ideas are not unique. What SnapShrink adds on top is the typed target: you enter 100, and the encoder binary-searches quality until the download lands at or under that budget, across the whole batch, without an upload step. You are not nudging a quality slider and re-checking file size by hand after every try.

It does not replace both tools. If you need an API, TinyPNG still wins. If you want codec-level control over a single image, Squoosh still wins. SnapShrink wins the middle case: batches, privacy, and exact sizes. Try the free image compressor and see which camp you fall in.

FAQ

Is Squoosh really free?

Yes. Squoosh is an open-source project from Google Chrome Labs with no paid tier, no accounts, and no usage limits. The web app at squoosh.app is the complete product.

Does TinyPNG upload my images to its servers?

Yes. TinyPNG's compression runs server-side, so every image you drop on the page is uploaded, processed, and sent back. That is also why the free tier caps files at 5 MB each.

Can Squoosh compress multiple images at once?

No. The Squoosh web app processes one image at a time. For batches you repeat the steps per image, which is the main reason people reach for a batch tool instead.

Can either tool compress to an exact file size?

No. Neither TinyPNG nor Squoosh has a target-size mode. You adjust quality and check the output until the file fits, which is trial and error. For a walkthrough of typing a hard KB budget, see how to compress an image to 100KB.

Which is better for converting images to WebP or AVIF?

Squoosh, because it gives you a choice of codecs and a live preview of what each one does to quality. TinyPNG supports WebP and AVIF output too, but with fewer controls. For when WebP beats PNG on the web, see the WebP vs PNG guide.

Which one is better for website speed and Core Web Vitals?

Squoosh has a small edge. Core Web Vitals reward small files in modern formats, and Squoosh gives you direct control over both: AVIF output with a quality slider you can tune against the preview. TinyPNG also shrinks files well, which is most of the battle. The bigger win is serving WebP or AVIF at the right dimensions, and either tool can produce those.

Does Squoosh work well on mobile?

Yes. Squoosh runs in the mobile browser and installs as a Progressive Web App, so it keeps working offline after the first load. The controls are usable on a phone screen. TinyPNG works in a mobile browser too, but every image still uploads first, which is slow on cellular data.

Do TinyPNG and Squoosh strip EXIF metadata?

TinyPNG strips metadata during compression on its servers, per its documentation. With Squoosh, nothing leaves your device, so there is no server copy of your metadata to worry about. Whether EXIF survives in the output depends on the codec and settings you choose, so check the output file before publishing if metadata must be gone. For the full walkthrough, see how to strip metadata from photos.

Sources and further reading

• TinyPNG Web Pro and Web Ultra pricing
• Squoosh web app
• How to compress JPEG file size

The WebP vs PNG question is a delivery decision, not a specs debate. Pick the wrong format and your pages carry weight they do not need; pick the right one and you get the easiest performance win on your site. Here is what each format is actually for, where each one wins, and the workflow that lets you stop choosing.

WebP vs PNG in 60 seconds

WebP is Google's image format from 2010, available in lossy and lossless modes. In lossless mode it runs about 26% smaller than PNG; in lossy mode it runs 25 to 34% smaller than JPEG at similar quality, per Google's own documentation. PNG answers with universal compatibility, deeper color support, and no upper bound on dimensions.

Sources: compression figures from Google's WebP documentation; max dimensions from Google's WebP FAQ.

Two things the table hides: WebP's only real weakness is compatibility, not capability. PNG's only real weakness is file size. Everything below follows from that.

When WebP wins

WebP wins anywhere an image gets served to a browser. At similar visual quality it is roughly a quarter smaller than PNG, and that saving multiplies across every image on the page. On galleries, product listings, and blog archives, that is the gap between a page that feels instant and one that drags, especially on mobile data.

Anything served on a website. This is the core case. File weight feeds directly into Core Web Vitals like LCP, which is one more reason to care.

Transparency without the PNG tax. PNG's alpha channel is great and WebP matches it, including in lossy mode, which JPEG cannot do at all. A transparent logo or UI element as WebP is typically much smaller than the same PNG with no visible difference.

Photo-heavy pages. Lossy WebP at a sensible quality setting beats PNG by a wide margin on photographs, where PNG's lossless compression is the wrong tool entirely. If your photos are currently PNGs, switching them to WebP is usually the single biggest image win available.

Replacing simple GIFs. WebP supports animation with far better compression than GIF. One honest caveat about tooling: most batch converters treat GIF inputs as stills and convert only the first frame. If you need animated output, use a dedicated GIF-to-WebP tool, not a batch compressor.

When PNG still wins

An honest comparison has to say this plainly: there are jobs where PNG is still the right format, and converting everything to WebP would be a mistake. PNG wins when the image is a working file rather than a delivered one: masters, print, brand kits, and anywhere someone else's system touches it.

Editing masters. Keep your originals as PNG (or whatever lossless source you have). Every conversion is a generation of change; you want the master to be the highest-fidelity version. Convert copies for delivery, never the only copy you have.

Print and brand-kit delivery. Print workflows, design tools, and brand kits expect PNG. Nobody wants a .webp in a logo package. Deliver what the recipient's toolchain accepts.

Legacy systems and email clients. Older email clients, some CMS plugins, and partner systems that ingest images may reject WebP outright. When someone else's system is in the loop, PNG is the safe format.

Deep color. PNG supports up to 16 bits per channel, per the W3C PNG specification. If you are working with high-bit-depth sources, PNG preserves what WebP's 8-bit channels cannot.

Enormous images. WebP tops out at 16,383 x 16,383 pixels (WebP FAQ). For poster-size or survey imagery above that, PNG is the format.

None of this is an argument against WebP for web delivery. It is an argument for keeping both formats in your life, each doing its job.

The practical workflow: keep PNG masters, serve WebP

People who do this well do not convert files one at a time in a panic before launch. They run a simple pipeline: untouched PNG masters in a private folder, a small sample converted to lock in settings, then one batch pass for the whole folder. The site serves WebP; the private folder keeps PNG.

1. Keep masters in a private folder. Originals stay PNG, untouched, in a folder that never gets uploaded anywhere. This is your source of truth.

2. Convert a representative sample first. Pick 3-5 images that cover your range: a photo, a screenshot with text, a transparent graphic. Compare each against the original side by side at real display size.

3. Lock the settings. Once the sample looks right, those quality settings apply to the whole folder. No per-image fiddling.

4. Batch-convert the folder. Select everything, convert in one pass, download the batch as a ZIP. Name files consistently before you convert so the ZIP drops straight into your theme or CMS image directory without renaming.

5. Ship WebP, keep PNG. When you need to re-edit, you go back to the master, not the compressed copy.

One more thing the pipeline surfaces: re-encoding an image typically drops EXIF data (camera settings, and sometimes location) along the way. If you publish photos, read what image metadata gives away and how to strip it before you batch-convert.

Should I use WebP or PNG on a website?

Short version: WebP for everything the browser displays, PNG for everything else. That sentence answers it for anyone who searched this comparison, but the edge cases are where people get burned. The most common real-world mistake is not choosing WebP; it is converting the only copy and deleting the master, or shipping WebP into a system that cannot read it (hello, email newsletters).

Use WebP for hero images, thumbnails, blog media, product photos, and any image where file weight affects load time. If a destination supports WebP (modern browsers, most CDNs, most static site generators), it is the strong default.

Keep PNG for the five cases in the previous section.

For logos specifically: serve WebP on the site, keep PNG in the brand kit. The transparent-logo case is where WebP's savings are most dramatic, and it is also where a PNG fallback matters most for compatibility.

And if you are wondering "which is better" in the abstract: neither. They are tools. The better question is always "better for what?"

Convert PNG to WebP without uploading your files

Most PNG-to-WebP converters work like this: you upload your files to their server, their encoder does the work, and you have created a copy of your images on someone else's disk. SnapShrink works the other way. The File API reads your images inside the browser tab, a Web Worker encodes them locally, and the bytes never leave your machine.

You do not have to take that on faith: open DevTools, switch to the Network tab, run a batch, and watch for uploads. There will not be any. This is documented on the WebP converter page itself, which is the right place to be skeptical of marketing copy, including this post.

The practical version, using the free WebP converter:

1. Open the SnapShrink image compressor (no account, no install).
2. Set the output format to WebP.
3. Drop your PNGs (or JPGs) onto the drop zone: one file or a whole folder.
4. Optionally set a Target KB value if a portal demands a hard size cap. The tool searches for the quality setting that fits, so you can convert to WebP and hit "under 100KB" in one pass.
5. Download files individually or grab the whole batch as a ZIP.

The first 10 images per session are free. Because the encoding happens in a Web Worker, the tab stays responsive while a big batch churns through.

Converting to WebP is also a quality-control moment. If you are unsure how aggressive to be with the quality slider, the guide to compressing images without losing quality walks through what to look at before you commit to settings for a whole folder.

Frequently asked questions

Is WebP better than PNG?

For web delivery, yes: smaller files at similar quality, with transparency and animation support. For masters, editing, print, and compatibility, no: PNG is still the right format. "Better" depends entirely on the job.

Does converting PNG to WebP lose quality?

Only if you choose lossy mode and push the quality slider too low. Lossless WebP is pixel-for-pixel identical to the source at roughly 26% smaller (Google's figure). Convert a representative sample first and compare it against the original at real display size before batch-converting.

Can I use WebP everywhere?

Almost. All modern browsers display WebP (browser support data). The exceptions sit outside the browser: older email clients, some CMS plugins, print workflows, and partner systems that only accept PNG or JPEG. Serve WebP on the site; keep PNG for those.

Which format should I use for logos with transparency?

WebP on the website: the file-size savings on transparent graphics are substantial. PNG in the brand kit and anywhere the logo gets handed to someone else's toolchain.

Nawal Shrestha, founder of SnapShrink, building privacy-first browser tools.

Try it: free WebP converter (no signup, no upload, first 10 images free per session).

Originally published on the SnapShrink blog.

Every photo your phone takes ships with a hidden data file: GPS coordinates of where you stood, the exact date and time, your camera model, and sometimes a thumbnail of the original image. Stripping that metadata before you post, email, or upload takes seconds and changes zero pixels. Leave it in, and anyone who downloads the original can read where and when you took it.

This guide covers what is hiding in your files, who should care most, how to check, which platforms clean your files for you (and which do not), and how to strip metadata without uploading your photos anywhere.

What metadata is hiding in your photos

Your phone embeds EXIF metadata in every photo it takes: GPS coordinates of where you stood, the exact date and time, your camera model, and sometimes a full-size thumbnail of the original. You never see any of it in the gallery app. Anyone who downloads the original file can read it in seconds with free software.

EXIF (Exchangeable Image File Format) is the standard that defines these tags, maintained through the JEITA and CIPA camera industry specifications. Here is what a typical phone photo carries:

Screenshots carry less: usually no GPS, but device model, software version, and timestamps can still be in there. Strip them the same way before posting publicly.

Why this actually matters for privacy

A casual upload can hand strangers your home address. EXIF geotags are precise enough to place a photo at a specific house, and that data travels with the file unless something strips it. Online sellers, parents posting kids' photos, and job seekers sending resume photos all leak location this way without realizing it.

This is not theoretical. In 2012, Vice published a photo of John McAfee taken on a phone with geotagging enabled. The GPS coordinates embedded in the file placed him in Guatemala, and he was arrested two days later. Ordinary people do not attract that kind of attention, but the mechanism is identical when a marketplace listing photo carries the GPS of your living room.

Who should care most:

• Online sellers: listing photos with your home GPS embedded is a real privacy leak.
• Job seekers and freelancers: a resume photo with location data tells strangers where you live.
• Parents: kids' photos with location tags deserve a second thought before posting.
• Journalists and activists: source protection starts with clean files.

How to check what is in your photo first

Checking takes ten seconds and it is worth doing before you share anything publicly. On Windows, right-click the file, open Properties, and look at the Details tab. On a Mac, open the photo in Preview, go to Tools, then Show Inspector. If you see GPS coordinates or camera info, the file needs cleaning.

Online EXIF viewers exist too, but uploading a personal photo to a random site just to check its privacy is self-defeating. Prefer the offline methods above.

Which platforms strip it, and which do not

WhatsApp, Facebook, and Instagram strip EXIF data, including GPS, when you send photos through their normal flows. Email attachments, AirDrop originals, forum uploads, and "send as document" transfers usually preserve it. Some services are worse: GitHub preserves all tags including location. Platforms also change behavior silently, so never rely on the destination to clean your files.

Quick reference:

How SnapShrink strips metadata by default

SnapShrink re-encodes your image from raw pixels, which is why the metadata cannot survive. EXIF lives in a separate segment of the JPEG file, not in the pixel data, so when the browser decodes the photo and writes a fresh file, the tags have nowhere to go. Remove photo metadata is on by default for every download.

A bit of background on why this works: JPEG stores EXIF in a dedicated APP1 segment of the file, separate from the image data itself. When a browser-based tool decodes the photo into a bitmap and re-encodes it, only pixel values cross that boundary. The createImageBitmap() web API, which MDN documents as producing bitmap data from an image source, works on exactly this principle: pixels in, pixels out, with no file container carried along.

This is also why stripping never affects image quality. Metadata is not pixel data, so removing it changes zero pixels. The image looks identical; only the hidden fields are gone.

To clean a photo in SnapShrink:

1. Open the tool in your browser. No signup, no install.
2. Drop your photos in, up to 10 per session free.
3. Leave "Remove photo metadata (EXIF/GPS)" checked. It is on by default.
4. Compress or convert as usual, then download. Check Properties/Details or the Preview inspector on the output: the fields come back clean.

The file never leaves your device. Re-encoding happens in your browser tab, so there is no server copy to worry about.

When to keep metadata instead

Keep metadata only when the data itself is part of the deliverable. Client photography archives, print workflows, and photojournalism need EXIF intact for provenance. For everything you post, email, or list for sale, stripped is the safer default. In SnapShrink, uncheck the toggle for JPEG output; WebP and PNG outputs do not preserve EXIF either way.

One more caution: stripped metadata cannot be recovered. Once the file is re-encoded without EXIF, the tags are gone for good. If the metadata matters to you, for an archive or for legal evidence, keep an untouched original somewhere safe and only share the cleaned copy.

FAQ

What metadata do photos carry?

Phone and camera JPEGs embed EXIF tags: GPS coordinates, camera model, lens, capture time, and sometimes software names. That data travels with the file when you email, upload, or share it.

Does SnapShrink strip EXIF by default?

Yes. Remove photo metadata is on by default. Every compressed download ships without EXIF/GPS unless you turn the toggle off for JPEG keep-metadata mode.

Are my photos uploaded when metadata is stripped?

No. Stripping and compression run in your browser on your device. Nothing is uploaded to SnapShrink servers.

Can I keep EXIF when I need it?

For JPEG output only, uncheck Remove photo metadata. WebP and PNG outputs do not keep EXIF either way.

Do WhatsApp and Facebook strip metadata automatically?

Mostly. WhatsApp, Facebook, and Instagram strip EXIF, including GPS, through their normal flows. But "send as document", email attachments, AirDrop originals, and direct file shares usually preserve it. Strip before sharing rather than trusting the platform.

Does stripping metadata affect image quality?

No. Metadata is separate from pixel data, so removing it changes zero pixels. The image looks identical; only the hidden fields are gone.

Can stripped metadata be recovered?

No. Once re-encoded without EXIF, the data is gone. Keep an original copy if the metadata matters to you.

Clean your next upload in seconds

Open SnapShrink, drop a photo, and compare the Details tab before and after. Ten images per session, free, no signup. If you also need to hit a file size cap, compress an image to 100KB online with the same workflow.

Originally published on the SnapShrink blog.

Why JPEGs are still too big

JPEG is already a compressed format, which confuses people. Compressed sounds like it should be small. But a modern phone photo lands at 3 to 12 MB, and a DSLR raw-to-JPEG export can be larger. That is fine for archival storage. It is terrible for everything else: email attachments bounce, CMS uploads crawl, and portals with byte caps reject the file outright.

File size comes down to four things: resolution, noise, fine detail, and how aggressively the camera encoded the original. A noisy indoor shot at full resolution will always be heavier than a clean daylight photo at the same dimensions. Keep that in mind. It explains why the same quality setting produces different file sizes on different photos, which matters in the next section.

The three ways to compress JPEG file size

Every JPEG compression method you have ever seen is one of these three: lower the quality slider, shrink the pixel dimensions, or convert to a more efficient format. In practice the best results combine all three, in this order: resize to the display size first, then compress to the target size.

Lower the quality. The classic slider. Fast, but imprecise. You guess a number, check the size, guess again. Fine when there is no hard cap.

Shrink the dimensions. A 4000px-wide photo displayed at 800px is carrying five times the pixels it needs. Resizing first is the highest quality-per-byte move you can make, and most people skip it.

Change the format. If the destination accepts WebP, converting typically cuts 25 to 35 percent at the same visual quality, measured in Google's own WebP compression study. If it requires JPEG, many portals still do, stay in JPEG. I go deeper on the trade-offs in WebP vs PNG: which should you use.

How to compress JPEG file size without uploading anything

Most "compress JPEG online" tools make you upload the photo to their server, process it there, and hand back a download link. That works, but your file just traveled to a stranger's infrastructure, and their retention policy, not yours, decides how long it stays.

I built SnapShrink to do the whole job inside your browser tab instead. The browser reads your file with the File API, draws it onto a canvas, and re-encodes it with a chosen format and quality, all locally. That encoder API is canvas.toBlob(), which MDN documents as accepting a type and a 0-to-1 quality parameter for lossy formats like JPEG and WebP. Here is the actual workflow:

Step 1: open the tool. Go to SnapShrink. No signup, no wall. You will see a drop zone, quality controls, a Target KB field, and an output format picker.

Step 2: drop your JPEGs. One file or a whole folder. Mixed batches with PNG and WebP are fine. Files over 50 MB get skipped with a clear message instead of crashing the batch, and corrupt files are skipped the same way.

Step 3: pick your method. Quality slider for quick shrinks, Target KB when a portal demands an exact number, or WebP output when the destination allows it. Typing 100 into Target KB gives you a file of 100KB or less, because the engine binary-searches quality to find the highest setting that fits. For portal caps specifically, see my guide on how to compress an image to 100KB online.

Step 4: compress and inspect. Each finished image shows original size, new size, and ratio. Check faces, text overlays, and product edges at 100 percent zoom before you ship the file. If skin looks waxy or text fringes, you went too far. Raise the target slightly.

Step 5: download. Single files or Download all as ZIP. The ZIP is assembled in the browser too. First 10 images per session are free, and a one-time 9 dollar license removes the quota.

You can verify the no-upload claim yourself: open DevTools, go to Network, compress a batch, and filter for uploads. There won't be any. I built it this way because I got tired of wondering where my client photos went after using hosted compressors.

Target size vs quality slider: which one to use

Use the quality slider when there is no hard cap. You are just making files smaller for a faster site or a lighter email. Start around quality 80, check the result, adjust once. Use target size when a number is non-negotiable: visa portals, exam forms, "maximum 100KB" fields. Typing 100 and getting 100KB or less beats five rounds of guess-and-check.

One thing worth knowing: quality percentages are not standardized across encoders. Quality 80 in one tool is not the same file size as quality 80 in another. MDN notes that each browser applies its own default quality when none is specified, and encoders interpret the 0-to-1 range differently. That is why slider advice like "just export at 80 percent" is unreliable across tools, and why naming the size you want is the more honest approach.

Resize first: the step everyone skips

The mistake I see constantly: someone takes a 4000 by 3000 photo, sets quality to 40 trying to hit 200KB, and ends up with mush. The right move was resizing to 1200 by 900 first, then compressing at quality 80. Similar file size, dramatically better looking.

The math is simple. Halving each dimension quarters the pixel count. Fewer pixels means the quality budget stretches further. If you know the display size, an 800px email template or a 1200px blog hero, resize to it, or slightly above for retina, before you touch quality.

SnapShrink does not resize for you yet, so do this step in your OS photo app first. It takes thirty seconds and it is the single biggest quality win in this whole guide.

How to compress JPEG file size on iPhone and Android

The same workflow runs on mobile, and it is identical on both platforms. On iPhone, tap the drop zone in Safari and pick from Photos or Files, then set quality or a target and download. One wrinkle: iPhone photos are usually HEIC. Safari hands HEIC to the browser as JPEG through the system picker, so SnapShrink receives a JPEG and processes it normally. No separate conversion step.

On Android in Chrome, the flow is the same. Pick from the gallery or Files, compress, and the download lands in your Downloads folder for attaching wherever you need it. For portal caps on mobile, the Target KB field is the whole game, same as desktop. If the form says 100KB, type 100 and you are done.

Batch compress JPEGs without the tedium

If you are prepping product shots or a blog media library, do the folder in one pass. Drop everything into SnapShrink, set one quality or target size, and download the ZIP. The same settings apply across the batch, which keeps a product gallery visually consistent, something you lose when you hand-tune files one by one.

Keep your originals somewhere safe and only ship the compressed set to the CMS. Disk is cheap. Re-shoots are not.

Mistakes that ruin JPEGs

There are five, and I have watched people make every one of them. First, re-saving the same JPEG repeatedly. Every lossy pass adds artifacts, so always compress from the original, once. Second, cranking quality to minimum. Skin tones band and gradients posterize, so if quality 30 looks bad, the answer is resizing first, not going lower.

Third, ignoring the required format. Some portals still reject WebP, so check before you convert a whole batch. Fourth, compressing thumbnails and expecting miracles. A 50KB thumbnail cannot become a clean 20KB hero image. Garbage in, garbage out. Fifth, uploading sensitive photos to random compressors. Passport photos, client work, unreleased designs. If a local tool exists, use it.

FAQ

Does compressing a JPEG always reduce quality?

Technically yes. JPEG is lossy, so recompressing discards some detail. The practical goal is finding the highest quality that meets your size need. Done right, resize first and use a sensible quality, the difference is invisible at normal viewing sizes.

Should I convert JPEG to WebP instead of compressing?

If the destination supports WebP, usually yes. Google's study measured 25 to 34 percent smaller files at equal quality. If a portal or old software requires JPEG, keep JPEG output. When in doubt, JPEG is the safe choice.

Are my photos uploaded when I compress them?

Not with SnapShrink. Everything runs in your browser through the File API and a Web Worker. Open DevTools, go to Network while compressing, and you will see zero file uploads.

Can I compress many JPEGs at once?

Yes. Drop a batch, set quality or a target size, and download a ZIP. The first 10 images per session are free.

Why is my JPEG still big at low quality?

Almost always resolution. A 4000px photo at quality 40 can outweigh a 1200px photo at quality 85, and look worse doing it. Resize first, then compress.

What is a good quality setting for web photos?

Quality 75 to 85 after resizing to display dimensions. That is the range where file size drops a lot and visible quality barely moves. Below 60, inspect carefully.

Compress your first JPEG free

Open SnapShrink, drop a photo, and set quality or a target size. Ten images per session, no signup.

What to look for in a TinyPNG alternative

Before comparing tools, decide what actually matters for your workflow. Most people leaving TinyPNG want the same five things: no uploads, no subscription, real batch handling, exact target sizes, and a free tier honest enough to test quality before paying anything. Keep that list handy. It's the scorecard for everything below.

1. No uploads. Your images never leave your device. This matters for client work, ID photos, unreleased designs — anything you wouldn't email to a stranger.

2. No subscription. A compressor that runs on your own CPU has no per-image server cost. Paying monthly for it is a business model, not a technical necessity.

3. Batch without friction. Real folders, not 20-files-at-a-time, with one ZIP at the end.

4. Exact sizes. A target-KB mode for portals with hard caps, instead of guessing with a quality slider.

5. Honest free tier. Enough free use to verify quality before paying.

What TinyPNG offers today

Fair description first — check their site for the latest, but as of late 2026:

TinyPNG's online compressor optimizes WebP, PNG, JPEG, and related formats on their servers. Their FAQ states free users can upload up to 20 images at once, each up to 5 MB. Free format conversion is limited to 3 images. For higher capacity they sell Web Pro and Web Ultra subscriptions. Uploaded images are retained for a maximum of 48 hours before deletion, per their privacy FAQ.

That's a clear, honest policy. It still means the bytes left your device for up to two days. For occasional single-page tweaks, the limits are fine. They get expensive or awkward when you regularly compress product folders, blog media libraries, or client deliverables.

SnapShrink vs TinyPNG

I deliberately don't quote TinyPNG's subscription prices here. Pricing pages change, and third-party roundups disagree with each other. The durable fact is structural: paid capacity is sold as a subscription, not a one-time license.

Why one-time pricing fits an in-browser tool

Server-side compressors pay for bandwidth, storage, and compute on every image, so subscriptions make commercial sense for them. An in-browser compressor has effectively zero marginal cost per image after the page loads. Your CPU does the work. Charging rent every month for that is a business choice, not a technical necessity.

SnapShrink charges $9 once: you pay through Dodo Payments, get a license key by email, paste it into the app, and verification happens offline with a cryptographic signature stored only in your browser. No seats, no "update your card" emails, no annual renewals. There's a 14-day money-back guarantee — one email, full refund (refund policy).

The privacy difference, and how to verify it yourself

Here's what most "TinyPNG alternative" roundups never tell you: how to check the claim.

Any compressor can say "we don't upload" or "we delete after 48 hours." With a server-side tool, you're trusting the policy. With an in-browser tool, you can verify in thirty seconds:

1. Open the tool and press F12 (DevTools) → Network tab.

2. Drop in a batch of photos and compress.

3. Filter the network log for uploads (POST/PUT requests with file bodies).

With SnapShrink, you'll see none, because there are none to see. The File API reads your images, a Web Worker encodes them, and the bytes never leave the tab. Try the same test on any server-side compressor and watch the difference. This is the single most useful thing I can teach you in this article: don't trust privacy claims, test them. See also the privacy policy.

There's a second privacy angle nobody talks about: EXIF data. Phone photos carry GPS coordinates, timestamps, and device info. When you upload to a server compressor, that metadata travels with the file, and you're trusting their pipeline to strip it. SnapShrink strips EXIF automatically during compression, on your device, before anything could ever leave it. (See the guide: Strip metadata from photos.)

Which tool for which person: a decision matrix

Want the full head-to-head of the two free options? See our TinyPNG vs Squoosh comparison.

The honest version: these tools overlap but aren't identical. TinyPNG has the ecosystem (API, plugins, CDN). SnapShrink has the privacy model and the pricing model. Pick the one whose strengths match your actual workflow.

When TinyPNG is still the better pick

Choose TinyPNG when you want their specific compression algorithm, the WordPress plugin, the developer API, or the CDN pipeline, or when you're happy uploading files and paying for Web Pro / Web Ultra. It's a good product; this article exists because the model (upload + subscribe) doesn't fit everyone, not because the tool is bad.

Switching takes two minutes

1. Open getsnapshrink.com/app/, no signup.

2. Drop your batch (JPG, PNG, WebP, GIF in; JPG, PNG, WebP out). The bulk image compressor is built for folders.

3. Set quality or type an exact target size, then download individually or as one ZIP. Prefer WebP when the destination allows it.

Your first 10 images each session are free, so compare output quality against TinyPNG on your own photos before spending anything. Zoom to 100% on faces and text. That's where encoder differences actually show.

FAQ

Is SnapShrink a TinyPNG alternative?

Yes, if you want batch compression without uploading files and without a monthly subscription. It runs entirely in your browser and unlocks unlimited use for $9 once.

What are TinyPNG's free limits?

Per their site: up to 20 images at once (5 MB each), 3 free format conversions. More capacity needs a Web Pro or Web Ultra subscription.

Is the $9 really one-time?

Yes. One payment through Dodo Payments, one license key by email, unlimited compressions. No subscription, no renewal. 14-day money-back guarantee.

Do I need an account?

No. No accounts, no passwords, no sync. Your license lives in your browser's local storage.

How is in-browser compression different, technically?

Your browser reads files with the File API and encodes them in a Web Worker. The same machine that took the photo does the compression. Server-side tools upload first, then process. The output quality depends on the encoder, not the location; the difference is privacy and cost structure.

Can I verify SnapShrink doesn't upload my images?

Yes. DevTools → Network during any batch shows zero file uploads. That's the whole point of the architecture.

Does SnapShrink strip EXIF/location data?

Automatically, on every compression, on your device.

What if I don't like it?

14-day money-back guarantee. One email, full refund. See the refund policy.

Can I use it for client work commercially?

Yes. The license covers your use; there are no seat limits.

Nawal Shrestha: founder of SnapShrink, building privacy-first browser tools.

Try it free

Open SnapShrink. 10 images per session, $9 once for unlimited. No subscription.

There is a simpler way. Name the size, and let the tool find the highest quality that fits. Type 100, get a file at or under 100KB, done.

Why 100KB limits still exist

Government and university portals process millions of files, and a hard per-file cap keeps storage costs and database rows predictable. A phone photo today is 3-8MB, so "under 100KB" means shrinking it to roughly 2% of its original size.

You will run into this cap on visa and passport photo uploads, exam and university admission portals, resume portals that reject oversized profile photos, scholarship and KYC forms, and banking document uploads. The bottleneck is storage and database row size, not your internet speed. Faster broadband never moved it, and it will not move soon.

The mistake most people make: crushing quality before resizing

100KB is mostly about resolution, not the quality slider. A typical phone photo saved as JPEG shows this clearly:

Sizes vary with image complexity; noisy photos run heavier. But the pattern holds: a 1200x900 photo at quality 60 is still ~140KB, while an 800x600 photo is comfortably under 100KB at the same quality. Lowering quality on a 12MP original is bad advice. Resize first, then compress.

How target-size mode works: type 100, get 100KB or less

Instead of guessing quality levels, type the size you need into a target-size box. In SnapShrink the flow is:

1. Drop your image at getsnapshrink.com/app. JPG, PNG, WebP, and GIF all work.
2. Type 100 as the target size in KB and pick your output format. WebP is smallest for photos, but check portal acceptance below.
3. The engine encodes at quality 95, then 50, then narrows the range. About 8 encodes find the highest quality that lands at or under 100KB.
4. If even quality 5 overshoots, the image scales down in 0.9 steps (never below 320px) and the search repeats.
5. You get the result with before and after sizes shown. On the rare image where 100KB is truly unreachable, it reports the best effort it managed instead of failing silently.

A standard 5MP phone photo typically finishes in under 3 seconds, processed in a background worker that keeps the page responsive.

Which format will the portal accept?

This is where people get burned: a beautiful 80KB WebP gets rejected, not for size, but for format. Older government and banking portals often accept only JPEG.

• Photo or camera shot: WebP or JPEG. WebP usually wins by about 25%.
• Screenshot or graphic with text: PNG or WebP, to keep edges sharp.
• Document scan: WebP or JPEG. Text stays readable far below 100KB in grayscale.
• Signature on white background: PNG or JPEG. JPEG is the safest choice for old portals.

When in doubt, use JPEG. It is the universally accepted format. Use WebP only when you have confirmed the portal accepts it, or when the file is for your own site rather than someone else's form.

From a phone

The process is identical in Safari on iOS and Chrome on Android: tap the drop zone, pick from camera roll or files, type 100, download. The file lands in Downloads, ready to attach.

One iOS detail: phone photos are typically HEIC, and Safari converts HEIC to JPEG automatically through the file picker. SnapShrink receives a JPEG and processes it normally, so no manual conversion is needed.

Why browser-only compression matters for documents

Passport photos, ID scans, and visa applications contain biometric data. Uploading those to a third-party compressor creates a data trail: how long the server actually retains the file, who can access it, and their breach notification obligations. You have no visibility into any of that.

SnapShrink processes images with the browser's Canvas API and a Web Worker. The bytes never leave your device. You can verify it yourself:

1. Open the tool and press F12, then open the Network tab.
2. Compress a photo.
3. Look for file uploads in the network log. There are none.

Thirty seconds and you have confirmed what no privacy policy can prove for a server-side tool. EXIF metadata (GPS coordinates, device info, timestamps) is stripped automatically during compression, so an ID photo does not carry location history into a portal database.

A batch of documents

A passport photo, a signature scan, a supporting ID: drop them all at once. SnapShrink's bulk compressor applies the 100KB target to each file individually, because every image needs a different quality level to hit the same cap. When the batch finishes, download everything as one ZIP with filenames intact.

When the image will not reach 100KB

Genuinely impossible cases are rare but real. A 320x320 photo already at 110KB at quality 1 in JPEG has nowhere left to go. Then:

• Switch to WebP. Usually smaller than JPEG at the same dimensions, if the portal allows it.
• Crop tighter. Border whitespace costs bytes, especially in JPEG.
• Resize to the portal's minimum. If it says minimum 200x200, try exactly 200x200.
• Grayscale for documents. Some portals accept it, and it compresses far more efficiently.
• Check the EXIF. A 50-200KB metadata payload on an unprocessed phone photo is dead weight; stripping it alone can close the gap.

The tool always reports the actual output size, so you know exactly where you stand instead of wondering whether a rejection was the size, the format, or the portal being slow.

FAQ

Is my photo uploaded to a server? No. Compression happens entirely in your browser. Open DevTools and watch the Network tab while compressing: zero file uploads.

What if my image cannot reach 100KB? Rare, but possible with very detailed images at small dimensions. You will see the smallest size achieved instead of a silent failure.

Which browsers work? Chrome, Edge, Firefox, and Safari handle WebP encoding natively. If yours cannot encode WebP, the tool says so and you pick JPEG or PNG instead.

Is there a file size limit? Files up to 50MB are accepted. Larger files are skipped with a clear message; the rest of the batch keeps going.

How is this different from Squoosh? Squoosh is excellent for single-image manual tuning. SnapShrink handles batch processing and target-size mode: type the cap, get there automatically. One image with pixel-perfect control: Squoosh. A stack of documents with a size cap: SnapShrink.

First 10 images per session are free. For regular document processing, a one-time $9 payment unlocks unlimited use with no subscription.

Originally published on SnapShrink: https://getsnapshrink.com/blog/compress-image-to-100kb-online/