WebP vs AVIF vs JPEG: 2026’da hangi görsel formatı kazanır?

Özet: AVIF, WebP’den %20–30, JPEG’den %30–50 daha küçüktür. WebP ise JPEG’den yaklaşık %25–35 daha küçük dosya üretir. AVIF, WebP’den 5–20× daha yavaş kodlanır; buna karşılık WebP üçünün arasında en hızlı çözülen formattır. 2026’nın kazanan iş akışı şudur: önce AVIF sunun, ardından WebP’ye düşün, JPEG’i evrensel güvenlik ağı olarak tutun ve seçimi <picture> öğesi üzerinden tarayıcıya bırakın.

Bu yanıt okurların çoğunu kapsar. Daha ilginç soru, AVIF’ten ne zaman uzak durulacağıdır. Kodlama süresinin baytlardan daha önemli olduğu sıkışık CI bütçelerinde AVIF’i atlayın. Tarayıcı tarafında AVIF kodlaması hâlâ tam oturmadığı için gerçek zamanlı kullanıcı yüklemelerinde geri planda tutun. iOS 16.0–16.3 veya sahadaki eski Edge’i desteklemek zorundaysanız JPEG’i birincil olarak koruyun. Diğer her yerde, <picture> işaretlemeniz doğru ve CDN’iniz uygun MIME türünü gönderdiği sürece, AVIF dosya boyutunda kazanır.

Rehberin geri kalanı işin teknik tarafıdır: 2026 destek rakamları, gerçek bir fotoğraf üzerinde karşılaştırma, kullanım senaryosuna göre karar ağacı, kopyala-yapıştır <picture> örnekleri, dönüştürme komutları ve ekiplere zaman kaybettiren dört tuzak. Sadece dönüştürme işini bitirmek istiyorsanız, ücretsiz resim sıkıştırıcı JPEG, PNG, WebP ve AVIF’i tarayıcıda hiçbir şey yüklemeden işler.

1. 2026 tarayıcı desteği: WebP %97, AVIF %93

Edge’in AVIF’i göndermesinin üzerinden iki buçuk yıl geçti ve destek farkı küresel trafiğin yalnızca birkaç yüzdesine indi. Artık soru “destekleniyor mu” değil, “son %3’e ne sunacağız” oldu.

1.1 WebP: güvenli varsayılan

WebP, 2012’de Chrome’a, 2019’da Firefox 65’e, 2018’de Edge 18’e ve 2020’de Safari 14’e geldi. Mayıs 2026 itibarıyla caniuse küresel desteği yaklaşık %97 gösteriyor. WebP “modern alternatif” sıfatından “uygulanabilir fallback” konumuna terfi etti. JPEG dışında tek bir format sunacaksanız, o WebP olacaktır.

1.2 AVIF: artık birincil format olarak kullanılabilir

AVIF, Chrome 85’e (Ağustos 2020) ve Firefox 93’e (Ekim 2021) geldi. Safari 16.4, Mart 2023’te macOS ve iOS’ta etkinleştirdi. Edge geriden geldi; çözme desteğini ancak 121 sürümünde (Ocak 2024) ekledi. Mayıs 2026’da küresel kapsam yaklaşık %93–95.

Bir keskin köşe var: iOS 16.0–16.3’te bilinen bir AVIF çözme hatası belirli görsellerde Safari’yi çökertebiliyor. Bu yapılar hâlâ kurumsal MDM ile geride tutulan cihazlarda yaşıyor; yani çalışan bir WebP veya JPEG fallback olmadan AVIF gerçek bir kesinti riski taşır. Onu “sigortalı birincil” olarak görün, tek başına birincil olarak değil.

1.3 Hızlı uyumluluk matrisi

Format	Küresel destek (Mayıs 2026)	Ana kısıt
JPEG	%100	En büyük dosyalar; saydamlık yok; HDR yok
WebP	~%97	HDR veya 10 bit renk yok
AVIF	~%93–95	Yavaş kodlama; iOS 16.0–16.3 çözme hatası; Edge 121+ gerekir

2. Temel farklar: sıkıştırma, hız, özellikler

2.1 Gerçek bir fotoğrafta sıkıştırma verimliliği

Aynı kaynaktan tek bir karşılaştırma. 4000×3000 boyutunda bir manzara fotoğrafı, orijinal PNG yaklaşık 24 MB, algısal olarak eşleştirilmiş kalitede yeniden kodlandı:

