Every developer has shipped an image that was too heavy, wrongly sized, or worse: one that still had GPS coordinates buried in its EXIF data. I did it enough times that I ended up building a checklist, and eventually a set of free browser tools around it. Here is the checklist, with both manual ways to run each check and the shortcut.
1. Dimensions: is it the size it will actually display at?
Serving a 4000px-wide photo in an 800px container wastes bandwidth and hurts LCP. Check the rendered size in DevTools (hover the img in the Elements panel) and compare it with the intrinsic size. As a rule of thumb, export at 1x and 2x of the display size and let srcset do the rest.
<img src="hero-800.webp"
srcset="hero-800.webp 1x, hero-1600.webp 2x"
width="800" height="450" alt="...">
2. File size: does it fit your budget?
For most content images, aim for under ~150 KB; hero images can justify more. If you are on Node, sharp handles resizing and compression in one pass:
import sharp from "sharp";
await sharp("input.jpg").resize(1600).webp({ quality: 78 }).toFile("hero.webp");
3. Format: WebP/AVIF unless you have a reason not to
JPEG/PNG still make sense for compatibility corner cases, but WebP typically cuts 25-35% at equal quality, and AVIF more. Photographs: AVIF/WebP. Logos and flat art: SVG. Screenshots: WebP or PNG.
4. Metadata: strip what you don't want public
This is the one people forget. Photos from phones carry EXIF: device model, timestamps, and often GPS location. Check what's inside with exiftool:
exiftool photo.jpg | grep -i -E "gps|serial|owner"
Re-exporting through most build pipelines (sharp, imagemin) strips EXIF, but images uploaded straight to a CMS often keep it.
5. Filename and alt text: the SEO part
IMG_4032.jpg tells search engines nothing. blue-running-shoes-side-view.webp does. Same for alt text: describe the image for someone who can't see it. That serves accessibility first and image SEO as a side effect.
6. Social readiness: will the crop survive each platform?
The same source image gets cropped differently by Open Graph previews (1.91:1), Instagram (4:5 or 1:1), YouTube thumbnails (16:9 with TV-safe margins)... If a campaign matters, prepare dedicated crops. I keep a cheat sheet of every platform's exact pixel sizes because they change every year.
7. Open Graph: does the preview actually render?
Before sharing, verify og:image resolves, is at least 1200x630, and isn't blocked by robots. The classic way is the Meta Sharing Debugger or curl + eyeballing the tags:
curl -s https://example.com | grep -o '<meta property="og:[^>]*>'
The shortcut
Running all seven checks by hand gets old fast. I built PublishPixel to run them in one pass: you drop an image and it reports dimensions, weight, format fit, filename, alt-text plan, metadata (including GPS), and readiness for web/SEO/social/YouTube. Everything runs client-side in your browser: no upload, no account, files never leave your machine. It's free; it exists because of this checklist.
Disclosure: PublishPixel is my project. The manual methods above work fine without it. The point is to run the checklist somehow before hitting publish.
What would you add as check #8?
Top comments (0)