How to Reduce Image File Size (Without Losing Quality)

You uploaded a photo, hit save, and your CMS threw back a warning: "This image is too large." Or you ran your homepage through PageSpeed Insights and got flagged for slow-loading images. Either way, you landed here because you need to know how to reduce image file size, and you need the actual steps, not a lecture on compression algorithms.

Here's the good news. The fix is a short, repeatable sequence, not a mystery you need a design degree to solve. Once you know the order to do things in and roughly how small each type of image should end up, you can shrink image file size on almost any photo in a couple of minutes, using tools that cost nothing.

Why Your Images Are So Big in the First Place

Most beginners assume a large file means "not compressed enough." Usually that's not the real problem. The real problem is pixel count: a photo straight off a modern phone is often 3,000 to 4,000 pixels wide, while the space it's actually displayed in on your site might be 800 or 1,200 pixels wide. Google's Lighthouse tool has an entire audit built around exactly this, called "properly size images", which flags any image being delivered at a resolution far larger than what's rendered on screen, because those extra pixels are pure wasted bytes.

Think of it like shipping. If someone in your town orders a paperback book and you send it in a moving truck, the truck doesn't make the book heavier, but it does make the delivery absurdly expensive and slow.

A 4,000-pixel photo displayed in an 800-pixel box is the same kind of mismatch. Compressing that oversized file helps a little. Resizing it first helps a lot more, because you're removing pixels the browser was never going to show anyone anyway.

How to reduce image file size in 4 steps

This is the order that actually works, and it matters more than which specific tool you use. Skip a step or do them out of sequence, and you'll end up compressing an image that was oversized to begin with, which is like tightening the belt on pants three sizes too big. It helps a bit. It's not the fix.

1. Decide where the image will actually be displayed. Open the page (or a similar page) where the image will live, right-click the space it fills, and check the rendered width, or ask your theme's documentation what the content column width is. You should end up with a rough target in pixels, something like "this is a blog post image, so it needs to be about 800px wide" or "this is a hero banner, so it needs to be around 1,600px wide." If you have no idea what the display width is, use the role-based table further down as a stand-in until you can check properly.

2. Resize the pixel dimensions to that target first. Open the image in an editor (Preview on a Mac, the Photos app on Windows, or a browser tool like Squoosh) and resize the width to the number from step one, keeping the aspect ratio locked so the image doesn't stretch or squash. When it worked, the file's properties panel shows dimensions close to your target, and the file size has usually already dropped by half or more, before you've compressed anything.

   Three things trip people up here. Cropping is not resizing, cropping cuts part of the photo away while resizing shrinks the whole thing, so make sure you're using the right tool. Unlocking the aspect ratio (typing a new width and height separately) warps the image into an oval-eyed version of itself. And doing this step after compressing instead of before wastes the compression, since you'll just compress it again anyway.

3. Compress the resized image. Run the newly resized file through a compressor at a moderate quality setting. Lighthouse itself sets its own benchmark at 85 percent when it checks whether an image is efficiently encoded, so a range of 75 to 85 percent is a reasonable place to start. If it worked, the file size drops again, often by another 30 to 60 percent, and the image still looks sharp at normal viewing distance on the actual page.

   If the file barely shrinks at this step, it usually means one of two things: the image was already fairly small going in, or you're compressing a format (like a screenshot saved as PNG) that responds better to a different quality setting or file type entirely, which is worth testing directly rather than assuming one fixed number works for every format.

4. Verify the result before you trust it. Check the actual delivered file size and format on the live page, not the number your editor's export dialog claims, because some CMS platforms and hosts silently re-encode images on upload. Running the published URL through a tool like imagecheck.tools shows you the real bytes, real format, and real pixel dimensions each image is serving, which is the only way to know for certain the first three steps actually stuck. If the check still flags an image as large, look for a leftover original hiding in your media library, a caching layer serving an old version, or a resize that got skipped somewhere in the upload process.

How small should your images actually be?

"Small enough" depends heavily on what the image is doing on the page. A tiny icon and a full-width hero banner have nothing in common except that they're both technically images, so treating them the same way is where a lot of guides go wrong. These are reasonable starting points, not hard rules, and they're worth adjusting once you know your own theme's actual display sizes.

• Hero or banner images (full-width, top of page): aim for roughly 150 to 300 KB. These are visually important, so they can carry a slightly bigger budget than smaller images, but going past 300 KB starts to noticeably affect load time on a typical page.
• In-content or blog images (photos inside an article, product shots): aim for roughly 50 to 150 KB. Most pages carry several of these, so keeping each one modest keeps the total page weight in check.
• Thumbnails (list previews, related-post cards): aim for roughly 10 to 40 KB. They're small on screen, so they don't need much data to look sharp.
• Icons (small UI graphics, logos): aim for under 10 KB, and consider whether an icon needs to be a photo-style file at all, since simple graphics often compress far better as SVG.

As a rough plain-language yardstick, once a single image on a page climbs past 300 KB it's worth a second look, and anywhere near or above 1 MB is almost always worth fixing, regardless of what type of image it is. The HTTP Archive's Web Almanac tracks this every year, and the trend keeps pointing the same direction: even the single largest image on a typical page still runs a median of roughly 150 KB on desktop and 135 KB on mobile, and that's before counting every other image stacked on top of it. So this isn't a theoretical problem. It's the actual reason most sites feel slow.

