DEV Community: Serhii Kalyna

AVIF in 2026: why it's the best format for web images

Serhii Kalyna — Thu, 02 Apr 2026 16:30:31 +0000

AVIF has been available since 2020, but it's only in 2026 that it became the obvious default choice for web images. Browser support crossed 94.9%, Google officially recommends it in PageSpeed Insights, and the compression advantages over JPG are too large to ignore. Here's what you need to know.

What is AVIF?

AVIF (AV1 Image File Format) is an image format developed by the Alliance for Open Media — a consortium that includes Google, Apple, Mozilla, Microsoft, and Netflix. It uses the AV1 video codec to compress images, which is why it achieves compression rates that traditional image codecs like JPG can't match.

AV1 was designed for video — it's optimized for the kind of complex, natural content that appears in photos and real-world scenes. When you use it for a single image frame instead of a video stream, you get dramatically better compression than JPG's DCT-based algorithm, which dates back to 1992.

The compression numbers

At equivalent visual quality (measured by SSIM/DSSIM), AVIF consistently beats JPG by 40–60%:

Format	File size vs JPG	Browser support
JPG	Baseline	All browsers & apps
WebP	~30% smaller	95.67%
AVIF	~50% smaller	94.9%
JPEG XL	~45% smaller	14.7% (Safari only)

A real example from my own testing with libvips:

JPEG (q80): 540 KB
WebP: 350 KB (−35%)
AVIF: 210 KB (−61%)

That's not a cherry-picked example — Netflix's internal benchmarks across a diverse image dataset showed AVIF achieving ~50% better compression than JPG on average.

Why AVIF wins over WebP in 2026

WebP was Google's previous recommendation and it's still a solid format. But AVIF has caught up in browser support (94.9% vs 95.67%) while delivering meaningfully better compression.

The gap matters at scale. If you have 1,000 product images averaging 400 KB as JPG:

WebP: ~270 KB each → 270 MB total
AVIF: ~200 KB each → 200 MB total

That's 70 MB less bandwidth per 1,000 images served. For high-traffic sites, this compounds into significant CDN cost savings and faster page loads.

Core Web Vitals impact

Largest Contentful Paint (LCP) measures how quickly the main image on a page loads. It's a Google ranking signal and one of the Core Web Vitals metrics.

Large images are the most common cause of poor LCP scores. Switching from JPG to AVIF typically reduces image payload by 40–60%, directly improving LCP. Google's PageSpeed Insights will flag JPG images as a performance opportunity and explicitly recommend AVIF as the preferred replacement.

For e-commerce sites where product images are the LCP element, converting to AVIF is the highest-impact single change for page performance.

Browser support in 2026

AVIF achieved Baseline status in 2024:

Chrome 85+ (2020)
Firefox 93+ (2021)
Safari 16+ (2022)
Edge 121+ (2024)

The ~5% without support is primarily legacy mobile browsers and Internet Explorer. For most sites, you can serve AVIF as the primary format with a JPG fallback using the HTML <picture> element:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="description">
</picture>

Browsers download only the first format they support.

The encoding speed problem

AVIF's biggest practical limitation is slow encoding. While JPG encodes in ~2ms and WebP in ~168ms, AVIF takes 1–2 seconds per image with the libaom reference encoder.

This makes real-time AVIF encoding impractical for user-uploaded content without a job queue. For static assets (product photos, blog images, landing page assets), encode offline during your build process and serve the pre-encoded AVIF files.

Alternative encoders help:

rav1e — faster than libaom, slightly larger files
SVT-AV1 — good balance of speed and compression

In my Rust + libvips backend for Convertify, I use libvips's built-in AVIF support which wraps libaom. For batch conversion of user files, the encoding time is acceptable. For real-time conversion of large files, it's a constraint worth planning around.

AVIF transparency and animation

Unlike JPG, AVIF supports full alpha channel transparency. This makes it a potential replacement for PNG in web contexts — smaller files with the same transparency support.

AVIF also supports animation, making it an alternative to GIF. Animated AVIF files are significantly smaller than GIF while supporting a full color range (GIF is limited to 256 colors).

What about JPEG XL?

JPEG XL (JXL) is technically superior to AVIF in some dimensions:

Better compression at high quality settings (~20% smaller than AVIF)
Progressive decoding (shows usable image with 1% of data loaded)
Lossless JPEG transcoding (20% smaller, byte-perfect reconstruction)

