I Compressed Every Image on a Client's Site. Here Is What an Image Compressor Actually Did to Speed, LCP, and Rankings.

Executive summary

An image compressor shrinks your image files so pages load faster, usually cutting 60 to 90 percent of file size with no visible quality loss at the right settings. That helps Largest Contentful Paint, one of Google's Core Web Vitals, and faster pages convert better. That part is real and measurable.

What you will learn: why compression is step two (resizing is step one), why converting JPEG to WebP or AVIF beats any quality slider, the right settings for photos versus screenshots, and an honest comparison of TinyPNG, Squoosh, ShortPixel, and other tools. You will also learn what compression cannot do. It will not guarantee rankings. Page experience is one signal among many, and anyone promising ranking jumps from compression alone is selling something.

This guide is written for local business owners, bloggers, WordPress users, and freelancers handling client media libraries. Every claim below has a number, a date, or a mistake attached to it.

What does an image compressor actually do to your files?

An image compressor rewrites your image data more efficiently, either throwing away detail your eyes cannot easily see (lossy) or removing redundancy without touching a pixel (lossless). A good lossy pass at 80 percent quality typically cuts a photo to around one-fifth of its original size while looking identical on screen.

Think of it like packing a suitcase. Lossy compression folds everything neatly and removes the three jackets you were never going to wear.

Under the hood, JPEG compression uses quantization: it splits the image into tiny blocks and rounds off subtle color variations. Your eye misses small brightness changes in busy areas, so the rounding is invisible. Chroma subsampling stores less color detail than brightness detail. That is how a 4MB photo becomes 800KB.

Here is what surprised me when I dug in. Much of the "compression" magic on PNG screenshots is actually color reduction. Tools like TinyPNG convert a 24-bit PNG into an 8-bit paletted image, keeping only the colors that are used. A screenshot with 200 distinct colors does not need 16 million available.

Compression cannot fix a fundamentally wrong file. A 6000-pixel-wide photo shown at 800 pixels wide carries far more pixels than it needs. Resize first, then compress. It is the most skipped step in every workflow I have audited.

Does compressing images really help SEO, or is that a myth?

Compressed images help SEO indirectly but genuinely. They reduce page weight, which improves Largest Contentful Paint and Core Web Vitals, and Google has confirmed that page experience is a ranking signal. But it is one of many signals, so compression supports rankings without guaranteeing them.

Let me separate the myth from the mechanism, because both exist.

The myth: "Compress your images and watch your rankings soar." I have seen this on a dozen tool pages. It is nonsense. Rankings move on relevance, authority, content quality, and hundreds of other factors.

The mechanism: images are often the largest share of a page's weight. On mobile, which Google primarily uses to crawl and rank, a heavy page means a slow LCP and a poor page experience. Slow pages also bleed visitors: as load time grows from one second to three, the chance of a bounce climbs steeply.

The plumber's site is my cleanest example. Rankings barely moved. But his call button started getting tapped because people could actually see it before giving up. Compression is a conversion tool that happens to send Google a favorable speed signal.

What is the biggest image mistake that makes compression pointless?

Uploading full-resolution originals straight from a camera or phone. An 8MB, 6000-pixel-wide photo displayed at 800 pixels wide is mostly waste before compression even starts. Resize the image to its display size first, then compress. Skipping this step is the number one mistake I find in client media libraries.

I want to be blunt, because this costs people real money. Every compressor roundup will take your 8MB original, squeeze it to 2MB, and call it a win. That is a 75 percent reduction of a file that should have been well over 90 percent smaller before you touched a slider.

A DSLR photo at 6000 by 4000 pixels holds 24 million pixels. Your blog displays it at 800 pixels wide, roughly 530,000 pixels. You are shipping 24 million pixels to show about half a million. No tool fixes that as well as thirty seconds of resizing.

My workflow: resize to display size plus retina headroom (1600 pixels wide for an 800-pixel slot), compress at 80 percent, then consider WebP. On the plumber's site, resizing alone took his 3.8MB average down to 900KB. Compression took it to 180KB.

Why do tool pages rarely lead with "resize first"? Because a tool page wants you to use the tool. I built my own compressor and still tell you this first, because any compressor works far better on sane input.

Lossy vs lossless compression: which one should you pick?

Pick lossy for photos on websites. At 75 to 85 percent quality, file sizes drop 60 to 90 percent with no visible difference. Pick lossless only for logos, icons, and archival masters where every pixel must survive exactly, and accept that the savings will be a modest 5 to 30 percent.

