How to Reduce Image Size Under 100KB Without Losing Quality
Your homepage hero image is 2.4 MB. On a decent 4G connection that takes about 8 seconds to load. Half your visitors leave before they see anything. Google's Core Web Vitals flag your Largest Contentful Paint as "Poor," and your search ranking quietly slides.
The fix isn't buying a faster server. It's shrinking the image. Most web photos can land under 100 KB and look identical to the original on screen. Here's the exact process, with real numbers.
Why 100KB Is the Target
100 KB isn't magic, but it's a good line in the sand:
- A 100 KB image loads in roughly 0.3 seconds on 4G (vs 8 seconds for 2.4 MB).
- Google's LCP threshold for "Good" is 2.5 seconds. Images are usually the LCP element. A sub-100KB hero gives you headroom for everything else on the page.
- On mobile data plans, every megabyte costs your user real money in some markets.
You don't need every image under 100 KB — thumbnails and icons should be far smaller, and a full-screen photographic background might legitimately be 150–200 KB. But if your content images are routinely over 100 KB, you're leaving performance on the table.
Step 1: Resize to the Actual Display Size
This is where most of the savings come from, and most people skip it.
That 2.4 MB photo? It's probably 6000×4000 pixels straight from a camera or stock site. Your page displays it at 800 pixels wide. You're shipping 56 times more pixels than the screen shows.
The rule: resize the image to the largest size it will actually display, then add a small margin.
| Display context | Target width |
|---|---|
| Blog content image | 800–1200 px |
| Hero/banner | 1600–1920 px |
| Thumbnail | 300–400 px |
| Full-screen background | 1920 px (rarely more) |
For retina/HiDPI screens, serve at 2× the CSS display width — a 400px-wide slot gets an 800px image. Going to 3× or beyond has diminishing returns; the human eye can't resolve the difference at normal viewing distances, and you're tripling the file size for nothing.
Concrete example: A 6000×4000 JPEG at 2.4 MB, resized to 1200×800, drops to roughly 400–500 KB before any other optimization. One step, ~80% reduction.
Step 2: Pick the Right Format
Format choice matters more than most people think. Here's the honest breakdown:
Photographs (complex, many colors):
- WebP — your default choice in 2026. Typically 25–35% smaller than JPEG at the same visual quality. Supported by every modern browser (Chrome, Firefox, Safari 14+, Edge).
- AVIF — 20–30% smaller than WebP, but encodes much slower and Safari support has quirks. Worth it for hero images you optimize once; overkill for bulk processing.
- JPEG — the fallback. Use it when you need maximum compatibility (email clients, old systems).
Graphics, logos, screenshots with text:
- PNG — only when you need transparency or pixel-perfect sharp edges. A photographic PNG can be 5–10× larger than the equivalent JPEG.
- SVG — for logos and icons. It's code, not pixels. Always smaller, infinitely scalable.
The single biggest format mistake: saving a photograph as PNG. I see this constantly. A 2 MB PNG photo becomes a 180 KB JPEG with no visible difference. If your image has no transparency and isn't a logo, it probably shouldn't be PNG.
Step 3: Dial In the Quality Setting
Once resized and in the right format, the quality slider does the rest. Here's what actually happens at different settings:
| Quality | JPEG/WebP file size (1200px photo) | Visible difference |
|---|---|---|
| 100 | ~450 KB | None (don't do this) |
| 90 | ~220 KB | None on screen |
| 80 | ~130 KB | None on screen |
| 70 | ~95 KB | Barely perceptible on close inspection |
| 60 | ~70 KB | Slight artifacts in smooth gradients |
| 50 | ~55 KB | Noticeable blockiness |
The sweet spot for web is 75–82. At quality 80, a 1200px photo lands around 100–130 KB and looks identical to the original on any screen. Below 70, you start seeing artifacts in skies and gradients.
Don't trust the slider blindly — zoom to 100% and check smooth gradient areas (skies, skin, shadows). That's where compression artifacts show first. Text and sharp edges are more forgiving.
Step 4: Strip the Metadata
Photos carry EXIF data: camera model, GPS coordinates, timestamps, thumbnails. This adds 10–50 KB and — more importantly — can leak your location.
Most compression tools strip EXIF by default. If yours doesn't, make sure to enable it. The exception: photographers who need copyright metadata embedded should keep it, but that's not your blog hero image.
Stripping metadata on our example image saves another ~15 KB and removes a privacy risk. Free win.
Step 5: Serve Responsive Sizes (Don't Ship Desktop Images to Phones)
Even a well-optimized 1200px image is wasteful on a phone that displays it at 400px. Responsive images solve this with the srcset attribute — the browser picks the smallest file that fits the screen.
<img src="photo-800.jpg"
srcset="photo-400.jpg 400w,
photo-800.jpg 800w,
photo-1200.jpg 1200w"
sizes="(max-width: 600px) 400px,
(max-width: 1000px) 800px,
1200px"
alt="A mountain lake at sunrise"
loading="lazy">
Here's what each piece does:
srcsetlists available files with their widths. The browser — not you — picks the best one based on screen size and pixel density.sizestells the browser how wide the image will display at different viewport widths, so it can choose before downloading.loading="lazy"defers offscreen images until the user scrolls near them. Your initial page load only fetches what's visible.
The impact is dramatic. A mobile user on a 375px-wide phone gets the 400px version (~35 KB) instead of the 1200px version (~98 KB). That's a 64% reduction for the majority of web traffic — mobile accounts for roughly 60% of page views globally.
Generate three sizes per image: the full size, half, and quarter. Most build tools and CDNs automate this. If you're doing it manually, it's three exports from your compressor instead of one — an extra 30 seconds per image.
The <picture> Element for Format Switching
srcset handles sizes. For formats, use <picture> to serve WebP or AVIF with JPEG fallback:
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="A mountain lake at sunrise" loading="lazy">
</picture>
The browser picks the first format it supports. Modern browsers get AVIF or WebP; older ones fall back to JPEG. You get the best compression available without breaking anyone's experience.
This is more markup to write, but the payoff is real: AVIF at quality 70 is roughly half the size of JPEG at quality 80, with comparable visual quality. For hero images that every visitor downloads, that difference matters.
WebP vs AVIF: An Honest Comparison
Both beat JPEG. But which should you actually use in 2026?
| WebP | AVIF | |
|---|---|---|
| Size vs JPEG | 25–35% smaller | 40–50% smaller |
| Browser support | Universal (all modern browsers) | Near-universal, minor Safari quirks |
| Encode speed | Fast | 5–10× slower than WebP |
| Decode speed | Fast | Slower on old devices |
| Tooling | Mature everywhere | Good, improving |
| Animation | Yes | Yes (better than GIF) |
| Transparency | Yes | Yes |
My recommendation: WebP as your default. It's fast to encode, universally supported, and the tooling just works. Use AVIF selectively for your largest, most-viewed images (hero banners, og:image social cards) where the extra 20% savings justifies the slower encode and testing overhead.
Don't overthink this. The jump from JPEG to WebP captures most of the available savings. The jump from WebP to AVIF is incremental — nice to have, not transformative.
What About Image CDNs?
Services like Cloudinary, Imgix, and Cloudflare Images can automate everything above: upload one high-res source, and they serve resized, reformatted, quality-optimized versions on the fly via URL parameters.
https://cdn.example.com/photo.jpg?w=800&format=webp&quality=80
Change w=800 to w=400 and you get the mobile version. No manual exports, no build step.
The tradeoff: cost and complexity. These services charge by bandwidth or transformations. For a personal blog or small site, manual optimization (or a build-time tool like sharp or squoosh-cli) is free and gives you full control. For a large site with thousands of images and a team, a CDN pays for itself in engineering time saved.
There's a middle ground: build-time optimization. Tools like Next.js's <Image> component, Gatsby's image plugins, or a simple sharp script in your build pipeline automatically generate responsive sizes and modern formats at deploy time. You write <Image src="photo.jpg" width={1200} /> and the framework handles the rest. Zero runtime cost, zero manual work after setup.
Putting It Together: A Real Walkthrough
Starting point: a 6000×4000 stock photo, JPEG, 2.4 MB.
- Resize to 1200×800 → ~480 KB (80% reduction)
- Convert to WebP → ~310 KB (35% smaller than the resized JPEG)
- Quality 80 → ~115 KB
- Strip EXIF → ~98 KB
Final: 2.4 MB → 98 KB. A 96% reduction. Side by side on a monitor, you cannot tell them apart. I mean that literally — put the original and the compressed version next to each other at display size and try to spot the difference.
If you need to go further (say, under 50 KB for a thumbnail), drop to quality 65–70 and resize to 800px. You'll see minor artifacts if you pixel-peep, but at thumbnail size nobody will notice.
Common Mistakes
Compressing without resizing first. Running a 6000px image through a compressor at quality 60 gives you a 400 KB file that still looks bad. Resize first, then compress. Order matters.
Using PNG for photographs. I keep saying this because I keep seeing it. PNG is lossless — great for screenshots with text, terrible for photos. A photo saved as PNG is often 5–10× larger than necessary.
Quality 100 "to be safe." Quality 100 doesn't mean "best for web." It means "minimum compression," which produces files 3–4× larger than quality 80 with zero visible improvement on screen. You're paying for peace of mind with your users' bandwidth.
Upscaling small images. If your source is 800px and you need 1200px, don't upscale — you'll get a blurry 1200px image that's larger in file size than the sharp 800px original. Find a bigger source or accept the smaller size.
Forgetting about retina. Serving a 400px image in a 400px slot looks soft on a MacBook or modern phone. Serve at 2× (800px image, displayed at 400px CSS pixels). But don't go to 3× — the file size jump isn't worth the imperceptible sharpness gain.
Optimizing once and forgetting srcset. If you serve the same 1200px image to phones and desktops, mobile users download desktop-sized files. Use srcset to serve smaller versions to smaller screens:
<img src="photo-800.jpg"
srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
alt="...">
This alone can cut mobile image payload by 60–70%.
Try It
You don't need Photoshop or a build pipeline for any of this. DailyToolbox's free image compressor runs entirely in your browser — drop in a photo, pick your target size and quality, and download the result. Nothing uploads to a server, which also means your images stay private.
FAQ
Will compressing to under 100KB work for all images? For typical web photos at content sizes (800–1200px), yes. Very detailed images (dense foliage, crowds) compress less efficiently and might land at 120–150 KB at quality 80 — that's fine. Don't chase the number at the expense of visible quality.
Should I use WebP or AVIF? WebP for now. It's universally supported and the tooling is mature. AVIF saves another 20–30% but encodes slowly and has edge cases in Safari. Revisit AVIF in a year or two when the ecosystem catches up.
Does image compression affect SEO?
Indirectly, yes. Google uses page speed (Core Web Vitals) as a ranking factor, and images are usually the biggest contributor to slow loads. Smaller images → faster LCP → better rankings. Also add descriptive alt text and filenames — that part matters for image search.
What about lazy loading?
Lazy loading (loading="lazy" on below-the-fold images) is complementary, not a substitute. It defers loading offscreen images, but the images still need to be small when they do load. Do both.
How do I handle user-uploaded images?
Validate on upload: reject files over a sane limit (say 5 MB), then process server-side or in a background job — resize to max dimensions, convert to WebP, strip EXIF. Never serve user uploads raw. Libraries like sharp (Node.js), Pillow (Python), or ImageMagick handle this in a few lines. Also consider limiting accepted formats to JPEG, PNG, and WebP to reduce attack surface.
Does compressing images affect print quality? Web-optimized images (72–96 DPI equivalent, compressed) look bad in print. If your site offers downloadable/printable versions, keep a separate high-res original and serve the optimized version for screen display only. Don't try to make one file serve both purposes.
What's the deal with "Save for Web" in Photoshop? It's the manual version of everything in this article — resize, format choice, quality slider, metadata stripping. It works fine, but it's 2026: use an automated pipeline or a browser tool instead. Manual "Save for Web" doesn't scale past a handful of images, and humans are inconsistent with quality settings.