Kodlama	Boyut	JPEG temeline göre
JPEG q75 (mozjpeg)	~2,1 MB	%0 (temel)
WebP q75 (libwebp)	~1,4 MB	%33 daha küçük
AVIF q60 (libavif, cpu-used 4)	~1,0 MB	%52 daha küçük

Buradaki AVIF q60, görsel olarak JPEG q80 ve WebP q75 ile eşdeğerdir. Kalite ölçekleri kodekler arasında birbirinin yerine kullanılamaz. “JPEG q75’i AVIF q75’e yeniden kodlamak” klasik acemi hatasıdır; sonuçta kaynakla aynı görünen ama gereksiz yere büyük bir AVIF elde edersiniz.

2.2 Kodlama hızı: 5–20× vergi

AVIF daha sıkı sıkıştırır çünkü daha çok iş yapar. libavif’i varsayılan cpu-used 4 ile kullanırsanız, 4000×3000 bir görsel libwebp’den 5–20×, mozjpeg’den ise yaklaşık 50× daha uzun sürer. Bu maliyet CI build’leri, Lambda soğuk başlatmaları ve binlerce varlığı yeniden kodlayan iş akışlarında katlanarak büyür.

İki kaçış vanası var. cavif --speed 9 (veya libavif cpu-used 9), %5–8 daha büyük dosyalar pahasına libwebp’nin 3 katına kadar yaklaşır. Bir de agresif önbellekleme yapın: değişmemiş kaynakları yeniden kodlamayı atlayan, içerik adresli bir varlık iş akışı yavaş bir kodeği tek seferlik bir maliyete dönüştürür.

2.3 Renk derinliği ve HDR

JPEG ve WebP 8 bit sRGB ile sınırlıdır. AVIF, 10 ve 12 bit rengi, Rec. 2020, DCI-P3 ve PQ/HLG transfer fonksiyonlarını dahili olarak işler. HDR video küçük resimleri, profesyonel fotoğraf galerileri veya tarayıcıdaki baskı provaları için bugün standartlaşmış tek seçenek AVIF’tir.

2.4 Saydamlık ve animasyon

JPEG’de hiçbiri yok. WebP ve AVIF, alfa kanalını ve animasyonu destekler. Özellikle saydam PNG yerine geçme konusunda AVIF alfa kanalını daha kompakt kodlar: WebP olarak %30–40 küçülen bir UI çizimi, AVIF olarak çoğu zaman %50–70 küçülür.

3. Karar ağacı: hangi iş için hangi format

3.1 Statik siteler: bloglar, pazarlama sayfaları, dokümanlar

Birincil AVIF, fallback WebP, güvenlik ağı JPEG. Kodlama CI’da bir kez yapılır, dolayısıyla 5–20× vergi build süresinde ödenir, kullanıcı süresinde değil. 4. bölümdeki üç kaynaklı <picture> örüntüsünün kanonik durumu budur.

3.2 Kullanıcı yüklemeleri: avatarlar, UGC, form ekleri

Tarayıcıda WebP’ye sıkıştırın, sunucuda asenkron olarak AVIF’e yeniden kodlayın. Tarayıcı tarafında canvas.toBlob('image/avif') bugün yalnızca Chrome 99+‘da çalışır; bu yüzden AVIF yükleme yolu olamaz. WebP tarayıcıda hızlı sıkışır ve yüklemenin kendisinde bant genişliğinden kazandırır.

İstemci tarafı kütüphanelerin (Squoosh, browser-image-compression, Compressor.js) daha derin karşılaştırması ve sunucu tarafı Sharp veya Imagemin ile nasıl eşleştikleri için kardeş yazıya bakın: resim sıkıştırma rehberi: tarayıcı ile Node.js. Format seçimi ile işleme konumu birbirinden bağımsızdır; bu rehber format eksenini ele alır.

3.3 HDR ve yüksek sadakatli fotoğrafçılık

Yalnızca AVIF. Açık web yığınında bugün 10 veya 12 bit rengi destekleyen başka bir şey yok. HDR’e özel varlıklarda fallback’i atlayın ya da JPEG fallback’inin SDR olacağını kabul edin.

3.4 Eski tarayıcı ağırlıklı kitleler

Birincil JPEG, isteğe bağlı WebP, AVIF yok. Devlet portalları, belirli Doğu Asya kurumsal ortamları ve cihaz kuyruğu uzun olan B2B araçları, bazen analitiklerinde %5–10 IE/eski Edge trafiği gösterir. WebP artık güvenli; AVIF henüz değil.

3.5 Gerçek zamanlı CDN dağıtımı