Lossless is a perfectionist. It stores data patterns more cleverly, but every pixel survives unchanged. PNG and WebP both have lossless modes. The price: on a detailed photo, lossless might save 10 percent. That is rarely worth it for web delivery.

Lossy is a pragmatist. It permanently discards data your eyes are unlikely to miss. JPEG is lossy by nature. WebP and AVIF can be either. For website photos, lossy at 80 percent is the entire game. I have compared originals with 80-percent JPEGs on a calibrated monitor more times than I can count. On photographs, I cannot tell them apart.

When does lossless win? Logos and icons with flat colors, where lossy artifacts show up as halos. Screenshots with text, for the same reason. Master copies you plan to edit later. Never lossy-compress your only copy. Compress the copy that ships.

My own compressor has no strict lossless mode, and the tool page says so openly. It is lossy with a quality slider, and at 95 percent the output is near-lossless to human eyes. If you need mathematically lossless output, use a dedicated lossless optimizer.

What quality setting should you use? Is 80 percent really the sweet spot?

For photographs on the web, 75 to 85 percent quality is the sweet spot, and 80 percent is the safest default. Below 70 percent, artifacts become visible on close inspection. Above 90 percent, file sizes balloon for quality gains nobody can see.

I did not pick 80 percent from a blog post. I picked it from hundreds of compressed photos across client sites since 2021. At 80 percent, JPEGs and WebPs look identical to the original in normal viewing. At 70, blockiness creeps into skies if you zoom in. At 60, your hero image looks like a 2012 Facebook upload.

The nuance most guides skip: the right setting depends on the content. Busy, detailed photos compress beautifully and can go down to 70. Smooth gradients (skies, studio backgrounds) show artifacts first and deserve 80 to 85. Images with overlaid text need 90 to 95, or a different format.

My rule: photos at 80 percent WebP, screenshots and graphics at 90-plus, and logos as SVG so the settings become irrelevant.

One confession. Early in my career I compressed a client's gallery at 60 percent because "smaller is better." She called that evening: her product photos looked washed out on her iPhone. I redid all 47 images at 80 that night. Aggressive compression is vandalism with extra steps.

Why do my compressed PNG screenshots look blurry, and how do I fix it?

PNG screenshots go blurry because lossy compression was designed for photos, not sharp text edges. The quantization that is invisible in a busy photo creates visible smearing around text. Fix it by using 90 to 95 percent quality, switching the output to WebP, or keeping screenshots as optimized PNGs.

Text in a screenshot is a hard edge: pure white pixels next to pure black. JPEG-style compression works in 8-by-8 blocks and rounds off transitions. In a photo of a tree, that rounding hides in the leaves. On the letter "e" in a 14-point font, it shows up as a gray halo, and your brain reads it as blur.

