WebP vs AVIF vs JPEG: który format obrazu wybrać w 2026?

TL;DR. AVIF jest 20–30% mniejszy od WebP i 30–50% mniejszy od JPEG. WebP jest mniej więcej 25–35% mniejszy od JPEG. AVIF koduje 5–20× wolniej niż WebP, a WebP dekoduje najszybciej z całej trójki. Sensowny układ na 2026: serwować w pierwszej kolejności AVIF, potem fallback do WebP, a JPEG zostawić jako uniwersalną siatkę bezpieczeństwa. Wybór formatu oddać przeglądarce poprzez element <picture>.

Ta odpowiedź wystarczy większości czytelników. Ciekawsze pytanie brzmi, kiedy nie sięgać po AVIF. Można go pominąć przy ciasnych budżetach CI, gdzie czas kodowania liczy się bardziej niż bajty. Można go odłożyć przy uploadach użytkowników w czasie rzeczywistym, ponieważ kodowanie AVIF po stronie przeglądarki wciąż jest niespójne. JPEG zostaje formatem podstawowym, jeśli trzeba wspierać iOS 16.0–16.3 lub starsze wersje Edge w środowisku produkcyjnym. Wszędzie indziej AVIF wygrywa rozmiarem pliku, o ile znaczniki <picture> są poprawne, a CDN wysyła właściwy typ MIME.

Reszta tego poradnika to praktyka: liczby wsparcia w 2026, benchmark na realnym zdjęciu, drzewo decyzyjne według zastosowania, gotowe do wklejenia wzorce <picture>, polecenia konwersji oraz cztery pułapki, które kosztują zespoły czas. Jeżeli chcesz od razu zająć się konwersją, darmowy kompresor obrazów obsługuje JPEG, PNG, WebP i AVIF w przeglądarce, bez przesyłania plików.

1. Wsparcie przeglądarek w 2026: WebP na 97%, AVIF na 93%

Dwa i pół roku po tym, jak Edge dostarczył AVIF, luka we wsparciu zwęziła się do kilku procent globalnego ruchu. Pytanie nie brzmi już „czy jest wspierany”, a raczej „co serwujemy ostatnim 3%?”.

1.1 WebP: bezpieczne ustawienie domyślne

WebP trafił do Chrome jeszcze w 2012 roku, do Firefox 65 (2019), Edge 18 (2018) i Safari 14 (2020). Według stanu na maj 2026, caniuse szacuje globalne wsparcie na mniej więcej 97%. WebP awansował z „nowoczesnej alternatywy” do „realnego fallbacku”. Jeżeli serwowany jest jeden format inny niż JPEG, jest nim WebP.

1.2 AVIF: można już używać jako format podstawowy

AVIF pojawił się w Chrome 85 (sierpień 2020) i w Firefox 93 (październik 2021). Safari 16.4 włączyło go na macOS i iOS w marcu 2023. Edge zostawał z tyłu i dodał wsparcie dekodowania dopiero w wersji 121 (styczeń 2024). Globalne pokrycie w maju 2026 wynosi mniej więcej 93–95%.

Jedna ostra krawędź warta odnotowania: iOS 16.0–16.3 ma znany błąd dekodowania AVIF, który może wywołać awarię Safari na pewnych obrazach. Te wydania wciąż żyją na urządzeniach blokowanych przez korporacyjne MDM, więc AVIF bez działającego fallbacku WebP lub JPEG to realne ryzyko awarii. Lepiej go traktować jako „podstawowy z polisą”, a nie „podstawowy w pojedynkę”.

1.3 Szybka tabela kompatybilności

Format	Globalne wsparcie (maj 2026)	Kluczowe ograniczenie
JPEG	100%	Największe pliki; brak przezroczystości; brak HDR
WebP	~97%	Brak HDR ani 10-bitowego koloru
AVIF	~93–95%	Wolne kodowanie; błąd dekodowania w iOS 16.0–16.3; wymaga Edge 121+

2. Kluczowe różnice: kompresja, prędkość, funkcje

2.1 Skuteczność kompresji na realnym zdjęciu

Jeden benchmark z tego samego źródła. Pejzaż w rozdzielczości 4000×3000, oryginalny PNG mniej więcej 24 MB, ponownie zakodowany przy percepcyjnie dopasowanej jakości:

Kodowanie	Rozmiar	Względem JPEG (baseline)
JPEG q75 (mozjpeg)	~2,1 MB	0% (baseline)
WebP q75 (libwebp)	~1,4 MB	33% mniejszy
AVIF q60 (libavif, cpu-used 4)	~1,0 MB	52% mniejszy

AVIF q60 jest tutaj wizualnie równoważny JPEG q80 i WebP q75. Skale jakości nie są wymienne między kodekami. Ponowne kodowanie „JPEG q75 do AVIF q75” to klasyczny błąd początkującego: efektem jest przewymiarowany AVIF wyglądający identycznie jak źródło.

2.2 Prędkość kodowania: podatek 5–20×

AVIF kompresuje mocniej, bo wykonuje więcej pracy. Przy domyślnym cpu-used 4 w libavif obraz 4000×3000 zajmuje 5–20× więcej czasu niż w libwebp i mniej więcej 50× więcej niż w mozjpeg. Ten koszt narasta w buildach CI, na zimnych startach Lambdy oraz w pipeline’ach, które ponownie kodują tysiące zasobów.

Dwa wentyle bezpieczeństwa. Pierwszy: cavif --speed 9 (lub libavif cpu-used 9) mieści się w 3× czasu libwebp kosztem 5–8% większych plików. Drugi: agresywne cachowanie. Pipeline zasobów adresowany treścią, który pomija ponowne kodowanie niezmienionych źródeł, zamienia wolny kodek w jednorazowy koszt.

2.3 Głębia koloru i HDR

JPEG i WebP zatrzymują się na 8-bitowym sRGB. AVIF natywnie obsługuje 10- i 12-bitowy kolor, Rec. 2020, DCI-P3 oraz funkcje przenoszenia PQ/HLG. Dla miniatur HDR wideo, profesjonalnych galerii fotograficznych albo wydruków próbnych po stronie przeglądarki AVIF jest dziś jedyną ustandaryzowaną opcją.

2.4 Przezroczystość i animacja

JPEG nie ma żadnej z nich. WebP i AVIF wspierają zarówno alpha, jak i animację. Jako zamiennik przezroczystego PNG, AVIF koduje kanał alpha zwięźlej: ilustracja UI, która kurczy się o 30–40% w WebP, w AVIF często chudnie o 50–70%.

3. Drzewo decyzyjne: który format do którego zadania

3.1 Witryny statyczne: blogi, strony marketingowe, dokumentacja

AVIF jako podstawa, WebP jako fallback, JPEG jako siatka bezpieczeństwa. Kodowanie odbywa się raz w CI, więc podatek 5–20× płaci się czasem buildu, nie czasem użytkownika. To kanoniczny przypadek wzorca <picture> z trzema źródłami z sekcji 4.

3.2 Uploady użytkowników: awatary, UGC, załączniki formularzy

Kompresja do WebP w przeglądarce, ponowne kodowanie do AVIF asynchronicznie na serwerze. canvas.toBlob('image/avif') po stronie przeglądarki działa dziś tylko w Chrome 99+, więc AVIF nie może być ścieżką uploadu. WebP kompresuje się szybko w przeglądarce i oszczędza pasmo na samym uploadzie.

Jeśli chcesz dokładniej porównać biblioteki client-side (Squoosh, browser-image-compression, Compressor.js) i to, jak łączą się z Sharpem lub Imageminem po stronie serwera, zerknij do bratniego poradnika kompresji obrazów: przeglądarka vs Node.js. Wybór formatu i miejsce przetwarzania to osie ortogonalne; ten poradnik pokrywa oś formatu.

3.3 HDR i fotografia o wysokiej wierności

Tylko AVIF. Nic innego w otwartym stosie webowym nie wspiera dziś 10- ani 12-bitowego koloru. Dla zasobów wyłącznie HDR pominąć fallback albo zaakceptować, że fallback JPEG będzie SDR.

3.4 Audytoria z dużym udziałem starszych przeglądarek

JPEG jako podstawa, WebP opcjonalnie, bez AVIF. Portale rządowe, niektóre wschodnioazjatyckie środowiska korporacyjne oraz narzędzia B2B z długimi ogonami urządzeń niekiedy pokazują w analityce 5–10% ruchu z IE czy starego Edge. WebP jest już bezpieczny, AVIF jeszcze nie.

3.5 Dostarczanie z CDN w czasie rzeczywistym