The problem is browser support: 14.7% as of early 2026, limited to Safari 17+.

The big news: Chrome Canary 145 shipped a Rust-based JXL decoder in late 2025, reversing Google's 2022 decision to remove JXL support. Realistic stable Chrome support: H2 2026.

My recommendation: Use AVIF now. Watch JXL for H2 2026 when Chrome stable support arrives. Don't wait.

Practical implementation

For static sites: Convert during build. Store both AVIF and JPG. Use <picture> for fallback.

For CDNs: Cloudflare, Cloudinary, and Imgix serve AVIF automatically via Accept header negotiation. Upload once, let the CDN handle format selection.

For Next.js: The <Image> component serves AVIF automatically for supported browsers since Next.js 13.

For WordPress: ShortPixel, Imagify, and WebP Express all support AVIF conversion.

For manual conversion: Tools like Convertify handle batch AVIF conversion without requiring local tooling.

Summary

AVIF is the right default for web images in 2026:

✅ 94.9% browser support — effectively universal with JPG fallback
✅ ~50% smaller than JPG at the same quality
✅ Recommended by Google PageSpeed Insights
✅ Transparency and animation support
⚠️ Slow encoding — plan around it for real-time use cases
⚠️ Limited app support outside browsers

The implementation is straightforward. The performance gains are significant. There's no good reason to keep shipping JPG for web images in 2026.

Why I added internal linking to my image converter (and what changed in Google)

Serhii Kalyna — Tue, 31 Mar 2026 17:11:48 +0000

I've been building Convertify — a free image converter powered by Rust + libvips. Two weeks in, Google had indexed 18 of my 186 static pages. The numbers were moving, but slowly.
Then I read a recommendation that changed my approach: internal linking is 80% of cluster SEO.

The problem

My converter pages existed in isolation. /heic-to-jpg had no idea /heic-to-png existed. Google couldn't see a cluster — just a collection of unrelated tools.

What I built

A RelatedConversions component that generates contextual links on every page:

const RELATED: Record<string, string[]> = {
  heic: ["jpg", "png", "webp", "avif"],
  avif: ["jpg", "png", "webp", "heic"],
  // ...
};

export default function RelatedConversions({ from, to }) {
  // generates links like "HEIC to PNG", "WEBP to JPG" etc.
  // deduplicates, shows related formats from both source and target
}

On the homepage — "Popular Conversions". On converter pages — "Related Conversions". Every page now links to 6-8 related pages.

The immediate result

Deployed on day 15. The same day I submitted the key pages for re-indexing in Search Console.
Within 24 hours Google crawled the updated pages. The internal links give Googlebot a clear path through the entire site — it no longer needs to discover pages through the sitemap alone.

What's next

Still too early to see ranking changes — SEO takes weeks. But the site now looks like a cluster to Google, not a collection of isolated tools. That's the foundation for ranking multiple pages simultaneously for the same search query.

Stats so far (week 3, day 2):

18 pages indexed (up from 2 three weeks ago)

Building in public. Follow along if you're curious how Rust + Next.js SSG performs for SEO.

Building Convertify in public. Previous posts:

AVIF converter: why I built one and what I learned

Serhii Kalyna — Mon, 23 Mar 2026 16:04:29 +0000

Large images slow down websites, frustrate users, and hurt SEO. Modern formats like AVIF promise smaller sizes with better quality, but the ecosystem is still young. I decided to explore AVIF and build my own converter to see what works in practice.

Why AVIF

AVIF images can be 50–70% smaller than JPEG or PNG at similar or better visual quality. This means faster loading times, lower bandwidth, and improved PageSpeed scores. Yet, support for AVIF in editing tools and converters is still limited, which makes it hard for developers and content creators.

Why I built my own converter

Existing tools are either slow, require file uploads (privacy concerns), or are paid. I wanted a converter that is fast, privacy-first, and free. That led me to create Convertify.

Tech stack

Rust for performance-critical processing
libvips as a high-speed image processing backend
Next.js SSG for static landing pages and SEO

Challenges

AVIF encoding is slower than JPEG/PNG
Browser compatibility is still patchy
UX: making drag & drop intuitive without blocking the main thread

Results

