How to compress images for website use comes down to three moves in order: resize each photo to the width it actually displays at, convert it to WebP or AVIF, then run it through a compressor that strips metadata. Skipping the resize step is the single biggest mistake, since a desktop-sized photo served to a phone can waste two to four times the data the screen needs.
My guide to compressing images for every destination covers email, documents, and the web together at survey depth. This page is the website-specific deep dive: the exact levers that move Largest Contentful Paint, the target size for each kind of image on a page, and the arithmetic behind what resizing and converting together actually save.
Why Does Image Size Slow Down Your Website?
Large, unresized photos are usually the single biggest thing holding a page back, because Largest Contentful Paint, the moment the biggest visible element finishes rendering, is graded against whatever the page is waiting on, and on most pages that is a photo. Google's own developer documentation puts a real number on the waste: serving a desktop-sized image to a phone can use two to four times the data the screen actually needs, and every one of those extra bytes has to finish downloading before the browser can call the image, and often the page, done loading (web.dev).
Fix the images and the metric that most affects how fast your site feels moves with them. That is also why the fix has two separate parts working together: resize to the width the photo actually displays at, then compress what is left. Doing only one of them, which is what most sites do, leaves real savings sitting on the table. None of this is about one photo in isolation either: a typical page carries a hero image plus several supporting photos, so the two-to-four-times waste above compounds across every one of them, and a page that gets this right on five images feels like a different site than one that gets it right on just the hero.
How to Compress Images for Website
How to compress images for website use is a three-step order, not three separate options to pick from: resize the photo to the width it will actually display at, choose WebP or AVIF over JPEG or PNG where you can, then run the resized file through a compressor that strips metadata on the way out. Do them out of order and you lose savings; a photo that is compressed but never resized is still carrying pixels nobody's screen will show.
Step 1: Resize to the Width It Actually Displays At
Find the pixel width your photo actually renders at on the page, not the width your camera or CMS uploaded it at, and resize to that first. This is the biggest single lever in this guide and the one almost nobody pulls, because compressing feels like the whole job and resizing feels like a separate, optional task. It is not optional: a 4000-pixel-wide photo displayed at 800 pixels is carrying five times the pixel data the layout will ever show, and no amount of quality-slider work gets those pixels back. The "Generate 3 to 5 Sizes" section below covers the tools that do this resizing for you.
Step 2: Pick a Format (WebP by Default, AVIF Where You Can)
Use WebP as your safe default and AVIF where your audience's browsers support it and encoding time is not a constraint; both beat a same-quality JPEG by a wide margin. AVIF often saves more than 50 percent versus JPEG at matching visual quality, the largest gap of any format pair in common use, though it takes noticeably longer to encode than WebP does (web.dev). Keep a JPEG or PNG fallback in your markup regardless; a handful of older browsers and in-app browsers still only read those two.
Step 3: Compress and Strip Metadata
Drop the resized photo into the compressor and it strips EXIF metadata, the hidden GPS coordinates, camera model, and timestamp every phone photo carries, automatically while it re-encodes at quality 80, no separate step required. Quality 80 is visually lossless for a photograph at normal viewing size, and the whole process runs in your browser, so nothing uploads to a server you do not control.
Is PNG or JPEG Better for Websites?
PNG only wins when the image needs a transparent background or is a screenshot or logo built from flat color and hard edges; for everything photographic, JPEG, WebP, or AVIF is both smaller and just as good-looking. Lossy WebP already runs 25 to 35 percent smaller than a same-quality JPEG, and lossless WebP is roughly 26 percent smaller than the equivalent PNG, with a <picture> element used to fall back to JPEG or PNG for the rare browser that reads neither newer format (MDN).
| Format | Best for on a website | Size vs. same-quality JPEG |
|---|---|---|
| JPEG | Photos, the safe fallback | Baseline |
| PNG | Logos, screenshots, transparency | Larger, lossless |
| WebP | The modern default | 25 to 35% smaller |
| AVIF | Hero photos, modern browsers | Often 50%+ smaller |
A photograph saved as PNG anyway routinely runs five to ten times larger than the same photo as a JPEG nobody could tell apart, because PNG's lossless compression cannot throw away the gradients and sensor noise a lossy format is built to discard.
What Is the Best Image Size for a Website?
There is no single best file size, only the right target for what the image is doing on the page: a hero photo above the fold has a tighter budget than a thumbnail three screens down, because only one of them can hold up your Largest Contentful Paint. Sort by role first, then chase the number.
| Image role | Target file size | Why |
|---|---|---|
| Hero / above the fold | Under 200 KB | It is usually the LCP element visitors wait on |
| In-body photos | Under 100 KB | Full detail at article width without dragging down total page weight |
| Thumbnails and cards | Under 30 KB | Displayed small enough that extra quality is invisible |
| Icons and logos | SVG, or under 10 KB as PNG | Vector where possible; these are rarely photographic |
A page built around these four numbers, rather than one blanket "compress everything" pass, is how you optimize images for website performance without guessing which photo actually matters.
How Do You Serve Responsive Images at the Right Size?
Generate several sizes of the same photo and let the browser choose the right one for each visitor's screen with srcset and sizes, rather than shipping one file to every device.
Generate 3 to 5 Sizes
It is common to serve three to five different sizes of an image across your real breakpoints, and there is no single correct number, only enough steps that no visitor downloads dramatically more pixels than their screen shows (web.dev). Three tools do this generation for you.
| Tool | Best for | Example |
|---|---|---|
| sharp (npm) | Build pipelines, automated resizing | Runs the same open-source engine this compressor uses |
| ImageMagick | One-off batches from the command line | convert -resize 33% photo.jpg photo-small.jpg |
| Cloudinary or Thumbor | On-demand resizing by URL | No build step, resizes when the URL is requested |
If your build pipeline already resizes with one of these, compressing there too is one step away rather than a new tool to learn. If you would rather not wire it in at all, the compressor on this site does the same quality and format changes in a browser.
Write the srcset and sizes Markup
<img src="photo-large.jpg"
srcset="photo-small.jpg 480w, photo-large.jpg 1080w"
sizes="50vw"
alt="description">
srcset lists each candidate file with its actual pixel width, the 480w and 1080w descriptors here. sizes tells the browser how wide the image will display at the current viewport, half the viewport width in this example, so it can match a candidate to the space available before it downloads anything. src stays as the fallback for the rare browser that ignores both attributes. These responsive image sizes work together, not as alternatives to each other, and CSS still controls the real displayed width regardless of what sizes hints at.
Should You Lazy-Load Every Image?
No. Add loading="lazy" to every image below the initial viewport, and leave your hero image, almost always your LCP element, on its default eager loading. Native lazy loading is well supported across all major browsers and needs no extra library to use (web.dev). A browser cannot lazy-load an image until it knows where that image sits on the page, and finding that out takes work the browser cannot finish until layout is further along, which is exactly why lazy-loading the hero photo makes it arrive slower, not faster.
Add explicit width and height to every <img> tag too, lazy-loaded or not, so the browser can reserve the right amount of space before the file arrives. Skip that and the page jumps once each image finally loads in, which is Cumulative Layout Shift, graded separately from load speed but felt just as directly by a visitor scrolling at the wrong moment. Lazy-loading and sizing get an image's own weight right; a CDN and a long cache lifetime on top of that stop the browser from re-downloading the same photo on every visit, which is a separate, complementary fix, not a replacement for compressing and resizing in the first place.
Does Compressing Images Hurt Website SEO or Quality?
No, the opposite is true: page speed is part of how Google evaluates a page, and a handful of oversized, uncompressed photos are one of the most common reasons a page fails its Core Web Vitals checks. Quality 80 is visually lossless for a photograph at normal viewing size, so you get the speed benefit of a smaller file without a visitor ever noticing the picture changed. The only quality risk worth worrying about is compressing the same file more than once; every lossy re-save throws away a little more detail on top of what the last save already discarded, so always compress from the original photo, never from a copy that has already been through a lossy save. Keep your original file somewhere untouched for exactly that reason: compression is not reversible, and a photo you might need at full resolution later, for print or a redesign, should never be the same file you re-export for the web over and over.
How Do You Verify It Worked?
Run Lighthouse, either in Chrome DevTools or at PageSpeed Insights, and read the "Properly size images" and "Defer offscreen images" audits directly; both name the exact file that is oversized or loading too early, not a vague score. Compressing a photo without resizing it can still fail "Properly size images," because that audit checks the pixel dimensions being served against the space the image occupies on the page, and a smaller file at the wrong resolution still ships more pixels than the layout needs.
One Photo, Two Levers, Real Numbers
Here is the arithmetic, not a guess. Our own homepage demo file is a 497 KB JPEG that comes back as a 214 KB WebP at quality 80, a 56.9 percent reduction, with compression as the only thing that changed. Now add the resize step using the low end of web.dev's own two-to-four-times mobile-waste figure: a version of that same photo resized to the width it would actually display at drops to roughly 200 KB before a single quality setting is touched. Run that resized file through the same WebP conversion, the same 56.9 percent reduction rate the homepage demo measured, and it lands around 86 KB, an unresized-to-finished drop of nearly 79 percent from one photo doing both things instead of one.
| Step | File size | What changed |
|---|---|---|
| Original, full desktop width | 497 KB | Our own demo JPEG, unresized |
| Resized to actual display width | About 200 KB | The low end of web.dev's 2x to 4x mobile-waste figure |
| Resized and converted to WebP quality 80 | About 86 KB | The same 56.9% reduction the homepage demo measures, applied to the resized file |
That is not a lab result; it is the same demonstrated WebP rate applied twice, once by itself and once after a resize, so you can check the multiplication yourself against the two cited figures.