Free tools that actually do this

You don't need paid software to reduce image file size, and you don't need to install anything either, unless you want to. Here's an honest, three-option shortlist, with the real trade-offs included instead of a "best tool" ranking that pretends there's no trade-off at all.

• Squoosh, built by Google's Chrome team, runs entirely in your browser. Nothing you upload leaves your computer, which matters if you're working with client photos or anything you'd rather not send to a third-party server. The trade-off is that it's manual, one image at a time, so it's not built for batch jobs.
• TinyPNG is a drag-and-drop web compressor that handles PNG and JPEG files with almost no learning curve. It's fast and forgiving for beginners, but your files do get uploaded to their servers to be processed, so it's worth knowing that before you drop in anything sensitive.
• ShortPixel and similar plugins work automatically inside WordPress or Shopify, compressing images the moment you upload them. That hands-off convenience is genuinely useful once your site has hundreds of images, but it also means you're trusting an automated process rather than checking each image yourself, so it's worth spot-checking results occasionally rather than assuming it's always working perfectly.

All three are worth knowing because each solves a different problem: Squoosh for privacy and one-off control, a drag-and-drop compressor for speed, and an automatic plugin for scale. Free tiers and upload limits on any of these change over time, so it's worth checking each tool's own site for current numbers before you rely on a specific limit.

How to tell if you've compressed too far

Compression isn't free. Push it too hard and you start trading file size for visible quality loss, and the earlier you catch it, the less time you waste redoing the work.

Three signs are worth watching for. Banding shows up as visible stripes in what should be a smooth gradient, like a sunset sky suddenly looking like a barcode. Blur appears when fine detail (text inside a screenshot, hair, fabric texture) turns to mush instead of staying crisp. Blocky artifacts, small square patches that don't match the surrounding image, show up most often around sharp edges in JPEG files pushed to very low quality settings.

If you spot any of these, the fix is simple: go back to your compressor and raise the quality setting by 5 to 10 percent, then re-check the result. There's no shame in needing two or three passes to find the sweet spot for a particular image. Even professionals eyeball this rather than trusting one fixed number to work for every photo.

Check your work after you publish

The export dialog in your editor is not the final word on what actually gets delivered to a visitor's browser. Hosts recompress. CMS platforms generate their own resized versions and sometimes serve the wrong one. Caching layers hold onto an old file after you've replaced it.

The only way to know for sure is to check the live, published version of the page, which is exactly what this site's free image checker is built for: paste in a URL and it reports the real delivered file size, format, and pixel dimensions for every image the page serves, flagging anything still running large.

If you're tackling image weight because of a PageSpeed or Lighthouse flag, it's worth knowing this workflow addresses only one part of overall image health. Descriptive alt text is a separate but related job worth doing at the same time, and our guide to writing alt text covers what to write for different kinds of images. And if a hero image also doubles as your social share preview, the pixel dimensions that work well for an og:image aren't always the same as what works inside your article, a distinction socialpreview.tools is built to check directly. For a full picture of what a technical check like this one grades and where its limits are, our about page lays it out plainly, and the wider family of free tools this one belongs to is listed at imagecheck.tools/tools.

None of this requires learning codec theory or memorizing format trade-offs. Resize to the size the image actually needs to be, compress what's left, and check the real result before you call it done. That sequence alone fixes the vast majority of "image too large" warnings a beginner runs into. For larger sites where doing this by hand doesn't scale, Google's own web.dev guidance on image CDNs covers the automated version of the same idea: resizing and compressing on the fly instead of shipping one oversized master file to every visitor.

Frequently Asked Questions

What image file size is acceptable for a website?

There's no single number that fits every image, since a full-width hero banner and a small thumbnail carry very different weight budgets. As a general guide, hero or banner images work well between 150 and 300 KB, in-content images between 50 and 150 KB, thumbnails under 40 KB, and icons under 10 KB. Once any single image climbs past roughly 300 KB it's worth a second look, and images near or above 1 MB are almost always worth resizing and compressing, since that weight is rarely necessary for how the image is actually displayed.

Does reducing file size lower image quality?

It can, but it doesn't have to, and the resize-first workflow is exactly why. Removing pixels the browser was never going to display anyway costs you nothing visible, since no one was seeing those extra pixels to begin with. Moderate compression (Lighthouse's own audit benchmarks around 85 percent quality) is also usually invisible at normal viewing distance. Quality loss becomes noticeable only when you push compression too aggressively on an image that's already the right size, which shows up as banding, blur, or blocky patches, all signs it's time to back the quality setting up a notch.

What is the best free tool to reduce image file size?

There isn't one single best tool, because the right choice depends on what you're doing. Squoosh works entirely in your browser and keeps your files private, which suits one-off images and anything sensitive. TinyPNG is a fast drag-and-drop option for quick jobs, with the trade-off that your files are uploaded to their servers. A plugin like ShortPixel compresses images automatically on upload inside WordPress or Shopify, which is the most convenient option once a site has hundreds of images to manage.

Should I resize or compress first?

Resize first, then compress. Resizing the pixel dimensions down to the size the image will actually be displayed at removes the largest chunk of unnecessary data in a single step, since a browser was never going to render those extra pixels anyway. Compressing after that point works on a file that's already close to its real target size, so the quality setting you choose has to do far less heavy lifting. Compressing an oversized image first, then resizing it, wastes that first compression pass entirely.