Conversion speed improved significantly with Rust + libvips
PageSpeed scores for test pages increased
Early users appreciated privacy-first, instant conversion

Conclusion

AVIF adoption will grow as tools improve. Building your own converter is a great way to learn about modern image formats and get early traction. Check out a quick AVIF-to-JPG demo Convertifyapp.

How I fixed Google ignoring 160 pages: migrating from Vite SPA to Next.js SSG

Serhii Kalyna — Sat, 21 Mar 2026 17:59:51 +0000

How I fixed Google ignoring 160 pages: migrating from Vite SPA to Next.js SSG

I've been building Convertify — a free image converter
that supports HEIC, WebP, AVIF, PNG, JPG and 20+ formats.

The problem: after weeks of work, Google had indexed exactly 2 pages out of 160+.

Why Google ignored my pages

My app was a Vite React SPA. Every route looked like this in HTML:

<!DOCTYPE html>
<html>
  <head>
    <title>Convertify</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/assets/index.js"></script>
  </body>
</html>

Google crawls without executing JavaScript. So every single page —
/heic-to-jpg, /webp-to-png, /avif-to-jpg — returned identical empty HTML.
Google saw them all as duplicates and indexed only the homepage.

The fix: Next.js App Router + generateStaticParams

I migrated to Next.js and used generateStaticParams() to pre-render
all format pairs at build time:

export async function generateStaticParams() {
  const formats = ['heic', 'jpg', 'jpeg', 'png', 'webp', 'avif', 'gif', 'bmp', 'tiff']
  const params = []
  for (const from of formats) {
    for (const to of formats) {
      if (from !== to) params.push({ slug: `${from}-to-${to}` })
    }
  }
  return params
}

Result: 186 static HTML pages generated at build time.

Server components for SEO content

The key insight: not everything needs to be a client component.

I split the page into two parts:

Client (interactive): DropZone, Settings, ConvertButton, FilesViewer
Server (static HTML): FAQ, HowToConvert, SupportedFormats, Header, Footer

For server components I replaced MUI Accordion with native HTML <details>/<summary>:

// No 'use client', no JavaScript, pure HTML
const FAQ = ({ from, to }: { from?: string; to?: string }) => {
  return (
    <dl>
      {faqs.map((faq, i) => (
        <details key={i}>
          <summary>{faq.question}</summary>
          <dd>{faq.answer}</dd>
        </details>
      ))}
    </dl>
  )
}

Google gets full FAQ content without running any JavaScript.

Dynamic metadata per page

Instead of react-helmet-async, Next.js handles metadata server-side:

export async function generateMetadata({ params }) {
  const [from, to] = params.slug.split('-to-')
  return {
    title: `Convert ${from.toUpperCase()} to ${to.toUpperCase()} Online Free — Convertify`,
    description: `Free online ${from.toUpperCase()} to ${to.toUpperCase()} converter.`,
    alternates: { canonical: `https://convertifyapp.net/${params.slug}` },
  }
}

Every page now has unique title, description and canonical tag in the HTML
— no JavaScript required.

Results

Before: 2 indexed pages
After: 186 static pages pre-rendered
PageSpeed Desktop: 100/100 Performance, 100/100 SEO
PageSpeed Mobile: 83/100 Performance, 100/100 SEO

The mobile performance hit comes from MUI (emotion) on the client side.
Working on reducing that next.

Lessons learned

SPAs are SEO poison for content pages. Use SSG or SSR.
Split server/client components — only interactive parts need JavaScript.
Native HTML elements (<details>, <summary>) work great for accordions and are fully server-renderable.
generateStaticParams is incredibly powerful for programmatic SEO pages.

If you're building a tool with many landing pages — don't make the same
mistake I did. Start with Next.js from day one.

Check out Convertify if you need to convert
HEIC, WebP, AVIF or any other image format — free, no signup, no limits.

JPEG XL in Chrome 145: what it means for web developers

Serhii Kalyna — Thu, 19 Mar 2026 08:09:10 +0000

Chrome 145 quietly shipped something big: a native JPEG XL decoder. After dropping JXL support in 2022 and years of community pushback, Google reversed course. JXL is now viable in production.

What changed

Before Chrome 145, JPEG XL had only Safari support (~14%). Now with Chrome on board, you're looking at 70%+ coverage overnight. Firefox has JXL in nightly builds. Edge follows Chrome. The holdout is older Chrome versions.