Po stronie serwera libvips lub Sharp strumieniujący WebP, z AVIF generowanym w workerze w tle i serwowanym przy trafieniu w cache. Nie blokować odpowiedzi kodowaniem AVIF. Cloudflare Polish, Vercel Image Optimization oraz Cloudinary f_auto automatyzują ten wzorzec.

4. Fallback `<picture>` zrobiony jak należy

Element <picture> istnieje właśnie po to, by przeglądarka mogła wybrać najlepsze wspierane źródło. Trzy warstwy, wymienione z AVIF na czele, dają optymalny budżet bajtów bez psucia się na starszych klientach.

4.1 Trzywarstwowy baseline

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg"
       width="1200" height="800"
       alt="Górski krajobraz o zachodzie słońca"
       loading="lazy" decoding="async" />
</picture>

Trzy rzeczy do podkreślenia. Przeglądarka idzie po elementach <source> z góry na dół i wybiera pierwszy, którego type rozumie; reszta jest ignorowana, nie jest pobierana. Tag <img> to faktycznie renderowany element i dziedziczy atrybuty (alt, sizes, klasy) niezależnie od tego, które źródło wygra. A width/height na <img> w 2026 roku nie są opcjonalne, rezerwują miejsce i zapobiegają Cumulative Layout Shift.

Dla obrazów nad linią załamania (above-the-fold) trzeba zamienić loading="lazy" na loading="eager" fetchpriority="high". Lazy-loading obrazu LCP bywa jednym z najczęstszych potknięć Core Web Vitals.

4.2 Responsywność plus format: pełny wzorzec

Gdy potrzebne są też responsywne rozdzielczości, srcset powtarza się w każdym <source>:

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Górski krajobraz o zachodzie słońca"
       loading="lazy" decoding="async" />
</picture>

Tak, to dziewięć wygenerowanych plików na każdy obraz. Krok buildu jest na tej skali nieuniknioną koniecznością; sekcja 5.3 pokazuje, co podpiąć.

4.3 Negocjacja `Accept` po stronie serwera jako alternatywa

