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 (1)
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.