How to Convert PNG Screenshots to AVIF
Convert PNG screenshots to AVIF for lighter blog images, sharper UI text, and safer fallbacks when older browsers still need PNG or WebP.
Contents
Convert PNG screenshots to AVIF when the image is a blog, docs, or product UI capture that needs to load faster without fuzzy text. Keep the original PNG as your editing source, export AVIF for the page, and add a WebP or PNG fallback if your audience includes older browsers.
I don’t treat AVIF as magic. In a local 1600×900 screenshot-style test for this article, the PNG was 8,798 bytes, the WebP export was 7,154 bytes, and the AVIF landed at 1,884 bytes. Nice. But that same result would be boring on a 2 KB icon.
Check the PNG before you convert it
Start with the screenshot you already have. Open it in Preview on macOS, Photos on Windows, iPhone Photos, Android Gallery, or Paint, then crop out browser chrome, empty margins, and repeated whitespace before touching a converter.
This is the native-method part that people skip. A screenshot with 300 pixels of dead sidebar will still waste bytes after conversion, because AVIF compresses pixels; it doesn’t decide which pixels should exist. If the UI text is tiny, crop tighter first and keep the grid honest.
Also check the file size before doing anything fancy. Chrome’s Lighthouse documentation ignores modern-format savings below 8 KiB, which is a useful gut check: if your PNG is already under that line, conversion may be cleanup theatre rather than performance work.
I learned this the annoying way while prepping help-center screenshots. The big dashboard capture shrank hard. The tiny settings icon did not. Sort of. The catch is that the icon looked worse after conversion, so the PNG stayed.
If the PNG still looks heavy after cropping, move to a browser converter. For a direct handoff, use an AVIF converter and keep the original file in your project folder.
Convert the screenshot to AVIF in the browser
The clean browser workflow is simple: upload the cropped PNG, convert it to AVIF, download the result, then compare both files at 100% zoom before publishing. Don’t judge a screenshot from the thumbnail.
For UI captures, I usually put the PNG and AVIF side by side and inspect three places: small text, one-pixel borders, and flat brand color blocks. AVIF can nail these, but aggressive settings can smear counter-forms in letters like e, a, and g.
Araluma’s format converter is handy when you’re not sure which format you need yet. The downside: it is one-file-at-a-time, so a folder of 80 documentation screenshots still wants a batch pipeline or a build step.
If your screenshot has transparent UI elements, read this guide before flattening anything. AVIF can carry transparency, but your CMS, social preview tool, or old email client may still handle PNG more predictably.
Pick AVIF settings that do not blur UI text
For screenshots, use quality as a readability control, not as a vanity slider. Lower the AVIF quality until the file gets meaningfully smaller, then stop the moment labels, icons, and hairline dividers start to look soft.
Screenshots are not camera photos. A little blur in a portrait can pass; blur in a settings screen makes the whole image feel cheap. My test image was deliberately flat, with large blocks of color and placeholder text, so AVIF had an easy job. Real SaaS dashboards are messier (which is where the inspection step earns its keep).
I like three checkpoints:
- Open the AVIF at 100%.
- Zoom to 200% for small UI labels.
- Compare the file size against the cropped PNG.
If the AVIF is only 3 KB smaller and the text looks softer, skip it. If it cuts 60% or more and the text still reads cleanly, ship it. For pages where image weight affects Core Web Vitals, pair this with a speed audit and look at the page, not just the asset.
When the screenshot is a photographic UI, like a product card with a real shoe photo inside it, AVIF often does better than PNG. When it’s a flat chart with four colors and sharp type, a tuned PNG or WebP may be close enough. That’s not a failure. It’s format fit.
Keep a PNG or WebP fallback for older viewers
AVIF support is broad in 2026, but it is not universal. Can I Use listed 93.42% global AVIF support when I checked this on June 18, 2026, which is strong enough for most blogs and product pages but not a blank check.
MDN’s guidance is still sensible: serve AVIF, but keep a fallback for browsers or surfaces that don’t understand it. In a hand-coded page, that usually means a picture element with AVIF first and PNG or WebP after it. In a CMS, it may mean uploading both formats and letting the theme pick.
If you already have a WebP workflow, don’t rip it out just because AVIF is newer. Use WebP fallback as the fallback path, then save AVIF for the primary web image when it wins the size check.
This matters for screenshots sent outside your site too. Slack, Discord, Gmail, Outlook, and older project-management tools don’t all preview AVIF with the same grace. For attachments, PNG still travels better; for a blog page, AVIF usually earns the extra step.
Use AVIF for blog screenshots, not every tiny icon
The best use case is a screenshot that sits inside a post, help article, landing page, or changelog, especially when the page has several UI captures stacked in a tutorial. One converted file is nice; six converted files can change how the page feels on mobile.
The 2025 Web Almanac reported median mobile home pages at 911 KB of images and mobile inner pages at 354 KB. Those numbers are not a personal guilt trip, but they explain why image work pays off. Screenshots pile up quietly.
For broad format choices, keep a format guide nearby. PNG is still the source format I trust for crisp UI captures. AVIF is the delivery format I test when page weight matters. WebP sits in the middle and wins when support friction matters more than the last few kilobytes.
If the screenshot is too large in dimensions, resize before conversion with Araluma Compress or a native editor. Compressing a 3000-pixel-wide dashboard for a 760-pixel content column is backwards (the browser still has to decode the oversized image). Fix the dimensions first, then the format.
And if you ever need to edit the image again, go back from the web copy to the source PNG, not the AVIF. The WebP workflow follows the same rule, and the reverse case is covered in an editing fallback when an editor rejects the modern file.
Use AVIF when the screenshot is visible, repeated, and heavier than it needs to be. Keep PNG for the master. Keep WebP around when compatibility is the job. Next dashboard screenshot you publish, run that three-file check: PNG source, AVIF web copy, fallback. Thirty seconds, maybe less.