Jeśli CDN to wspiera, content negotiation zwija znaczniki do pojedynczego tagu <img>. Przeglądarka wysyła Accept: image/avif,image/webp,image/apng,*/*, a CDN odpowiada najlepszym wspieranym formatem pod tym samym URL.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto oraz CloudFront z Lambda@Edge: wszystkie to implementują. Kompromis: mniejszy HTML i jeden URL na obraz, ale uzależnienie od CDN i trudniejszy debugging lokalny. Użyteczny podział to negocjacja CDN dla stron marketingowych i jawny <picture> dla UI produktu, gdzie liczy się deterministyczne zachowanie.

5. Jak konwertować obrazy między formatami

5.1 W przeglądarce, bez uploadu

Najszybsza ścieżka dla pojedynczej konwersji lub małej paczki to wyłącznie przeglądarka. Wystarczy upuścić JPEG w darmowym kompresorze obrazów, wybrać WebP lub AVIF jako wyjście, a plik nigdy nie opuści maszyny. Wejściowy AVIF jest wspierany wszędzie; wyjściowy AVIF używa natywnego enkodera przeglądarki w Chrome 85+ i transparentnie spada do WebP w przeglądarkach, które jeszcze nie potrafią kodować AVIF.

5.2 Wiersz poleceń dla pipeline’ów buildu

Dla pipeline’u produkcyjnego potrzebne jest deterministyczne wyjście i powtarzalne buildy. Te trzy polecenia są realne:

# AVIF: cavif (Rust, łatwa instalacja przez cargo lub brew)
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP: cwebp (oficjalne libwebp od Google)
cwebp -q 75 -m 6 input.jpg -o output.webp

# Oba, plus resize, przez libvips (najszybszy w paczkach)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed przebiega od 0 (najwolniejsze, najmniejsze) do 10 (najszybsze, największe). Domyślne 4 to słodki punkt dla nocnych buildów; 9 sprawdza się przy podglądach PR, gdzie prędkość bije bajty.

5.3 Integracja z pipeline’em buildu

Większość frameworków statycznych już owija te enkodery. Wybrać ten, który pasuje do stosu.

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// Programowo — Sharp (Node.js)
import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600 })
  .avif({ quality: 60, effort: 4 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 75, effort: 6 })
  .toFile('output.webp');

Dla maleńkich zasobów (ikony poniżej około 5 KB, awatary inline, nagłówki maili) można pominąć sieć i osadzić jako data URI przy użyciu kodowania Base64. To zamienia żądanie HTTP na kilka dodatkowych bajtów HTML i zwykle daje wygraną przy rozmiarach poniżej ~5 KB.

Jeżeli wybierasz między bibliotekami kompresji client-side a Node-side (Sharp vs Squoosh vs browser-image-compression), poradnik kompresji obrazów: przeglądarka vs Node.js wchodzi głębiej w benchmarki i kompromisy.

6. Pułapki i nieporozumienia

6.1 „AVIF zawsze wygrywa” — nieprawda dla zrzutów ekranu i grafiki liniowej

Mocną stroną AVIF są fotografie ciągłotonalne. Na zrzutach ekranu z ostrym tekstem, na zrzutach UI i pixel arcie WebP często produkuje mniejsze pliki przy równoważnej jakości. Deblocking w AVIF potrafi wprowadzać subtelne pasy (banding) na płaskich obszarach koloru. Trzeba wykonać konwersje w obie strony i wybrać zwycięzcę dla każdej klasy zasobów.

6.2 „Bezstratne WebP idealnie zastępuje przezroczyste PNG” — blisko, ale nie identycznie

Bezstratne WebP jest naprawdę mniejsze niż PNG, zwykle o około 26%. Haczyk: „bezstratność” dotyczy skompresowanego obrazu, ale enkoder wciąż może modyfikować zaokrąglenie kanału alpha w obszarach o silnych gradientach. Dla pikselowo dokładnej reprodukcji (obrazowanie medyczne, zasoby archiwalne, cokolwiek, co prawnie musi pasować do źródła) zostawić PNG. Dla całej reszty bezstratne WebP to czysty zysk.

6.3 „Wystarczy wgrać pliki .avif” — twoje CDN może nie wiedzieć, co to jest

Starsze konfiguracje nginx i Apache są starsze niż AVIF. Jeśli /etc/nginx/mime.types nie zawiera image/avif avif;, nginx serwuje AVIF jako application/octet-stream. Przeglądarka widzi błędny Content-Type, odmawia renderowania obrazu i po cichu spada do JPEG, co niweczy całą optymalizację. Po deployu wystarczy curl-em odpytać URL zasobu i sprawdzić nagłówek Content-Type. Pięć sekund paranoi oszczędza tydzień „dlaczego AVIF jest zepsuty na produkcji”.

6.4 Awaria AVIF w iOS 16.0–16.3

Niektóre pliki AVIF wywołują awarię dekodowania w Safari na iOS 16.0–16.3. Błąd jest naprawiony w 16.4 (marzec 2023), ale korporacyjne MDM oraz powolne aktualizacje OEM trzymają starsze urządzenia przy życiu. Mitygacja: nigdy nie wysyłać AVIF bez działającego źródła WebP w tym samym <picture> i nigdy nie ustawiać AVIF bezpośrednio jako src w <img>. Stosowanie wzorców z sekcji 4 już chroni.

7. Ściąga 2026

Scenariusz	Format podstawowy	Fallback	Enkoder
Statyczne strony marketingowe	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp w CI
Wpisy bloga i dokumentacja	WebP q75	JPEG q80	darmowy kompresor obrazów (ręcznie) lub Sharp (build)
Uploady użytkowników	WebP (client-side)	JPEG (przeglądarka bez kodowania WebP)	browser-image-compression + Sharp po stronie serwera dla AVIF
HDR / fotografia profesjonalna	AVIF 10-bit q70	(brak — odrzucić fallback SDR albo całkowicie pominąć AVIF)	cavif + tryb HEIF libavif
Dostarczanie z CDN w czasie rzeczywistym	Negocjowane (AVIF lub WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Dwa przypomnienia przed wysyłką. Zawsze ustawiać width i height na <img>, żeby zapobiec CLS. Zawsze weryfikować produkcyjny nagłówek Content-Type na co najmniej jednej odpowiedzi AVIF; popsuta konfiguracja MIME po cichu zabija AVIF na produkcji częściej niż jakakolwiek inna usterka z tej listy.

FAQ

Czy w 2026 wciąż potrzebny jest fallback JPEG?

Tak. AVIF dociera do mniej więcej 93% globalnych użytkowników, a WebP do około 97%. Pozostawia to małą, ale realną populację (stary Edge, Firefox poniżej 93, iOS sprzed 16.4, plus strefa błędu iOS 16.0–16.3), która potrzebuje JPEG. JPEG porzucić tylko wtedy, gdy analityka pokazuje praktycznie zerowy ruch z tych przeglądarek i da się to udowodnić.

Jak utrzymać szybkie buildy CI, skoro kodowanie AVIF jest wolne?

Trzy dźwignie. Użyć cavif --speed 6 lub wyższego (domyślnie 4), żeby wymienić ~5% rozmiaru na ~3× prędkość. Zrównoleglić na rdzeniach przez GNU parallel albo pulę workerów narzędzia buildu. Cachować po hashu treści, żeby niezmienione obrazy źródłowe całkowicie omijały enkoder. Połączone, te trzy techniki zwykle skracają czas buildu AVIF poniżej dawnego, jednowątkowego baseline’u WebP.

Czy dekodowanie WebP jest naprawdę szybsze niż AVIF?

Tak. libwebp dekoduje mniej więcej 2–3× szybciej niż libavif, a luka rośnie na słabszym sprzęcie mobilnym. Jeżeli wąskim gardłem wydajności jest dekodowanie (np. długa galeria obrazów na budżetowym Androidzie), a nie sieć, WebP jest lepszym formatem podstawowym. Dla większości ruchu webowego dominują oszczędności na sieci i AVIF i tak wygrywa ogólnie.

Czy użytkownicy iPhone’a widzą AVIF?

iPhone’y z iOS 16.4 (marzec 2023) lub nowszym wspierają AVIF natywnie w Safari. Urządzenia na iOS 16.0–16.3 mają udokumentowany błąd dekodowania, który może wywołać awarię Safari na pewnych plikach AVIF; starsze wersje iOS w ogóle nie wspierają AVIF. Zawsze wysyłać fallback WebP lub JPEG wewnątrz <picture>, żeby dotknięci użytkownicy cokolwiek zobaczyli.

Używać `<picture>` czy negocjacji nagłówkiem Accept?

Mniejsze projekty zyskują na jawnych znacznikach <picture>: zachowanie jest deterministyczne, można debugować lokalnie, a koszt to może 80 bajtów HTML na obraz. Witryny o dużym ruchu wygrywają z negocjacją Accept po stronie CDN: jeden URL na obraz, automatyczne aktualizacje formatu, a CDN cachuje każdy format osobno. Częsta hybryda to <picture> w UI aplikacji i negocjacja CDN dla zasobów marketingowych.

Dlaczego mój PNG urósł po konwersji do WebP?

Prawie zawsze dlatego, że źródłowy PNG był już agresywnie zoptymalizowany przez pngquant, oxipng albo ZopfliPNG, a oparty na Canvas enkoder przeglądarki nie dorównuje tym narzędziom. Ponownie zakodować z oryginału (eksport z Photoshopa, master z narzędzia projektowego, RAW), a nie z zoptymalizowanego PNG. Jeśli zoptymalizowany PNG to jedyne źródło, oryginał jest już blisko optimum, więc zostawić go w spokoju.

Czy AVIF wspiera przezroczystość?

Tak. AVIF wspiera pełny kanał alpha o 8- do 12-bitowej głębi, a jego kodowanie alpha jest na ogół zwięźlejsze niż w WebP. Przezroczysta ilustracja PNG przekonwertowana do AVIF zwykle kurczy się o 50–70%, podczas gdy w WebP o 30–40%. AVIF jest najmocniejszym zamiennikiem przezroczystego PNG w każdym kontekście, który nie wymaga pikselowo dokładnego, bezstratnego wyjścia.

Czy przeglądarki mogą natywnie kodować AVIF przez `toBlob('image/avif')`?

Na razie tylko Chrome 99+. Safari i Firefox potrafią dekodować AVIF, ale na maj 2026 nie kodują go przez API Canvas. Do kodowania AVIF po stronie klienta trzeba dziś użyć bibliotek WebAssembly w stylu libavif-wasm albo jsquash, które dokładają 1–2 MB payloadu. Większość stosów produkcyjnych kompresuje w przeglądarce do WebP i zrzuca generowanie AVIF na workera serwerowego.