The single biggest performance win I ever shipped on WP Adminify's marketing site wasn't a caching plugin or a CDN tweak. It was deleting one image. Our old hero was a 2,400px PNG screenshot I'd exported at "full quality" because I stubbornly believed PNG meant crisp. That one file was 1.4 MB. On a mid-range Android over 4G, it was the Largest Contentful Paint element — and it was dragging LCP to roughly 4.1 seconds. I swapped it for an 84 KB WebP at the actual display width and LCP dropped under 1.9s the same afternoon. No code. Just a smaller picture.
That's the frustrating thing about image SEO. It's not exotic. Images are usually the heaviest thing on the page — often close to half the total bytes — and yet most of us treat them as an afterthought. We drop a camera-original into the CMS, type "screenshot" into the alt field, and move on. Then we wonder why the Core Web Vitals report in Search Console is bleeding red on mobile.
This guide is the checklist I actually run on toolz.dev and client sites, written from the perspective of someone who ships this stuff. I'll be honest about what the free tools do and — just as important — what they don't. Every image tool on toolz.dev runs entirely in your browser on a <canvas>, so nothing you drop in gets uploaded anywhere. That has real consequences for your workflow, some good, one annoying. We'll get to both.
TL;DR: Resize the image to its real display width first, then compress, then serve a modern format. In practice that's three passes: Image Resize to cut the pixel dimensions, Image Compress to squeeze the bytes, and Format Converter to get WebP. Add
width/heightattributes to stop layout shift, write alt text a human would say out loud, and lazy-load anything below the fold. Do that and your LCP and CLS both improve — the two image-driven Core Web Vitals Google actually ranks on.
Why do images matter so much for SEO?
Two of the three Core Web Vitals are image problems in disguise. Largest Contentful Paint is, on most content pages, the hero image finishing its download. Cumulative Layout Shift is very often an image loading late and shoving the text down a line. Both are confirmed ranking inputs, and both are things you fix by handling images better — not by writing more content.
There's a second traffic channel people forget: Google Images. For a lot of e-commerce, recipe, travel, and design sites, image search is a meaningful slice of organic visits, sometimes a fifth of it. That traffic depends entirely on things a crawler can read — the file name, the alt text, the surrounding copy, and whether the image is even small enough to get indexed promptly.
And then there's the boring-but-real one: bandwidth costs money and patience. A page that ships 3 MB of images bounces mobile users on metered connections before they see your headline. Faster pages keep people around, and engagement, however Google measures it, doesn't hurt.
What image format should you actually use?
Format choice is where most of the savings live, and the rules are simpler than the format wars make them sound.
JPEG is for photographs — anything with smooth gradients and thousands of colors. It's lossy, which is exactly what you want for a photo. At quality 75–85 the compression is invisible to a normal viewer and the file is a fraction of the original. Don't use it for anything with hard edges, text, or transparency.
PNG is lossless. Use it for screenshots, logos, diagrams, and anything with flat color regions or transparency. The catch: for a photograph, PNG produces a comically large file compared to JPEG. My 1.4 MB hero mistake was exactly this — a photographic-ish screenshot forced into PNG.
WebP is the practical default in 2026. It does both lossy and lossless, supports transparency and animation, and typically lands 25–34% smaller than JPEG at matching quality. Browser support is universal now. This is the format I convert almost everything to.
AVIF compresses even harder — often meaningfully smaller than WebP — because it's built on the AV1 video codec. It's a great format. But I have to be straight with you here, because a lot of guides (including the draft this article replaced) tell you to "just convert to AVIF" with an online tool, and that's not how browser canvas encoding works.
SVG is for vectors: icons, logos, simple illustrations. It scales infinitely and stays tiny. It's useless for photos.
The AVIF caveat nobody mentions
Here's the honest bit. toolz.dev's Format Converter exports PNG, JPEG, or WebP — and only those three. It can't output AVIF, and neither can most in-browser converters. The reason is technical: the tool draws your image onto a <canvas> and calls canvas.toBlob('image/webp', quality). The browser's canvas encoder ships JPEG, PNG, and WebP; it does not ship an AVIF encoder. So there is no way to squeeze an AVIF out of a canvas, full stop.
You can still feed an AVIF file in — the browser decodes AVIF happily via new Image(), so an AVIF drop-in gets rendered to canvas fine. You just can't get one back out. It's a decode-in, encode-out asymmetry, and it trips people up constantly.
So my real-world advice: use the Format Converter for the WebP step, which is the one that covers 95% of the win. If you want AVIF on top, generate it in your build pipeline with sharp, avifenc, or Squoosh's offline encoder — that's where AVIF belongs anyway, because its encoding is slow and you don't want to do it by hand for every image.
| Format | Best for | Lossy? | toolz.dev converter can output it? |
|---|---|---|---|
| JPEG | Photos | Yes | Yes |
| PNG | Screenshots, logos, transparency | No | Yes |
| WebP | Almost everything on the web | Both | Yes |
| AVIF | Max compression on heavy images | Yes | No — use a build tool |
| SVG | Icons, logos, vector art | N/A | No (vector, not canvas) |
How do you compress images without wrecking quality?
The mistake I see most is compressing the wrong thing in the wrong order. Compressing a 4000px image that displays at 800px is like vacuum-sealing a suitcase you never needed to pack. Resize first, compress second. Always.
So the workflow is: open Image Resize, set the width to the largest size the image will actually render at (check your layout — a blog body image is often 720–800px, not 1920). The resizer fits inside your target box and never stretches or crops, so aspect ratio is safe. Then take that output into Image Compress and pull the quality down until you can just barely tell — usually 78–82 for photos. Preview at full zoom before you commit; artifacts hide in gradients and skin tones, not in the thumbnail.
One number to anchor on: for photographic content, quality 80 is the boring, reliable answer. I've A/B'd 80 against 90 on real product shots and, at 100% zoom on a good monitor, most people can't call it. But 80 is often 40% smaller. Below about 60 you start seeing blocky artifacts in smooth areas, so that's the floor for anything but a tiny thumbnail.
Two browser gotchas that will confuse you
Both of these cost me real debugging time, so learn them free.
Transparent PNG → JPEG turns the background black, not white. I once converted a transparent logo to JPEG and the transparent areas came out solid black. I assumed the tool was broken and spent twenty minutes staring at it. It's not a bug — it's the HTML spec. When you serialize a canvas to a format with no alpha channel (JPEG), the transparent pixels get composited onto solid black. If you need transparency, keep PNG or use WebP, which supports alpha. If you specifically want a white background, put a white layer down first.
Every re-encode strips EXIF and GPS metadata. Because these tools redraw the image onto a fresh canvas, the output has no EXIF, no camera info, no embedded GPS coordinates. That's a genuine privacy win — you're not accidentally publishing the latitude/longitude your phone stamped into a photo. But it's also a gotcha if you were relying on embedded color profiles or copyright metadata; those go too. For SEO it doesn't matter, but know it's happening.
How do responsive images and srcset work?
A phone renders images at maybe 390px wide. Shipping it a 1920px file wastes most of the bytes you just carefully compressed. srcset fixes that by handing the browser a menu of sizes and letting it pick.
<img
src="product-800.webp"
srcset="product-400.webp 400w,
product-800.webp 800w,
product-1200.webp 1200w"
sizes="(max-width: 600px) 100vw, 800px"
alt="Matte-black wireless headphones on a walnut desk"
width="800" height="600" loading="lazy" />
To make those three files, run the same source through Image Resize at 400, 800, and 1200px, then convert each to WebP. The sizes attribute is the part people skip, and skipping it quietly breaks the whole thing — without it, the browser assumes the image fills the viewport and grabs the biggest candidate. Tell it how wide the image really renders and it downloads the right one.
How do you write alt text that actually helps?
Alt text is the other half of image SEO and it's the half developers rush. It does three jobs at once: it's what a screen reader reads aloud to a blind user, it's how a crawler understands what the image shows, and it's the fallback text if the image fails to load. Getting it right is mostly about writing like a person, not a keyword robot.
The rule I use: describe the image the way you'd describe it to someone on a phone call. Specific, natural, short — under about 125 characters so screen readers don't truncate it awkwardly. Skip "image of" or "photo of," because the screen reader already announces that it's an image; leading with those wastes the listener's time. And if your target keyword genuinely fits the picture, include it once, naturally. If it doesn't fit, leave it out — a photo of a keyboard doesn't need "buy cheap wireless headphones" jammed into its alt.
A few before/afters from real reviews I've done:
alt="image"→alt="Matte-black wireless headphones on a walnut desk"alt="chart"→alt="Bar chart of monthly revenue rising from $10K in January to $45K in December"alt="best cheap headphones buy now free shipping sale"(keyword-stuffed) →alt="Over-ear headphones with the carrying case open beside them"
One nuance people get wrong: purely decorative images — a divider, a background flourish — should have an empty alt="", not a description. An empty alt tells the screen reader to skip it entirely, which is exactly what you want for decoration. Reserve real alt text for images that carry information.
While you're at it, name the file descriptively too. wireless-headphones-matte-black.webp beats IMG_4532.jpg because search engines read the filename as a signal, and hyphens (not underscores) are the separator Google parses as word breaks.
How much does this actually change Core Web Vitals?
LCP (Largest Contentful Paint): your hero is usually the LCP element. Serve it at the right dimensions, in WebP, at quality ~80, and — critically — do not lazy-load it. Lazy-loading the above-the-fold hero is a classic self-own; it delays the exact element LCP is measuring. If it's the hero, <link rel="preload" as="image"> it instead.
CLS (Cumulative Layout Shift): always put width and height on the <img>. Those two attributes let the browser reserve the space before the image arrives, so text doesn't jump when it loads. This is the single cheapest CLS fix there is and I still find sites missing it.
INP (Interaction to Next Paint): images don't directly drive INP, but a page choking on 3 MB of un-optimized pictures is starving the main thread and the network of the capacity your JavaScript needs to respond. Lighter images, snappier interactions, indirectly.
A few things I've learned the annoying way
Audit before you optimize. Run the page through PageSpeed Insights and fix the heaviest file first — the 1.2 MB offender matters more than shaving 4 KB off an icon. Name files like a human: wireless-headphones-matte-black.webp beats IMG_4532.jpg in image search because the crawler reads the filename as a content signal. Write alt text you'd actually say describing the photo to someone on the phone — specific, natural, keyword-included only where it fits, never keyword-stuffed. And don't forget your Open Graph share image; a correctly sized 1200×630 that you made in Image Resize is what shows up in social previews and, sometimes, search.
Frequently Asked Questions
Does image optimization really affect SEO rankings?
Yes, through Core Web Vitals. LCP and CLS are confirmed Google ranking signals, and both are heavily image-driven. Optimized images typically improve mobile page-speed scores by a noticeable margin, and on mobile that can translate to ranking movement. It also unlocks Google Images as a separate traffic source.
Can I convert images to AVIF with a free online tool?
Usually not, and toolz.dev's Format Converter can't. In-browser converters draw to a <canvas>, and the browser's canvas encoder only outputs JPEG, PNG, and WebP — there's no AVIF encoder available to it. Convert to WebP online for most of the win, and generate AVIF in your build pipeline with tools like sharp or avifenc if you need it.
Should I use WebP or AVIF in 2026?
WebP is the safe default and what I reach for first — universal support, big savings, and you can make it in the browser. AVIF compresses even harder and is worth adding for large hero and gallery images, but generate it at build time and serve it via <picture> with a WebP fallback.
What quality setting should I compress JPEG and WebP to?
Quality 80 is the reliable answer for photos. It's usually indistinguishable from the original at normal viewing while being dramatically smaller. Preview at 100% zoom before committing, since artifacts show up in gradients and skin tones. Below 60, compression becomes visible.
Why did my transparent PNG turn black after converting to JPEG?
Because JPEG has no alpha channel. The HTML canvas spec says transparent pixels get composited onto solid black when you serialize to a non-alpha format. It's expected behavior, not a bug. Keep the image as PNG or WebP to preserve transparency, or composite it onto a white background first if you want white.
Do these tools upload my images to a server?
No. The image tools on toolz.dev process everything locally on a canvas in your browser — the file never leaves your device. A side effect worth knowing: every re-encode strips EXIF and GPS metadata, which is good for privacy but means embedded camera data and color profiles are dropped too.
What's the ideal file size for a web image?
As a rough target: hero images under ~200 KB, in-content images under ~100 KB, and thumbnails under ~30 KB. Those are very achievable once you resize to the real display width and serve WebP. The exact number matters less than the habit of resize-then-compress-then-convert.
Related reading and tools:
- Image Compress — cut file size after resizing
- Image Resize — make responsive sizes and social images
- Format Converter — export PNG, JPEG, or WebP
- The developer's image tools guide
- Image compression explained
