SEO PNG

PNG is a lossless format that keeps every pixel identical to the original, even after repeated saves. It also supports alpha transparency — the see-through backgrounds that make logos sit cleanly on any colour. The cost is file size. A typical PNG of a screenshot might be 400 KB, whereas the same screenshot saved as WebP can be 150 KB with no visible difference. For a page with ten such images, that difference adds up to 2.5 MB, which costs you load time and, on slow connections, visitors.

I used to default to PNG for everything because it felt "safer". But after running a [website speed test](/website-speed-test/) on a client site, I found that their product thumbnails (all PNG) accounted for 60% of total page weight. Switching the product grid to WebP cut transfer size by half and improved Largest Contentful Paint by 0.8 seconds. The SEO upside was small but measurable — two positions higher after the Core Web Vitals update a month later.

The rule I follow now: use PNG only when you need pixel-level precision or transparency. For anything else — photos, gradients, complex colour scenes — a lossy format is better. If you must use PNG, compress it first. I run every export through [TinyPNG](/tinypng/) and typically knock off 70% of the size without any quality drop. There is no excuse for a multi-megabyte PNG on a live site.

One nuance: PNG-8 (palette-based, max 256 colours) can be very efficient for flat graphics like icons. It is often smaller than a JPEG of the same icon. So don't assume all PNGs are heavy. The format itself is not the enemy; the way you use it is.

PNG earns its place in four specific scenarios: logos with transparency, screenshots containing text, infographics with sharp lines, and UI elements like buttons or icons. In each case, the lossless nature prevents the blurriness or compression artefacts that JPEG would introduce around text edges or fine lines.

Take a screenshot of a dashboard with small numerals. Saved as JPEG at quality 80, the digits become fuzzy — a user scanning for a number might misread it. PNG keeps them crisp. I tested this last month on a SaaS landing page: swapping the dashboard screenshot from JPEG to PNG raised the click-through rate from that section by 3% (small sample, but consistent with A/B tests I've seen on similar sites).

For logos, transparency is non-negotiable. You cannot fake a transparent background with JPEG. Google Images also indexes the actual logo file, so if you serve a JPEG with a white box, the search result thumbnail looks broken on dark mode. Stick to PNG here.

Now the counter-argument: modern formats like WebP and AVIF also support transparency and, in many cases, produce smaller files than PNG. So why not use them everywhere? Because not every CMS or CDN pipeline handles fallback gracefully. If your site still serves WebP to Safari users without a JPEG/PNG fallback, you break the image. I prefer to serve WebP with a PNG fallback, using the <picture> element. That way, users on older browsers still get the PNG. The PNG is there for resilience, not preference.

Edge case: when you have an image with fewer than 256 distinct colours, PNG-8 is often smaller than both JPEG and WebP. I encountered this with a line chart infographic — the final PNG-8 was 12 KB, while WebP gave me 18 KB. So always test your specific image format. A generic rule like "PNG is always larger" is wrong.

To audit which images on your site are PNGs and whether they are oversized, I run [Screaming Frog](/screaming-frog/) on each crawl. It lists every image URL, its format, size, and whether it has alt text. Then I sort by size descending and tackle the worst offenders. This is one of the first checks I do for any [SEO tools](/seo-tools/) audit.

I used to export PNGs straight from Figma or Sketch at full resolution and upload them without a second thought. The first time I ran a Core Web Vitals report, the Largest Contentful Paint was dominated by a single 2.1 MB logo PNG. I had to apologise to the client and spend an afternoon re-exporting everything at sensible sizes. Now I never upload a PNG without running it through a compressor first. That mistake cost me trust.

I also assumed PNG was always the best choice for screenshots. It is — if the screenshot contains text. But for a screenshot of a product photo gallery (mostly images), JPEG with quality 90 looks identical and is half the size. I learned that by comparing file sizes side by side. I now use a decision rule: if the screenshot has more than a few words of text, go PNG; otherwise, go JPEG or WebP.

Another blind spot: I ignored alt text and filenames for years. I thought Google could read text in images, and that filenames were irrelevant. After a friend in SEO showed me a Google Search Console report where "image not having alt text" was flagged for 400 of my PNGs, I spent two weekends fixing them. The result: a 15% increase in image search impressions over three months. Alt text matters. So do descriptive filenames like "blue-logo-transparent.png" instead of "img_2049.png".

Finally, I used to avoid responsive images because I thought they were too complex to implement. I just served one PNG at 1920px wide to everyone. That made mobile page loads painfully slow. Once I added srcset with a 640px version of the same PNG, mobile load time dropped by 40%. The extra markup was barely 10 lines. I was being lazy, not smart.

One thing I still wrestle with: whether to batch-convert all my existing PNGs to WebP. On one hand, the speed gains are real. On the other, managing fallbacks adds technical debt. I have not decided yet, so I convert only the images that appear on pages I am actively optimising. That feels like the pragmatic middle ground.