Most image advice is written page by page. Run a speed test, find the heavy hero, fix the hero, move on. That works, and it misses most of what a site actually ships. A website does not serve one image at a time, it serves a set: an icon in a browser tab, a card that appears when someone pastes your link into Slack, a logo in the header of every page, a photo next to an author name. Those assets are generated once, usually in a hurry, and then nobody looks at them again for years.
They also never show up in a performance report. A 404 favicon costs no milliseconds. An undersized social card does not affect Core Web Vitals. A logo exported at 2000 pixels for a 140 pixel slot will not fail an audit. They fail quietly, in places you do not visit: other people's tabs, other people's chat windows, other people's phones.
This is an inventory audit rather than a speed audit. If you want the page-speed math, the byte budgets and the LCP reasoning, that is a different job and we wrote it up separately in our guide to optimizing images for SEO. What follows is the checklist for the whole set, and at the end we run it on our own site and publish what broke.
The seven asset classes every site ships
Almost every website, from a one page portfolio to a large store, ships the same seven categories of image. Naming them is most of the work, because the ones people forget are the ones with no page of their own.
Work down the list in that order. It is roughly the order of how likely each one is to be broken, and it puts the cheapest fixes first.
1. Favicons are a set, not a file
The single biggest misconception here is that a favicon is one image. In practice a browser might ask for a 16 pixel icon for the tab, a 32 pixel one for a bookmark bar, or nothing at all if it finds an SVG it likes. A crawler or a feed reader will often skip your markup entirely and request /favicon.ico at the root, because that is where the convention says it lives.
So a complete favicon setup is three things: an SVG for modern browsers, an ICO at the root as the universal fallback, and PNGs at 16, 32 and 48 pixels for anything that wants a raster. The failure mode people actually hit is shipping one large PNG and letting the browser scale it down. A logo that reads beautifully at 512 pixels turns into four grey smudges at 16, because at that size you have room for one shape and maybe two colors, not a wordmark.
Check it in ten seconds: open your site, then shrink the browser window until the tab is at its narrowest. That is the size most people actually see your icon at. If you cannot tell what it is, redraw it rather than rescale it.
Building the set is the easy part. Drop a square source into the favicon generator and it produces the whole range at once, including the ICO, rather than making you export six times.
2. Touch icons and app icons
The apple-touch-icon is what iOS uses when someone adds your site to their home screen, and it wants 180 by 180. Android and desktop install prompts read the icon list in your web app manifest, which conventionally carries 192 and 512 pixel versions plus a maskable variant.
Maskable is the one that catches people. Android crops app icons into whatever shape the launcher uses, a circle, a squircle, a rounded square, and it crops aggressively. An icon designed edge to edge loses its outer ring, so a maskable version needs its artwork inside roughly the central 80 percent with padding around it. It is the same geometry problem as a circular avatar, which we go through in detail on the profile picture cropper page.
3. Social cards, the asset nobody checks until it is wrong
Your Open Graph image is the one asset that is guaranteed to be seen outside your site, by people who have not decided to visit yet. It is also the one most likely to be a shared default that says nothing about the page being shared.
The working size is 1200 by 630, a 1.91:1 ratio. Go smaller and the platforms will either upscale it or fall back to a small square thumbnail layout, which is a much weaker unit in a feed. Keep meaningful text within the middle 80 percent, because different platforms crop the edges differently, and keep the file under a megabyte.
The deeper problem is not the dimensions, it is repetition. If all two hundred pages of a site share one generic card, every link anyone shares looks identical, and the card stops carrying information. It does not need to be per page. Per template is usually enough: one card for guides, one for product pages, one for the home page.
4. Heroes and in-content images
These two are the ones already covered by ordinary performance work, so the audit question is narrow: is the file bigger than the box it is displayed in, and is it in a sensible format? Right-size first, then choose format, then compress. The reasoning behind that order, with measured numbers, is in the SEO guide, and the format decision itself is laid out in JPG vs PNG vs WEBP.
The one thing an inventory pass adds is a question a page-by-page audit never asks: are your in-content screenshots PNGs that should be JPGs? PNG is the right choice for a screenshot of an interface with flat color and crisp text. It is the wrong choice for a screenshot that is mostly a photograph, where it can easily be five to ten times the size of an equivalent JPG. Sites that publish a lot of tutorials accumulate this quietly, one post at a time. Running a folder of them through the bulk compressor is a ten minute job that most sites have never done once.
5. Logos, wordmarks and avatars
A logo should be an SVG wherever it can be. It is usually smaller than the PNG equivalent, it stays sharp at any size, and it never needs a retina variant. The exception is email, where SVG support is unreliable and a PNG at twice the display size is the safe answer.
Avatars are worth a look because they are the asset most often uploaded by someone who is not thinking about pixels. Check that author photos are square, that the important part survives a circular crop, and that nobody has uploaded a 4 MB phone photo into a 48 pixel slot. While you are there, run one through the EXIF viewer. Photos taken on a phone often carry GPS coordinates, and a team page is a strange place to publish where someone lives.
6. The fifteen minute audit
You do not need tooling for this. Open your own site and work through the list.
- Request
/favicon.icodirectly in the address bar. If it 404s, you are relying entirely on your markup being read. - View source and check for the icon, apple-touch-icon and manifest links. Open each URL to confirm the file is actually there.
- Shrink the window and look at the tab icon at its real size.
- Paste three different page URLs into a private chat with yourself. Do the cards differ? Are they sharp? Is the text readable at thumbnail size?
- Right click your logo and open it in a new tab. Note the format and the pixel size, then compare it to the size it is displayed at.
- Pick your three most viewed articles and check the weight of every image in them.
- Look at your author photos, cropped to a circle.
Write down what you find before you fix anything. The list is almost always shorter than people fear and more specific than a generic performance report.
7. We ran this on ImgCruncher, and found six problems
It would be easy to publish a checklist and imply we pass it. We ran the audit above against our own live site in August 2026, and we did not. Six problems came out of it. Two were embarrassing enough that we fixed them before this article went live, and the other three are still open.
Finding 1: our own favicon.ico returned a 404. We declared an SVG icon and an apple-touch-icon in the head, and nothing else. Any client that went straight to the root path for an ICO got nothing. This was the one that stung, because we build and give away a favicon generator that produces the full set including the ICO, and we had never run our own site through it.
Finding 2: no raster favicon at all. There was no 16, 32 or 48 pixel PNG anywhere in our asset folder. Modern browsers were fine with the SVG. Everything else fell back to nothing.
Both of those are now fixed, and we fixed them with our own tool. We fed our app icon into the favicon generator and shipped exactly what it produced: a multi-size favicon.ico carrying 16, 32 and 48 pixel images, plus the matching PNGs. One detail is worth admitting: the generator did not offer 48 pixels when we started, because we had never needed it ourselves. We added that size to the tool first, then used it. The changelog has the entry, and anyone who wants the same set can generate it in about ten seconds.
Finding 3: every page shares one social card. We checked all 23 tool pages, the home page and the static pages. Every one of them serves the same og-default.jpg. It is at least the correct size, 1200 by 630 and 62.8 KB, but a link to our OCR tool and a link to our privacy policy produce an identical preview.
Finding 4: most of our blog covers are undersized. Blog posts do carry their own covers, which is better. But of 64 cover images, 49 are 800 by 450. That is below the 1200 by 630 the platforms want, so those previews are being upscaled or dropped into the small card layout. Only 11 are the correct size.
Finding 5: heavy PNGs inside our own tutorials. The audit turned up several in-post screenshots between 400 KB and 975 KB, the largest being a 975 KB PNG in our Instagram sizes article. They are demonstration crops of photographs, which is exactly the case where PNG is the wrong container. Converting those to JPG or WEBP is the single biggest weight saving available to us, and it is in articles that tell people to do precisely that.
Finding 6, which is not an image problem at all: the audit made us re-read our own copy, and we found that our About page, FAQ and cookie policy still promised the site "works offline once loaded". That was true when we ran a caching service worker. We retired that worker because it kept serving stale files after deploys, and nobody went back through the copy. The cookie policy was the worst of the three, because it described a caching mechanism that no longer existed on a page whose whole job is telling you what we store. All three are corrected now: the site is still installable and an open page keeps working without a connection, but we no longer claim you can load it offline.
Where that leaves us. Findings 1, 2 and 6 are fixed and in the changelog. Findings 3, 4 and 5 are open, and they are the honest kind of open: each one is a batch job we have not scheduled yet rather than something we do not know how to do. Per-template social cards, regenerating 49 undersized covers at 1200 by 630, and converting a folder of heavy PNGs are all straightforward with the tools on this site. They are queued for our next maintenance pass, and this section will be updated with what changed rather than quietly rewritten.
Two of these six came from being busy. One came from removing something and not auditing the words around it, which is the failure this kind of pass is really designed to catch. We would rather publish the list than fix it silently, because a checklist nobody has failed is not worth much.
8. Fixing a whole asset set in one pass
The reason asset audits get postponed is that the fix list touches five different jobs: generate icons, resize a card, convert a format, get a file under a limit, strip metadata. Doing that as five separate uploads to five separate tools is why the task never gets done.
Our tools chain, so the middle three of those steps happen in a single pass. Drop the file in once, stack a resize to 1200 by 630 in the image resizer, a format change in the image converter and a target size in the image compressor, then download the finished asset. We wrote up the mechanics of that with measured numbers in resize, convert and compress in one pass. Everything runs in your browser, which for a logo or an unreleased product screenshot is the difference between a quick fix and a conversation with someone about uploading brand assets to a third party.
How we checked
Every finding above came from the live site in August 2026, not from our local copy. We requested the icon paths directly and recorded the status codes, read the rendered og:image value from the served HTML of the home page, a tool page and two blog posts, and measured every cover image and asset on disk for dimensions and byte size. Counts are exact: 23 canonical tool pages, 64 cover images, 49 of them at 800 by 450.
The findings above are recorded as we measured them, in the past tense where we have since fixed them, so the numbers stay checkable against what we said. Anything we change from here goes in the changelog first.
