Compress images to load faster on your website. Targets 100KB by default, ideal for improving Core Web Vitals and Largest Contentful Paint.
Last updated: August 2026
100KB
Default Target
JPEG + WebP
Output Formats
LCP Focused
Performance
Private
No Uploads
Common website image targets:
Drop image here to compress to 100KB
JPEG, PNG, WebP, AVIF, HEIC. All processing stays in your browser.
Default target is 100KB. For full-bleed hero images, 150KB to 200KB is also acceptable if needed for visual quality. The format toggle defaults to JPEG, switch it to WebP for the smaller next-gen file size.
Find your LCP image
Usually a hero or featured image, prioritize that one first.
Resize if oversized
Much larger than its display size? Resize before compressing.
Set your target
100KB by default, up to 150 to 200KB for full-bleed heroes.
Switch to WebP
Defaults to JPEG, select WebP for the smaller next-gen file.
Drop and download
JPEG, PNG, WebP, AVIF or HEIC accepted as input.
On the majority of pages, an image is the element Google measures for Largest Contentful Paint. Compressing the right images has an outsized effect on overall page speed.
Blog post and article images
Featured images and in-content photos are often the largest files on a blog post. Compressing to under 100KB each can significantly reduce total page weight.
Hero and banner images
The hero image is frequently the Largest Contentful Paint element. Compressing it directly improves the metric Google measures for page experience.
Product and gallery photos
E-commerce pages with multiple product images benefit the most from compression, since the combined weight of many photos compounds quickly.
Background and decorative images
CSS background images are easy to forget during optimization but load just like any other image and can quietly add hundreds of kilobytes to a page.
For the biggest impact, resize images to their actual display dimensions first. The Resize Image tool lets you set exact pixel dimensions before compressing.
The biggest speed gains come from the first cuts, not the last ones. Shrinking a 500KB hero image down to 150KB removes most of the load time it was adding, while squeezing that same file from 100KB down to 50KB saves far less in absolute terms and starts costing more in visible quality. If you're working through a page full of images, spend your effort on the largest files first rather than chasing the smallest possible number on every single one.
Google's Core Web Vitals data comes from real visitors on real networks, and a large share of that traffic is on mobile connections slower and less consistent than a home wifi test would suggest. A 100KB image that loads instantly on a fast connection can still take a full second or more to arrive on a throttled mobile network, which is exactly the kind of visitor Google's field data reflects most heavily in LCP scoring.
Compressing a single large hero image once and serving it to every visitor still forces a phone screen to download pixels it will never display. Pairing compression with a few resized versions at common breakpoints, rather than one image for desktop and mobile alike, cuts far more weight for mobile visitors than compression settings alone ever can. The resize for website tool covers the most common breakpoint sizes.
Compression only helps if the browser starts fetching the image early. A hero image marked for lazy loading, or one loaded through a CSS background rather than a plain img tag, can delay the fetch enough to erase most of the benefit of shrinking the file in the first place. If an image is the one determining your LCP, make sure it loads eagerly rather than lazily, since timing matters just as much as size.
Expecting AVIF as an output option
This tool outputs JPEG or WebP only, never AVIF. For AVIF specifically, use the dedicated JPG to AVIF converter on this site as a separate step.
Leaving the format on JPEG when WebP was the goal
The format toggle defaults to JPEG, not WebP. If the whole point was the smaller next-gen file size, check the toggle is actually set to WebP before downloading.
Compressing without resizing an oversized source first
A hero image that displays at 800px wide but was uploaded at 4000px still forces the browser to decode all that extra pixel data, even after compression brings the file size down. Resize to the actual display dimensions first for a meaningfully faster LCP.
Loading the compressed image lazily or as a CSS background
A smaller file only helps LCP if the browser starts fetching it early. Lazy loading or a CSS background image can delay that fetch enough to erase most of the benefit of compression, keep the LCP image as a plain, eagerly loaded img tag.
Treating every image on the page as equally important
The single largest visible image, usually the LCP candidate, deserves the most attention. Below-the-fold images matter less for the specific LCP metric, though they're still worth compressing for overall page weight.
Assuming the encoder caps quality below 100
It doesn't. The search checks quality 100 first and only steps down if that overshoots your target. At tight website-speed targets like 100KB you're much more likely to see quality land well below 100 simply because the target itself is tight, not because of any artificial ceiling.
Images account for nearly half of the total weight of a typical web page, and on the majority of pages the largest image is the element that determines Largest Contentful Paint, the Core Web Vital that measures how quickly the main content becomes visible. A hero image reduced from 420KB to 100KB or smaller loads faster on every connection type, directly improving LCP regardless of any other optimization on the page.
Under 100KB is a widely cited target for content images such as blog post images, hero banners and product photos, since this size combined with a modern format like WebP reliably keeps LCP under the 2.5 second good threshold. Background images and full-bleed hero photos can sometimes go up to 150KB to 200KB if the visual quality requires it, but smaller is always better for speed.
WebP is the better default for website images in 2026. It produces equal or better visual quality at smaller file sizes than JPEG, supports transparency, and is supported by over 97 percent of browsers globally. This tool can output WebP directly, select it in the format toggle since JPEG is the default, and it gives you a smaller file than an equivalent JPEG at the same target size.
Yes. Page speed is a confirmed Google ranking factor, and Core Web Vitals including LCP are part of how Google evaluates page experience. Sites that reduce their average image weight often see measurable improvements in both Core Web Vitals scores and mobile search visibility within a few months, since faster pages also reduce bounce rate, which is itself a signal of a good user experience.
Yes, when possible. Compression reduces file size at the same dimensions, but if your image is much larger than its display size, for example a 2400 pixel wide photo shown in an 800 pixel wide column, resizing first removes far more excess data than compression alone. For the best result, resize to your display dimensions first, then compress.
No. This tool outputs JPEG or WebP only. AVIF is not an output option here, if you specifically need AVIF for the smallest possible file size, the JPG to AVIF converter on this site handles that conversion as a separate step.
There's no ceiling below 100. The tool checks quality 100 first, before searching at all. At a tight target like 100KB, quality 100 usually overshoots, so the search narrows down from there, the resulting quality just depends on how much a given image can be compressed to fit, not on an artificial cap.
This tool handles one image at a time. For a full page or article with many images, run each one through individually, starting with the largest visible image since that usually has the biggest effect on LCP.
The tool checks the file size before compressing. If the image is already smaller than your target, it shows a confirmation and offers the original file for download instead of compressing it again for no benefit.
Yes, EXIF metadata including GPS location and camera details doesn't survive the compression, the image is decoded to raw pixels and re-encoded. This has a small, direct effect on file size, and a useful privacy side effect for any photo being published publicly.
Only rarely at loose targets like 100KB or 200KB. If quality reduction alone can't reach a very tight target, the tool falls back to slightly scaling down the pixel dimensions too. At website-speed targets in this range that fallback is uncommon, it shows up far more often at very tight targets like 10KB or 20KB.
Yes. It includes a dedicated decoder for HEIC and HEIF files, so an iPhone photo can be dropped in directly without a separate conversion step. The compressed output is still JPEG or WebP, not HEIC.
No. Compression addresses the file size and download time of your LCP image, but LCP also depends on when the browser starts fetching it. An image that's lazy-loaded, or loaded through a CSS background instead of a plain img tag, can delay the fetch enough to erase most of the benefit of a smaller file. A well-compressed image that also loads eagerly and isn't render-blocked gives the best result.
No sign-up. No upload to server. Drop your image above and download it in seconds.
