Image Optimization Checker

How to optimize images for the web, and what image SEO actually asks of them.

Images are usually the heaviest thing on a page and the least looked at after upload. Here is what "optimized" means in practice: the three sizes people confuse, the five formats, the markup that keeps a page steady while it loads, and the one image that should never wait.

Three sizes that get confused

Every image has three sizes, and most bad advice mixes them up. File weight is the number of bytes the browser has to download, the thing that decides how long the image takes to arrive. Pixel dimensions are the width and height the file was saved at, say 4000 by 6000 for a photo straight from a camera. Rendered size is the space the image actually fills on screen, which the page's CSS decides, often a few hundred pixels across.

The expensive mistake is the gap between the second and the third. A professional headshot delivered by the photographer at full resolution and uploaded as is can weigh several megabytes and display at 300 pixels wide. The browser downloads every pixel, then throws most of them away to fit the box. Nothing looks wrong, which is why it survives: the photo is sharp, the page is just slow. A reasonable target is a file saved at no more than about twice the width it displays at, which covers high-density screens, then compressed.

Regulated firms carry more of these than most sites: partner and advisor headshots, team photos from an office shoot, and the badges and award logos that sit in an About page or a sidebar. They are uploaded once, by someone in a hurry, and rarely touched again. This checker does not weigh files (see what it cannot see, above), but a count of legacy formats on an About page is often the first sign that those uploads were never resized.

JPEG, PNG, GIF, WebP and AVIF

Format matters because two files of the same picture at the same visual quality can differ a lot in weight. The older three each have a job; the newer two can do all three jobs in less space.

That is why this checker flags JPEG, PNG and GIF files rather than calling them wrong. A JPEG is a perfectly good file. It is simply no longer the lightest way to send a photograph, and on image optimization for a website the lightest file at the same quality is the whole game.

Lossy and lossless compression

Lossless compression shrinks a file without changing a single pixel; decompress it and you get exactly what went in. Lossy compression discards detail the eye is unlikely to miss, and gets far smaller files for it. For photographs, lossy at a sensible quality setting is almost always the right call: the discarded detail is noise and fine texture no reader will notice. For screenshots of a fee table or a chart with small type, lossless keeps the edges crisp. The mistake is using one setting for everything, which leaves either photos too heavy or text images smeared.

Responsive images: srcset and sizes

A single image file cannot be the right size for a phone and a wide desktop at once. The srcset attribute lists several widths of the same image, and sizes tells the browser how wide the image will display, so the browser picks the smallest file that still looks sharp on that screen. The phone gets the 600-pixel file, the desktop the 1200.

<!-- three widths, the browser chooses -->
<img src="/images/team-1200.webp"
     srcset="/images/team-600.webp 600w,
             /images/team-1200.webp 1200w,
             /images/team-2000.webp 2000w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="1200" height="800"
     loading="lazy" alt="The advisory team outside the office">

To offer AVIF with a fallback for older software, wrap the image in <picture> with a <source type="image/avif"> above the <img>. This checker reads that markup: an <img> inside a <picture> whose <source> offers WebP or AVIF, or whose own srcset lists a .webp or .avif file, counts as modern, and its JPEG or PNG fallback is not flagged.

Width and height, so the page does not jump

When an image has no width and height attributes, the browser does not know how much room to leave for it until the file arrives. The text below is laid out first, then shoved down when the image lands, which is the jolt that makes a reader tap the wrong link. Google measures this as Cumulative Layout Shift, one of its Core Web Vitals. The fix costs nothing: put the image's real width and height on the tag, and let CSS scale it. Modern browsers use the two numbers to reserve a box of the right shape before a byte of the image has loaded. This tool does not check for them, so it is worth a look while you are in the markup.

Lazy loading, and the one image that should not wait

loading="lazy" tells the browser not to fetch an image until the reader scrolls near it. On a long article with a dozen charts and photos, that means the first screen loads with only the images it shows, and the rest arrive as they are needed, or never, for a reader who leaves early. Browsers support the attribute natively; no script is required.

The exception is the image at the top. The hero photo on an article is often the largest thing in the first screen, which makes it the element Google times as Largest Contentful Paint. Lazy-loading it makes the browser wait before even requesting it, and the page feels slower for it. Load it at once, and consider fetchpriority="high" to move it up the queue. That is why this checker exempts the first image in the main content and counts only the ones after it. It is a rule of thumb: if your hero is the third image in the markup, the first two are exempt in spirit, and the count will include one you should leave alone.

Many themes and plugins lazy-load with a script instead, putting a tiny placeholder in src and the real address in an attribute like data-src. This checker skips images whose src is an inline data: placeholder, so a page built that way can pass both checks without a single image being read. A pass on such a page means "nothing to count", not "all clear".

Image SEO: what search engines read

For search, an image is its markup more than its pixels. Google indexes images from HTML <img> elements, including ones inside <picture>, and says it does not index images set as CSS backgrounds, so a photo you want found in Google Images belongs in an <img> tag. It reads the file name, the alt text, and the words around the image to work out what it shows. A file called IMG_4471.jpg says nothing; office-closing-denver.webp says something. Alt text is its own subject, covered by the Image Alt Tag Checker.

Weight feeds search indirectly. A heavy hero image is one of the most common reasons a page is slow to show its main content, and Google uses Core Web Vitals, including Largest Contentful Paint, among its page experience signals. It is careful to say that relevant content matters more. Faster images will not rescue a thin page, but a slow one makes a good page harder to use.

Never put the words in the picture

The image problem specific to regulated sites is text saved as a graphic: a rate table exported as a PNG, a disclosure pasted as a screenshot, a credential or license number set inside a banner. A screen reader cannot read it unless someone wrote it all into the alt text, a search engine cannot reliably read it, a visitor cannot select or copy it, and nobody can update one figure without reopening the design file. When the rate changes or the disclosure wording is revised, the graphic is the copy that gets missed. Put the words in HTML, where they can be read, searched, reviewed and changed; use the image for what only an image can show.

Verand's thresholds, stated as ours

No standard says when an image becomes "oversized" or which formats count as modern, and most checkers do not tell you where they draw the line. These are ours, taken from the code the tools run:

Where else to check

For the measurements this tool does not make, use a browser-based test. Google's PageSpeed Insights runs Lighthouse against the page in a real browser, runs its scripts, and reports actual bytes and rendered sizes; Lighthouse has reported this ground under audit names like "Serve images in next-gen formats", "Properly size images" and "Defer offscreen images". GTmetrix and WebPageTest show each image's download in a waterfall, which is the quickest way to spot the one file that weighs more than the rest of the page. Their numbers will differ from this checker's, and from each other, because each looks at a different slice of the page; see the last question below.