Sunucu tarafında libvips veya Sharp ile WebP akışı; AVIF arka plan worker’ında üretilip cache hit’inde sunulur. Yanıtı AVIF kodlamasında bloklamayın. Cloudflare Polish, Vercel Image Optimization ve Cloudinary f_auto bu örüntüyü otomatikleştirir.

4. `<picture>` fallback’i, doğru şekilde

<picture> öğesi, tarayıcının desteklenen en iyi kaynağı seçebilmesi için vardır. AVIF en başta listelenen üç katman, eski istemcilerde kırılmadan size en iyi bayt bütçesini verir.

4.1 Üç katmanlı temel

<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ün batımında dağ manzarası"
       loading="lazy" decoding="async" />
</picture>

Burada üç ayrıntı var. Tarayıcı <source> öğelerini yukarıdan aşağıya gezer ve type değerini anladığı ilkini seçer; geri kalanı yok sayılır, indirilmez. <img> etiketi, hangi kaynak kazanırsa kazansın gerçekte render edilen öğedir ve nitelikleri (alt, sizes, sınıflar) miras alır. Ayrıca <img> üzerindeki width/height 2026’da artık isteğe bağlı değildir; yer ayırırlar ve Cumulative Layout Shift’i önlerler.

Görüntü alanının üstünde yer alan görseller için loading="lazy" yerine loading="eager" fetchpriority="high" koyun. LCP görselini lazy-load etmek, Core Web Vitals’ta en sık yapılan kendi ayağına kurşun sıkma hatalarından biridir.

4.2 Duyarlı boyut ile format birlikte: tam örüntü

Duyarlı çözünürlüklere de ihtiyacınız varsa, her <source> içinde srcset’i tekrarlayın:

<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ün batımında dağ manzarası"
       loading="lazy" decoding="async" />
</picture>

Evet, bu görsel başına dokuz üretilmiş dosya demek. Bu ölçekte bir build adımı pazarlık konusu değildir; 5.3’te neyi takabileceğinizi anlatıyoruz.

4.3 Alternatif olarak sunucu tarafı `Accept` müzakeresi