Why JXL is different from AVIF and WebP

	AVIF	WebP	JPEG XL
Compression vs JPEG	~50%	25-34%	35-55%
Encode speed	Slow	Fast	Fast
Lossless	Yes	Yes	Yes
Progressive decode	No	No	Yes
Lossless JPEG recompression	No	No	Yes

The lossless JPEG recompression is unique — you can transcode existing JPEGs to JXL with zero quality loss and ~20% size reduction. No other format can do this.

Should you use JXL today?

For new projects: yes, with a JPEG fallback. The <picture> element handles this cleanly:

<picture>
  <source srcset="image.jxl" type="image/jxl">
  <source srcset="image.avif" type="image/avif">
  <img src="image.jpg" alt="...">
</picture>

For existing projects: wait 6-12 months until Chrome 145+ penetration is high enough.

Tooling support in 2026

The weak point is still encoder tooling. Lightroom and Photoshop don't export JXL natively yet. For now the options are:

cjxl CLI (libjxl reference encoder)
ImageMagick 7.1+
libvips 8.13+
Online converters like Convertify for quick testing

Bottom line

JXL won't replace AVIF for pure compression use cases. But for archival, lossless JPEG migration, and high-quality photography workflows — it's now the best option available in a browser.

The next 12 months will tell if the ecosystem catches up.

AVIF vs WebP vs HEIC vs JPEG XL: which image format should you use in 2026?

Serhii Kalyna — Mon, 16 Mar 2026 19:48:03 +0000

If you've ever wondered whether to use AVIF, WebP, or just stick with JPEG — this is the guide I wish existed when I was building Convertify, a free image converter that handles 20+ formats including all of these.

Let me cut through the noise with actual data.

TL;DR

Format	Lossy savings vs JPEG	Browser support	Best for
AVIF	~50% smaller	94.9%	General web delivery
WebP	25–34% smaller	95.67%	Fallback, simple graphics
JPEG XL	35–55% smaller	14.74% (Safari only)	High quality, archival
HEIC	~50% smaller	12% (Safari only)	Apple ecosystem only

Recommended today: AVIF → WebP → JPEG fallback chain.

Compression: the real numbers

At equivalent visual quality (measured by SSIM/DSSIM):

AVIF — ~50% smaller than JPEG (Netflix research, Ctrl.blog 600-image study)
WebP — 25–34% smaller than JPEG
JPEG XL — 35–55% smaller than JPEG, but 20% smaller than AVIF at high quality (Cloudinary, 40,000+ image test)
HEIC — ~50% smaller than JPEG, but patent issues kill web use

Real example — a 2000×2000 product photo:

JPEG (q80):   540 KB  (baseline)
WebP:         350 KB  (−35%)
JPEG XL:      260 KB  (−52%)
AVIF:         210 KB  (−61%)

AVIF wins at low-to-medium bitrates. JPEG XL wins at high quality. For most web photography, AVIF is the right call.

Encoding speed matters too

This is where AVIF has a real problem:

Format	Encoding time (approx)
JPEG	~2.5 ms
WebP	~168 ms
JPEG XL	~seconds (but fast mode available)
AVIF	1–2+ seconds per image

AVIF is slow to encode. If you're doing batch conversions, you feel this immediately. JPEG XL's encoder was designed for speed — at its default settings it runs ~100× faster than AVIF in throughput while achieving comparable compression.

Decoding matters for users:

JPEG: ~0.39 ms (fastest)
WebP: ~24 ms
AVIF: ~155 ms (5.4× slower than JPEG)
JPEG XL: similar to AVIF, but with progressive decoding — renders usable preview with just 1% of data downloaded

JPEG XL's progressive rendering is a big deal for large hero images on slow connections. Neither WebP nor AVIF can do this at all.

Browser support in 2026

Format	Support	Status
WebP	95.67%	Baseline "Widely Available" since 2020
AVIF	94.9%	Baseline 2024, all major browsers
JPEG XL	14.74%	Safari 17+ only, Chrome Canary 145 behind flag
HEIC	12.03%	Safari 17+ only, no other browser plans

WebP and AVIF are effectively universal. The remaining gaps are legacy browsers — handle them with JPEG fallback.