The fix, in order. First, raise the quality to 90 or 95 percent for screenshots. Text stays crisp, and you still save plenty. Second, convert to WebP instead of JPEG. It handles sharp edges noticeably better at the same file size. Third, for pixel-perfect UI shots, keep PNG but use a palette-based optimizer (TinyPNG's color-reduction approach was built for this).

I learned this the embarrassing way. In 2024 I compressed tutorial screenshots for a tool page at 75 percent, my photo setting. The text looked as if it had been rubbed with an eraser. I redid every one at 92. Now it is photos at 80, screenshots at 90-plus, and never mixed without checking.

Should you convert JPEG and PNG to WebP or AVIF instead of just compressing?

Yes, and this is the highest-impact image optimization most sites have not done. WebP files run 25 to 35 percent smaller than equivalent-quality JPEGs. AVIF can go up to 50 percent smaller. Converting formats beats pushing the quality slider lower, because you keep the visual quality while the file shrinks.

If this article has one "do this today" action, it is this one. Take your already-compressed JPEG at 80 percent and convert it to WebP at 80 percent. Same visible quality, a quarter to a third smaller. It is the closest thing to a free lunch in web performance, and on image-heavy pages the format switch alone can noticeably improve mobile LCP without any redesign.

Here is the format cheat sheet I give every client. Photos go to WebP first, or AVIF if you are ambitious. AVIF is remarkable on photographs, often half the size of a JPEG, but encoding is slower. In 2026 every modern browser handles both.

Graphics with transparency go to WebP: a 400KB transparent PNG can become 90KB. Simple logos go to SVG: vector, infinitely scalable, and often under 10KB. Animated content goes to animated WebP or AVIF; GIFs are typically several times larger than they need to be. Master copies stay as originals. Never convert your only copy.

How do you compress 50 or more images at once without losing your afternoon?

Use a bulk tool that processes files in parallel in your browser. Drop in the whole batch, set the quality once, and download everything as a single ZIP. Fifty images should take under a minute of actual processing.

When the workflow is "drag in the folder, pick WebP at 80 percent, download the ZIP," optimization becomes a habit. Mine is: resize to display size first, separate photos from screenshots, run photos at 80 percent WebP and screenshots at 90-plus, spot-check three to five images at full zoom, download the ZIP, upload, and keep the originals.

Fifty images take about ten minutes, including spot checks. The plumber's 41 took 90 minutes only because I was also renaming files for SEO and writing alt text. The compression itself was the fastest part.

Which image compressor should you use: TinyPNG, Squoosh, ShortPixel, or a browser-based tool?

For quick batch work with privacy, a browser-based compressor wins in 2026. For WordPress automation, ShortPixel is the best plugin. For single-image precision, Squoosh is unmatched. TinyPNG is still fine, but its free-tier limits and server uploads make it a default out of habit, not merit.

I have used all of these on real client work. Here is the honest breakdown, because many "best image compressor" listicles are secretly affiliate rankings. Free-tier limits change, so check each tool before relying on them.

TinyPNG. Excellent PNG color reduction, a trusted brand, and a solid API and plugin. But the free web tool caps batch sizes, files are uploaded to its servers, and AVIF support has lagged. Fine, but most people use it out of habit.

Squoosh (Google). The best single-image control, with a superb split-screen preview, and it runs fully in the browser. But it handles one file at a time, with no batch mode and no HEIC. Perfect for a hero image, useless for a gallery.

ShortPixel. The best WordPress plugin. SmartCompress analyzes each image, glossy mode keeps screenshot text legible, and it supports WebP and AVIF properly. But the free tier is small, processing is server-side, and the pricing is confusing. For WordPress automation, this is the one.

iLoveIMG. Familiar, and batches JPEG, PNG, and WebP. But it has daily task limits, limited quality control, and server uploads. Convenient but unremarkable.

Compressor.io. Dead simple, with a lossy/lossless toggle. But it handles one file at a time, uploads to a server, and nags about quotas. A tool running on brand memory.

ImageOptim (Mac). A desktop app with multiple engines, unlimited use, and full privacy. Mac only. If you are on a Mac doing this daily, nothing beats it.

Kraken.io. An excellent API for developers. Overkill for casual use. It is for pipelines, not bloggers.

Smush. Beginner-friendly with a generous free tier. But its compression ratios have trailed ShortPixel's in tests, and the upsells are constant. Good for hobby blogs, not client work.

EWWW Image Optimizer. Deep control and no file-size limits. But the settings overwhelm beginners.

Cloudinary / Cloudflare Images. Automatic responsive delivery through a CDN. Paid, and overkill for small sites.

MiniPx. A browser-based newcomer with exact target-size modes that has published its own benchmark with a stated methodology. The free tier limits batch size.

JPEGmini. Photographer-grade quality for a one-time fee. Niche: for photographers, not webmasters.

My daily setup: a browser-based tool for batches (I built one that handles 50 images per batch with no uploads and no signup), ShortPixel on client WordPress sites for automation, and Squoosh when a single hero image needs manual tuning. No single tool wins everything. The people who tell you otherwise are selling that tool.

If you want to try the browser-based approach, my free image compressor runs entirely in your browser with no signup, handles up to 50 images per batch, and can output WebP. But honestly, Squoosh or any tool above will get you there. The habit matters more than the brand.

Is it safe to upload client photos to an online image compressor?

It depends on where the processing happens. Browser-based compressors never receive your files, so they are safe for client work. Server-based tools upload your images, and while reputable ones delete them within a day or two, you are still trusting a third party with someone else's property.

Server-side tools (TinyPNG, iLoveIMG, Compressor.io) upload your image, compress it on their infrastructure, and send it back. TinyPNG says files are deleted within 48 hours. I believe them. But that still means your client's unreleased product photos may sit on someone else's server for up to two days. For a blog header, who cares? For pre-launch shots or anything under NDA, I care.

Browser-side tools (Squoosh, MiniPx, and the image compressor I built) do the work in your browser with JavaScript and WebAssembly. The file never leaves your device. There is nothing to delete because nothing was uploaded. It is also faster, since you skip the upload round trip.

My rule: if the image shows a real person, private property, an unreleased product, or anything under NDA, it gets compressed locally or not at all. "The tool probably deletes it" is not a policy.

Should you compress images before or after uploading to WordPress?

Before. Always before. Compressing after upload means WordPress has already generated multiple thumbnail sizes from your bloated original, wasting storage and leaving oversized files on your server. Optimize locally, then upload the finished file.

Plugin marketing obscures a workflow truth. Smush and ShortPixel will optimize your media library after the fact, and they do a decent job. But before they touch anything, you have uploaded a 5MB original and WordPress has generated half a dozen thumbnails from it. Your server now stores seven versions of a file that should have been 200KB.

I learned this on a client site in 2024. Someone uploaded 200MB of full-resolution images and then installed a plugin expecting a miracle. The site stayed slow, the storage stayed full, and the thumbnails were still generated from bloated originals. We deleted the whole media library and re-uploaded optimized files. That was a full day of work that a ten-minute pre-upload habit would have prevented.

The correct workflow: resize and compress on your computer, give the file a descriptive name (blue-widget-installation-lahore.jpg beats IMG_4829.jpg), then upload. Let the plugin catch whatever slips through. Plugins are a safety net, not a strategy. The exception is inheriting 3,000 unoptimized images, where bulk-optimizing in place with ShortPixel or EWWW is the pragmatic move.

What about Google Business Profile photos, WhatsApp sharing, and forms with strict KB limits?

Different destinations need different compression. Google Business Profile photos should be under 500KB for fast uploads that still look sharp. WhatsApp compresses everything anyway, so send reasonably sized files. Government and job forms with 100KB or 200KB limits need target-size compression, where you set the exact size in KB and the tool adjusts the quality to hit it.

Google Business Profile photos are my favorite overlooked case. GBP is a conversion surface for every local business. Uploading a 6MB original over a phone connection is painful, and Google recompresses everything anyway. My practice is to compress project photos to under 500KB at 80 percent before uploading them to GBP. For a local SEO managing ten client profiles, this is a weekly workflow.

WhatsApp is the opposite problem. People compress images before sending them, not realizing WhatsApp applies its own aggressive compression anyway. A 300KB image arrives looking the same as a 5MB original would have.

Forms with KB limits (job applications and government portals, often with 100KB or 200KB caps) need a target-size mode instead of a quality mode. Tell the tool "make this under 100KB," and it adjusts the quality automatically. XConvert, MiniPx, and CompressJPG offer this. The same goes for email: ten 4MB photos may bounce off corporate mail servers, while ten 300KB versions sail through.

Why did my PageSpeed score go up but my rankings didn't move?

Because page experience is one ranking signal among hundreds. Compression reliably improves LCP, PageSpeed scores, and bounce rates, which is real business value. But rankings also need relevance, authority, and content quality, and no amount of compression substitutes for those.

I am ending the guide here because this is the honesty section, and I would rather you hear it from me than discover it after doing everything right.

When the plumber's site went from a mobile score of 21 to 74, I did not promise rankings. Six weeks later he had moved up a couple of positions on one keyword. Was it the compression? The content was decent, and the competition was thin. Maybe speed helped at the margin. Maybe something else did. I told him I could not isolate the cause.

Compression buys you three things, in order: a better user experience (people stay), better conversion (people act), and a favorable page experience signal (Google notices). The first two are nearly guaranteed. The third is real but small. Rankings are a lagging indicator of a hundred inputs, and page speed is one of them.

Anyone who says compression alone moved a site from page three to page one is either mistaken about causation or selling a course. I have never seen it happen in isolation. What I have seen, repeatedly, is faster sites converting better. For a local business, a 10 percent conversion lift from speed beats a two-position ranking gain. Optimize for the money, not the metric.

The bottom line

Here is the takeaway. Resize before you compress. Use 80 percent for photos and 90-plus for screenshots. Convert to WebP instead of squeezing the slider harder. Batch your work so it becomes a habit. Keep your originals. Measure conversions and LCP first, and rankings whenever they show up.

The plumber from Lahore did not need faster hosting or a redesign. He needed someone to stop uploading DSLR originals to pages displaying them at 800 pixels. Ninety minutes later his site loaded in a blink and his phone rang more. That is what an image compressor actually does. Not magic, just physics, applied before your visitors give up.

When did you last check the actual file sizes in your media library, and what is the biggest single image sitting on your site right now?

Frequently asked questions