A surprising amount of "my site is slow" comes down to one thing: someone dropped a 4032x3024 photo straight off their phone into a content block that renders at 800px wide. The browser downloads all 5 MB and then throws most of it away during resize. Multiply that by a dozen images and you've got a page that takes 8 seconds on a hotel wifi.
Getting an image "web-ready" is really three decisions made in order: resize first, then choose a format, then compress. Do them in that order and you usually cut file size by 80-95% with no visible quality loss. Here's how to actually do it, with the numbers that matter.
Step 1: Resize to the size it's displayed at (this is the big win)
This is the step people skip, and it's the one that matters most. Pixels you can't see still cost bytes.
Figure out the largest size the image is ever shown at, then add a buffer for high-DPI screens:
- Full-width hero on a normal layout: cap at ~1920px wide. Even 4K monitors rarely render a content image wider than that.
- Blog post inline image / content column: the column is usually 700-800px, so export at 1600px (2x for retina) and let CSS scale it down.
- Thumbnail / avatar / card image: displayed at 200px? Export at 400px. No more.
- Icons and logos: if it's flat/geometric, this should be an SVG, not a raster image at all.
The math is brutal in your favor here. A 4000x3000 image is 12 million pixels. Resized to 1600x1200 it's 1.9 million pixels — 84% gone before you've compressed anything. Resizing from 4000px to 1600px usually takes a 5 MB JPEG down to roughly 600-900 KB on its own.
Quick rule: if the longest edge of your file is bigger than 2000px and it's not a print asset or a zoomable gallery image, it's too big.
Step 2: Pick the right format
Format choice is mostly about what's in the image:
- Photographs / complex gradients → JPEG or WebP. Lots of color, no hard edges, no transparency. JPEG is universally supported; WebP is ~25-35% smaller at the same quality and supported by every browser shipped in the last 5+ years.
- Screenshots, UI, text, line art, anything with sharp edges → PNG or WebP (lossless). JPEG turns crisp edges into a smeary mess of artifacts. This is the #1 format mistake — saving a screenshot of code as a JPEG.
- Needs transparency → PNG or WebP. JPEG has no alpha channel.
- AVIF is the smallest of all (often 20% under WebP) but it's slower to encode and a bit fussier; great for hero images where the savings are worth it, overkill for thumbnails.
Honest default for 2026: WebP for almost everything, with a JPEG fallback only if you're targeting truly ancient clients. If you don't want to think about it, JPEG for photos and PNG for screenshots is still perfectly fine and will never surprise you.
Step 3: Compress with a target quality, not "maximum"
For lossy formats (JPEG/WebP/AVIF), quality is a 0-100 dial, and the sweet spot is lower than people expect:
- Quality 80-85 is the standard "looks identical, much smaller" zone for photos. Start here.
- Quality 70-75 is fine for thumbnails and background images where nobody's pixel-peeping.
- Above 90 you're mostly adding bytes you can't see. Below 60 you start to notice blocking in skies and skin tones.
A typical 1600px photo at quality 82 lands around 120-200 KB. That's the target to aim for on a content image. If you're well above 300 KB after resizing, your quality setting is too high or the format is wrong for the content.
For PNG screenshots, "quality" works differently — you reduce the color palette (e.g. down to 256 colors) and run lossless optimization. A flat UI screenshot can drop 60-70% with palette reduction and look identical.
Doing it without installing anything
If you live in the terminal, the local CLI tools are excellent and worth knowing — they're scriptable, run offline, and keep files on your machine:
-
ImageMagick:
magick input.jpg -resize 1600x -quality 82 output.jpgdoes resize + compress in one shot.mogrifybatches a whole folder. -
cwebp:
cwebp -q 80 input.png -o output.webpfor WebP conversion. - sharp (Node) or Pillow (Python) if you want this baked into a build step or an upload pipeline. This is the right answer for anything recurring.
- squoosh-cli wraps the same encoders Squoosh uses, good for AVIF.
If it's a one-off, or you're on a machine where you can't install things, or you just don't want to remember ImageMagick's flag soup, a browser tool is faster. Web options worth knowing: Squoosh (Google's, the gold standard for fiddling with one image and watching the quality slider in real time, fully client-side), TinyPNG (dead simple, great auto-compression, but free tier caps file size and count), and Photopea if you also need to actually edit.
For the plain resize-then-compress run I described above, I usually point people at the image tools on BestAIFinds — full disclosure, I help build that one, so weigh that accordingly. There's a compress tool, a separate resize tool, and format conversion, all free with no sign-up or watermark, and uploads auto-delete within about an hour. Squoosh is genuinely better if you want to manually tune one image with a live preview, so use that when you care about a single hero shot. For batching a folder, honestly just use ImageMagick.
The privacy caveat you should actually think about
Any browser tool that uploads to a server means your image touches someone else's machine, even if it's deleted an hour later. For a marketing photo or a screenshot of public docs, who cares. For anything with PII, internal dashboards, unreleased product shots, medical or legal material — use a local CLI or a fully client-side tool (Squoosh and ImageMagick never send your file anywhere). This isn't paranoia, it's just matching the tool to the sensitivity of the file. Read whether a tool processes in-browser or server-side before you paste in something confidential.
Putting it together
The whole workflow for a typical content image:
- Resize longest edge to ~1600px (or 2x your display size). Biggest single saving.
- Pick format: WebP or JPEG for photos, PNG/WebP for screenshots and UI.
- Compress to quality ~82 for photos, ~75 for thumbnails. Aim for under ~200 KB.
- Sanity-check the output actually looks fine at the size it'll be shown, not zoomed to 400%.
Do those four things and a page that was shipping 6 MB of images ships maybe 600 KB, with no visible difference. Your Lighthouse score, your mobile users, and your bandwidth bill all thank you.
What's your default quality setting and format these days — has WebP fully replaced JPEG in your workflow, or are you still shipping JPEG fallbacks? Curious what edge cases are keeping people on the old formats. Drop a comment.
Top comments (5)
WebP is usually by go-to, but if it's something I think people will download, then PNG. Either way, you really should never be using JPEG, I dont even know why anyone still uses it? As for compression. Eg. document processing, you take a PDF and convert to PNG, 94% or down to 82% quality tends to retain enough details for good recognition, but for safety I stick to 94%, it's still a massive size drop, but it's the difference between a 0, O and o when dealing with blurry, grainy, skewed, crumpled scans.
This is a great comment. The 0/O/o thing is exactly why I never trust aggressive compression on anything with text — totally with you on PNG or lossless WebP for downloads and UI. The one place I'd still defend JPEG is pure photos with no text, where it (or WebP) is hard to beat on size and it works literally everywhere. Genuinely curious about your OCR setup though: does 94% hold up across fonts, or do the nasty scans — thermal receipts, dot-matrix, faxes — still push you higher?
Faded Dot matrix, shifted by 2 columns, at 94%, works flawlessly, with PaddleOCR and with Google Vision/gemini. What 94% does, is it just clears document artifacts, like micro deviations in white levels on paper, which is a bonus, not a deficit. Given it's for an autonomous accounting suite, where 99.99% extraction accuracy must be guaranteed, while keeping cloud storage costs down, 94% is imo the sweetspot. For structured pdfs, that werent scanned, or scans at 300 dpi, 82% gives you all the quality you need. With the JPEG, the exact problem is that WebP exists, which has far more benefits. JPEG unfortunately like so many other things, is a legacy format that's still widely used despite being deprecated.
Makes sense — using the compression step as a free denoiser is a neat way to squeeze accuracy out of an autonomous pipeline. And you've sold me on WebP-by-default; in a pipeline you actually control there's no real case left for JPEG. Appreciate you laying this out in such detail — genuinely one of the more useful comment threads I've had on here.
Thank you, it's nice having someone ask functional questions, rather than just 'does it work', 'where's benchmarks', 'benchmarks not detailed enough'... For Doccit, I tried everything to squeeze the highest efficiency out of it, so I can keep pricing low and not die from cloud storage costs over time, which is why WebP was the way to go and the 94% quality was the cleanest way I found to take a noisy color scan and just normalize it enough, without bleeding accuracy. In the end, most scans actually worked better at 94% than they did at native, because of that bit of denoising and smoothing. Doesnt hurt that it dropped scans from a few MB to a new hundred KB, the OCR engine ran it much faster and the models used to semantic reasoning and validation dropped their cost quite alot too. Often times, things were just meant to run faster and imo digital files are 1 of those cases. That being said, I am working on a 'unified file theory', lets face it, all modern file types were designed for human consumption, despite more than 50% of the internet being AI content and AI bots at the moment. I worked out a system that can represent any kind of file (eg. document, form, spreadsheet, photo, even video) and have it be deterministic. No JSON wrappers, no CSS styling, stripped of all the bloat and optimized for inference. Initial testing seems promising, once it's at a demo-stage, I'll write up a post on it. I kinda felt the need for it, since my last experiment ended up creating a data-protocol that's runtime-encrypted and saturates DDR5 dual channel when doing E2E tests 😂 For perspective, that's 40GB/s tested via a whatsapp like app (audio, video, messages), a file-transfer system like Google Drive (except chunks are saved encrypted), a banking infrastructure layer that runs at p99 25 microseconds per transaction on consumer hardware, next is as an anydesk style remote desktop system, then I'm releasing the 3 (Messenger, FTP, Remote Desktop) for free, but closed-source, so people can give it a test. But on the side working on the unified file type, because they're built on the same system, you'll have actually unhackable (unless you magically possess a pc that runs at exahertz speeds) data transfer and encrypted files that need to be unlocked in realtime if you dont want garbage data. So some big stuff dropping in the near future.