The big news for JPEG XL: Google reversed its 2022 decision to remove JPEG XL from Chrome. In November 2025, Chrome engineering welcomed a Rust-based decoder contribution. It landed in Chromium Canary 145. Realistic default Chrome support: H2 2026.

HEIC has 12% support entirely from Safari. Chrome, Firefox, Edge — no plans due to HEVC patent complexity. HEIC on the web is dead.

When to use each format

Use AVIF when:

Serving photos, thumbnails, product images
You want the best compression for most visitors
You need animated images (86% smaller than GIF per Google web.dev)

Use WebP when:

You need the universal fallback behind AVIF
Simple graphics, logos, illustrations
You don't have time to think about it

Use JPEG XL when:

Professional photography workflows (already supported in iPhone 16 Pro ProRAW)
You need lossless compression (48% smaller than PNG)
Lossless JPEG transcoding (20% size reduction, byte-perfect reconstruction)
Wait for Chrome stable before shipping to web visitors

Use HEIC when:

You're Apple-only (iPhone, Mac, iPad native apps)
Need to convert for web → convert HEIC to JPG or WebP instantly

What's actually deployed in 2026?

W3Techs data (March 2026):

PNG: 77.7% of websites
JPEG: 72.4%
WebP: 19.4% (1 in 5 sites)
AVIF: 1.3%
JPEG XL: < 0.1%

AVIF usage grew 386% between 2022–2024 but still sits at 1.3%. The gap between "supported" and "deployed" is real. CDN auto-negotiation is the fastest path — Cloudflare, Cloudinary, and Shopify's CDN all serve AVIF automatically without you changing a line of frontend code.

The practical implementation

The <picture> element is still the right approach:

If you're using a CDN — just use Accept header negotiation and let the CDN decide.

If you're converting images manually (e.g. iPhone HEIC photos for web), you can do it in one line with libvips (what I use in Convertify's Rust backend):

vips copy input.heic output.avif

Or just use convertifyapp.net — free, no signup, batch up to 10 files. 😄

What's next: AV2 and the Chrome decision

AV2 was announced by Alliance for Open Media in September 2025 — the next-generation codec that will eventually succeed AVIF. 53% of AOM members plan implementation within 12 months of release. Don't hold off on AVIF waiting for AV2 — that's a 2028+ story.

The format landscape for 2026–2027:

✅ Ship AVIF + WebP fallback now
👀 Watch JPEG XL — Chrome stable target H2 2026
❌ Skip HEIC for web — convert it on upload
🔭 AV2 — 2028+ horizon

Bottom line

AVIF is the best format for most web images in 2026. Implement it with WebP fallback using <picture>. Use a CDN if you can — it handles everything automatically.

If you're dealing with HEIC files from iPhone or need to convert between formats, check out Convertify — I built it specifically because every other converter was slow or required signup.

What format are you using in production? Drop a comment — curious how many teams have made the jump to AVIF.

Built something with image processing? I'm @app.convertify on X.

How I built a free HEIC image converter with Rust + libvips

Serhii Kalyna — Thu, 12 Mar 2026 18:06:11 +0000

How I built a free HEIC image converter with Rust + libvips

I needed a simple tool to convert HEIC photos from iPhone to JPG and WebP.
Most online converters require signup or add watermarks, so I built my own.

Tech stack

Backend: Rust + Axum + libvips
Frontend: React + Vite + MUI
Hosting: VPS with Caddy reverse proxy

The hardest part — HEIC support

Getting HEIC to work was the biggest challenge. The package manager version
of libheif was too old and didn't support newer iPhone photo formats.
I had to build libheif 1.21.2 from source:

cmake -DCMAKE_BUILD_TYPE=Release \
      -DLIBHEIF_ENABLE_PLUGIN_LOADING=ON \
      -DWITH_DAV1D=ON \
      ..
make -j$(nproc)
sudo make install

Why libvips?

libvips is significantly faster than ImageMagick for large files — it streams
pixels through a pipeline without loading the entire image into memory.
For batch conversion of 10 images this makes a real difference.

Privacy

All uploaded files are automatically deleted from the server within 6 hours.
No account required, no watermarks.

Result

Supports 20+ formats: HEIC, HEIF, WebP, PNG, JPG, AVIF, TIFF, BMP, GIF.
Batch convert up to 10 images at once.

Try it: convertifyapp.net

Source code coming soon on GitHub.