CDN’iniz destekliyorsa, içerik müzakeresi işaretlemeyi tek bir <img> etiketine indirger. Tarayıcı Accept: image/avif,image/webp,image/apng,*/* gönderir ve CDN aynı URL’de desteklenen en iyi formatı yanıt olarak verir.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto ve Lambda@Edge’li CloudFront bunu uygular. Ödün: daha küçük HTML ve görsel başına tek URL, ama CDN bağımlılığı ve daha zor yerel hata ayıklama. Pratikte iyi işleyen bir bölüşüm var: pazarlama sayfaları için CDN müzakeresi, deterministik davranışın önemli olduğu ürün UI’ı için açık <picture>.

5. Görselleri formatlar arası nasıl dönüştürürsünüz

5.1 Tarayıcıda, yükleme olmadan

Tek seferlik veya küçük bir batch için en hızlı yol yalnızca tarayıcıdır. Bir JPEG’i ücretsiz resim sıkıştırıcı içine bırakın, çıktı olarak WebP veya AVIF seçin; dosya makinenizden hiç ayrılmaz. AVIF girişi her yerde desteklenir; AVIF çıkışı Chrome 85+‘da yerel tarayıcı kodlamasını kullanır ve henüz AVIF kodlayamayan tarayıcılarda dahili olarak WebP’ye düşer.

5.2 Build iş akışları için komut satırı

Üretim iş akışında deterministik çıktı ve yeniden üretilebilir build’ler istersiniz. Pratikte işinize yarayacak üç komut:

# AVIF: cavif (Rust, cargo veya brew ile kolay kurulum)
cavif --quality 60 --speed 4 input.jpg -o output.avif

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

# İkisi de + yeniden boyutlandırma, libvips üzerinden (toplu işlemde en hızlısı)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed 0’dan (en yavaş, en küçük) 10’a (en hızlı, en büyük) kadar çalışır. Varsayılan 4, gecelik build’ler için tatlı noktadır; hızın baytları yendiği PR önizlemelerinde 9’a çıkarın.

5.3 Build iş akışı entegrasyonu

Çoğu statik site çatısı bu kodlayıcıları zaten sarmalar. Yığınınıza uyanı seçin:

// 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' },
  },
});

// Programatik — 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');

Çok küçük varlıklar için (yaklaşık 5 KB’tan küçük ikonlar, satır içi avatarlar, e-posta başlıkları) ağı tamamen atlayın ve Base64 kodlama ile bir data URI olarak gömün. Böylece bir HTTP isteğini birkaç ek HTML baytıyla takas etmiş olursunuz; genelde ~5 KB altında bu net bir kazançtır.

İstemci tarafı ile Node tarafı sıkıştırma kütüphaneleri (Sharp vs Squoosh vs browser-image-compression) arasında seçim yapıyorsanız, resim sıkıştırma rehberi: tarayıcı ile Node.js karşılaştırmalar ve ödünleri konusunda daha derine iner.

6. Tuzaklar ve yaygın yanılgılar

6.1 “AVIF her zaman kazanır” — ekran görüntüleri ve çizgi sanatı için değil

AVIF’in güçlü yönü sürekli tonlu fotoğraflardır. Keskin metinli ekran görüntüleri, UI yakalamaları ve piksel sanatında WebP eşdeğer kalitede çoğu zaman daha küçük dosyalar üretir. AVIF’in deblocking işlemi, düz renk bölgelerinde ince bantlanma getirebilir. Dönüşümleri her iki yöne de deneyin ve varlık sınıfı başına kazananı seçin.

6.2 “Kayıpsız WebP, saydam PNG’nin tam yerini tutar” — yakın, ama özdeş değil

Kayıpsız WebP, PNG’den gerçekten daha küçüktür; tipik olarak yaklaşık %26. Ama ince bir nokta var: “kayıpsız” sıkıştırılmış görsele uygulanır, ama kodlayıcı yine de yüksek gradyanlı bölgelerde alfa kanalı yuvarlamasını değiştirebilir. Piksel düzeyinde tam yeniden üretim için (medikal görüntüleme, arşiv varlıkları, kaynağa hukuken eşleşmesi gereken her şey) PNG’yi koruyun. Diğer her şey için kayıpsız WebP net bir kazançtır.

6.3 “.avif dosyalarını yükleyivermek” — CDN’iniz onların ne olduğunu bilmiyor olabilir

Eski nginx ve Apache yapılandırmaları AVIF’ten önce gelir. /etc/nginx/mime.types içinde image/avif avif; listelenmemişse nginx, AVIF’i application/octet-stream olarak sunar. Tarayıcı yanlış Content-Type görür, görseli render etmeyi reddeder ve sessizce JPEG’e düşer; tüm optimizasyonu boşa çıkarır. Deploy sonrası varlık URL’nizi curl ile çekip Content-Type başlığını kontrol edin. Beş saniyelik paranoya, “AVIF üretimde neden bozuk” diye geçen bir haftadan tasarruf ettirir.

6.4 iOS 16.0–16.3 AVIF çökmesi

Bazı AVIF dosyaları iOS 16.0–16.3’te Safari’nin çözme çökmesini tetikler. Hata 16.4’te (Mart 2023) düzeltildi; ama kurumsal MDM ve yavaş OEM güncellemeleri eski cihazları hayatta tutar. Hafifletme: aynı <picture> içinde çalışan bir WebP kaynağı olmadan AVIF göndermeyin, bir AVIF’i doğrudan <img> src olarak da koymayın. 4. bölümdeki örüntüleri izlerseniz zaten korumalı olursunuz.

7. 2026 hızlı başvuru

Senaryo	Birincil	Fallback	Kodlayıcı
Statik pazarlama sayfaları	AVIF q60	WebP q75 + JPEG q80	CI’da cavif + cwebp
Blog yazıları ve dokümanlar	WebP q75	JPEG q80	ücretsiz resim sıkıştırıcı (manuel) veya Sharp (build)
Kullanıcı yüklemeleri	WebP (istemci tarafı)	JPEG (WebP kodlaması olmayan tarayıcı)	browser-image-compression + AVIF için sunucu tarafı Sharp
HDR / profesyonel fotoğrafçılık	AVIF 10 bit q70	(yok — SDR fallback’i atlayın veya AVIF’ten tamamen vazgeçin)	cavif + libavif HEIF modu
Gerçek zamanlı CDN dağıtımı	Müzakereli (AVIF veya WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Yayına almadan önce iki hatırlatma. CLS’yi önlemek için <img> üzerine width ve height koyun. Üretimdeki en az bir AVIF yanıtının Content-Type başlığını doğrulayın; bozuk MIME yapılandırması, AVIF’i üretimde sessizce öldürür ve bu listedeki diğer her hatadan daha sık başa gelir.

SSS

2026’da hâlâ JPEG fallback’e ihtiyacım var mı?

Evet. AVIF küresel kullanıcıların yaklaşık %93’üne, WebP ise yaklaşık %97’sine ulaşır. Geriye küçük ama gerçek bir kitle kalır (eski Edge, 93’ün altındaki Firefox, 16.4 öncesi iOS, ayrıca iOS 16.0–16.3 hata bölgesi) ve bunların JPEG’e ihtiyacı var. JPEG’i yalnızca analitikleriniz bu tarayıcılardan fiilen sıfır trafik gösteriyorsa ve bunu ispatlayabiliyorsanız bırakın.

AVIF kodlaması yavaşken CI build’lerini nasıl hızlı tutarım?

Üç kaldıraç var. ~%5 boyut karşılığında ~3× hız için cavif --speed 6 veya daha yükseğini kullanın (varsayılan 4’tür). GNU parallel veya build aracınızın worker havuzu ile çekirdekler arasında paralelleştirin. Bir de içerik hash’iyle önbelleğe alın ki değişmeyen kaynak görseller kodlayıcıyı tamamen atlasın. Birleşince bunlar AVIF build süresini genellikle WebP’nin eski tek iş parçacıklı temelinin altına indirir.

WebP çözme gerçekten AVIF’ten daha mı hızlı?

Evet. libwebp, libavif’ten kabaca 2–3× daha hızlı çözer ve fark düşük donanımlı mobilde açılır. Performans darboğazınız ağ değil de çözme ise (örneğin uygun fiyatlı bir Android telefonda uzun bir görsel galerisi), birincil format olarak WebP daha iyidir. Çoğu web trafiğinde ağ tasarrufları baskındır ve AVIF genel olarak yine kazanır.

iPhone kullanıcıları AVIF’i görebilir mi?

iOS 16.4 (Mart 2023) veya sonrasını çalıştıran iPhone’lar Safari’de AVIF’i dahili olarak destekler. iOS 16.0–16.3’teki cihazlarda belirli AVIF dosyalarında Safari’yi çökertebilen belgelenmiş bir çözme hatası vardır; daha eski iOS sürümleri AVIF’i hiç desteklemez. Etkilenen kullanıcıların bir şey görmesi için her zaman <picture> içine bir WebP veya JPEG fallback gönderin.

`<picture>` mu kullanmalıyım, Accept başlığı müzakeresi mi?

Daha küçük projeler açık <picture> işaretlemesinden yarar görür: davranış deterministiktir, yerelde hata ayıklayabilirsiniz ve görsel başına belki 80 bayt HTML ekler. Yüksek trafikli siteler CDN tarafı Accept müzakeresiyle kazanır: görsel başına tek URL, otomatik format yükseltmeleri, CDN her formatı ayrı ayrı önbelleğe alır. Yaygın bir hibrit yaklaşım var: uygulama UI’ı için <picture>, pazarlama varlıkları için CDN müzakeresi.

PNG’m WebP’ye dönüşürken neden büyüdü?

Neredeyse her zaman bunun nedeni şudur: kaynak PNG, pngquant, oxipng veya ZopfliPNG ile zaten agresif şekilde optimize edilmiştir ve tarayıcının Canvas tabanlı kodlayıcısı bu araçlara yetişemez. Optimize edilmiş PNG yerine orijinalden (Photoshop dışa aktarımı, tasarım aracı master’ı, RAW) yeniden kodlayın. Optimize PNG tek kaynağınızsa, orijinal zaten en iyi haline yakındır; ona dokunmayın.

AVIF saydamlığı destekler mi?

Evet. AVIF, 8 ila 12 bitlik tam bir alfa kanalını destekler ve alfa kodlaması genellikle WebP’ninkinden daha kompakttır. Saydam bir PNG çizimi AVIF’e dönüştürüldüğünde tipik olarak %50–70 küçülürken, WebP olarak %30–40 küçülür. AVIF, piksel düzeyinde tam kayıpsız çıktı talep etmeyen herhangi bir bağlamda saydam PNG’nin en güçlü yerine geçenidir.

Tarayıcılar `toBlob('image/avif')` üzerinden AVIF’i dahili olarak kodlayabilir mi?

Şu an yalnızca Chrome 99+. Safari ve Firefox AVIF’i çözebilir, ama Mayıs 2026 itibarıyla Canvas API’leri üzerinden kodlayamaz. İstemci tarafı AVIF kodlaması için bugün libavif-wasm veya jsquash gibi WebAssembly kütüphanelerine ihtiyacınız var; bunlar 1–2 MB payload ekler. Üretim yığınlarının çoğu tarayıcıda WebP’ye sıkıştırır ve AVIF üretimini bir sunucu worker’ına devreder.