WebP vs AVIF vs JPEG: Format Gambar Mana yang Terbaik di 2026?

TL;DR. AVIF 20–30% lebih kecil daripada WebP dan 30–50% lebih kecil daripada JPEG. WebP kira-kira 25–35% lebih kecil daripada JPEG. Encoding AVIF 5–20× lebih lambat daripada WebP, sedangkan decoding WebP paling cepat di antara ketiganya. Alur kerja pemenang di 2026: sajikan AVIF dulu, fallback ke WebP, simpan JPEG sebagai jaring pengaman universal, dan biarkan browser memilih lewat elemen <picture>.

Jawaban itu sudah cukup untuk sebagian besar pembaca. Pertanyaan yang lebih menarik justru kapan tidak perlu memakai AVIF. Lewati AVIF kalau anggaran CI Anda ketat dan waktu encoding lebih penting daripada ukuran byte. Tunda dulu untuk upload pengguna real-time, karena encoding AVIF di sisi browser masih belum merata. Pertahankan JPEG sebagai format utama kalau Anda harus mendukung iOS 16.0–16.3 atau Edge versi lama yang masih beredar. Di skenario lainnya AVIF unggul dalam ukuran file, asalkan markup <picture> Anda benar dan CDN mengirim MIME type yang tepat.

Sisa panduan ini berisi detail teknisnya: angka dukungan 2026, benchmark foto nyata, pohon keputusan berdasarkan use-case, pola <picture> siap pakai, perintah konversi, dan empat jebakan yang membuat tim membuang waktu. Kalau Anda hanya butuh konversi cepat, kompresor gambar gratis kami menangani JPEG, PNG, WebP, dan AVIF langsung di browser tanpa upload apa pun.

1. Dukungan Browser 2026: WebP di 97%, AVIF di 93%

Dua setengah tahun setelah Edge merilis AVIF, kesenjangan dukungan tinggal menyisakan beberapa persen dari trafik global. Pertanyaannya bukan lagi “apakah didukung”, tapi “apa yang kita sajikan untuk 3% terakhir?“

1.1 WebP: default yang aman

WebP dirilis di Chrome sejak 2012, Firefox 65 (2019), Edge 18 (2018), dan Safari 14 (2020). Per Mei 2026, caniuse mencatat dukungan global sekitar 97%. WebP sudah naik kelas dari “alternatif modern” menjadi “fallback yang layak”. Kalau Anda hanya menyajikan satu format non-JPEG, pilihannya WebP.

1.2 AVIF: sudah layak jadi format utama

AVIF muncul di Chrome 85 (Agustus 2020) dan Firefox 93 (Oktober 2021). Safari 16.4 mengaktifkannya di macOS dan iOS pada Maret 2023. Edge paling lambat, baru menambahkan dukungan decode di versi 121 (Januari 2024). Cakupan global per Mei 2026 sekitar 93–95%.

Ada satu sisi tajam yang perlu disorot. iOS 16.0–16.3 punya bug decode AVIF yang sudah dikenal dan bisa membuat Safari crash pada gambar tertentu. Build tersebut masih hidup di perangkat yang tertahan oleh enterprise MDM, sehingga AVIF tanpa fallback WebP atau JPEG yang berfungsi adalah risiko outage yang nyata. Perlakukan AVIF sebagai “utama dengan asuransi”, bukan “utama tanpa cadangan”.

1.3 Matriks kompatibilitas singkat

Format	Dukungan global (Mei 2026)	Batasan utama
JPEG	100%	File terbesar; tanpa transparansi; tanpa HDR
WebP	~97%	Tanpa HDR atau warna 10-bit
AVIF	~93–95%	Encode lambat; bug decode iOS 16.0–16.3; butuh Edge 121+

2. Perbedaan Inti: Kompresi, Kecepatan, Fitur

2.1 Efisiensi kompresi pada foto nyata

Satu benchmark dari sumber yang sama. Foto landscape 4000×3000, PNG aslinya sekitar 24 MB, di-encode ulang pada kualitas yang setara secara perseptual:

Encoding	Ukuran	Vs baseline JPEG
JPEG q75 (mozjpeg)	~2.1 MB	0% (baseline)
WebP q75 (libwebp)	~1.4 MB	33% lebih kecil
AVIF q60 (libavif, cpu-used 4)	~1.0 MB	52% lebih kecil

AVIF q60 di sini setara secara visual dengan JPEG q80 dan WebP q75. Skala kualitas tidak bisa dipertukarkan antar codec. Meng-encode ulang “JPEG q75 ke AVIF q75” adalah kesalahan klasik pemula: Anda berakhir dengan AVIF yang kebesaran tapi tampilannya identik dengan sumbernya.

2.2 Kecepatan encoding: pajak 5–20×

AVIF menghasilkan kompresi yang lebih agresif karena memang mengerjakan lebih banyak hal. Memakai libavif dengan default cpu-used 4, gambar 4000×3000 butuh waktu 5–20× lebih lama daripada libwebp dan kira-kira 50× lebih lama daripada mozjpeg. Biaya itu menumpuk di build CI, cold start Lambda, dan pipeline yang meng-encode ulang ribuan aset.

Ada dua katup pelepas. cavif --speed 9 (atau libavif cpu-used 9) bisa mendekati libwebp dalam jarak 3×, dengan harga file 5–8% lebih besar. Lalu lakukan caching agresif: pipeline aset content-addressed yang melewatkan re-encode untuk sumber yang tidak berubah mengubah codec lambat jadi biaya satu kali.

2.3 Kedalaman warna dan HDR

JPEG dan WebP terbatas di 8-bit sRGB. AVIF menangani warna 10- dan 12-bit, Rec. 2020, DCI-P3, plus fungsi transfer PQ/HLG secara native. Untuk thumbnail video HDR, galeri foto profesional, atau proof cetak di sisi browser, AVIF adalah satu-satunya opsi terstandar saat ini.

2.4 Transparansi dan animasi

JPEG tidak punya keduanya. WebP dan AVIF sama-sama mendukung alpha dan animasi. Khusus untuk menggantikan PNG transparan, AVIF meng-encode alpha lebih ringkas: ilustrasi UI yang menyusut 30–40% sebagai WebP biasanya menyusut 50–70% sebagai AVIF.

3. Pohon Keputusan: Format Mana untuk Pekerjaan Mana

3.1 Situs statis: blog, halaman marketing, dokumentasi

AVIF utama, WebP fallback, JPEG jaring pengaman. Encoding terjadi sekali di CI, jadi pajak 5–20× dibayar pada waktu build, bukan waktu pengguna. Ini kasus kanonik untuk pola <picture> tiga sumber di bagian 4.

3.2 Upload pengguna: avatar, UGC, lampiran formulir

Kompresi ke WebP di browser, encode ulang ke AVIF secara async di server. canvas.toBlob('image/avif') di sisi browser baru bekerja di Chrome 99+ saat ini, jadi AVIF tidak bisa dijadikan jalur upload. WebP mengompresi cepat di browser dan menghemat bandwidth pada upload itu sendiri.

Untuk perbandingan lebih dalam soal library sisi klien (Squoosh, browser-image-compression, Compressor.js) dan bagaimana mereka berpasangan dengan Sharp atau Imagemin di sisi server, baca panduan kompresi gambar: browser vs Node.js. Pilihan format dan lokasi pemrosesan bersifat ortogonal; panduan ini fokus pada sumbu format.

3.3 HDR dan fotografi fidelitas tinggi

Hanya AVIF. Tidak ada format lain di tumpukan web terbuka yang mendukung warna 10- atau 12-bit hari ini. Lewati fallback untuk aset khusus HDR, atau terima bahwa fallback JPEG akan SDR.

3.4 Audiens dengan banyak browser legacy

JPEG utama, WebP opsional, tanpa AVIF. Portal pemerintah, beberapa lingkungan enterprise di Asia Timur, dan tools B2B dengan ekor perangkat panjang kadang menampilkan 5–10% trafik IE/Edge lama di analytics. WebP sekarang aman; AVIF belum.

3.5 Pengiriman CDN real-time

libvips atau Sharp di sisi server melakukan streaming WebP, sementara AVIF dibuat di background worker dan disajikan saat cache hit. Jangan blokir respons demi menunggu encoding AVIF. Cloudflare Polish, Vercel Image Optimization, dan Cloudinary f_auto mengotomasi pola tersebut.

4. Fallback `<picture>` yang Benar

Elemen <picture> ada justru agar browser bisa memilih sumber yang paling didukung. Tiga lapisan, dengan AVIF didaftar pertama, memberi Anda anggaran byte yang optimal tanpa rusak di klien lama.

4.1 Baseline tiga lapis

<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="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

Tiga hal yang perlu disorot. Browser membaca elemen <source> dari atas ke bawah dan memilih yang type-nya paling awal ia kenali; sisanya diabaikan, tidak diunduh. Tag <img> adalah elemen yang benar-benar di-render dan mewarisi atribut (alt, sizes, classes) terlepas dari sumber mana yang menang. Lalu width/height pada <img> bukan opsional di 2026; keduanya menyediakan ruang dan mencegah Cumulative Layout Shift.

Untuk gambar di atas lipatan (above-the-fold), tukar loading="lazy" dengan loading="eager" fetchpriority="high". Lazy-loading pada gambar LCP adalah salah satu blunder Core Web Vitals paling umum.

4.2 Responsif plus format: pola lengkap

Kalau Anda juga butuh resolusi responsif, ulangi srcset di dalam setiap <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="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

Ya, itu sembilan file yang dihasilkan per gambar. Build step jadi wajib di skala ini; bagian 5.3 membahas apa yang bisa dipasang.

4.3 Negosiasi `Accept` di sisi server sebagai alternatif

Kalau CDN Anda mendukungnya, content negotiation memadatkan markup jadi satu tag <img>. Browser mengirim Accept: image/avif,image/webp,image/apng,*/*, lalu CDN merespons dengan format paling didukung di URL yang sama.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto, dan CloudFront dengan Lambda@Edge semuanya mengimplementasikannya. Trade-off-nya: HTML lebih kecil dan satu URL per gambar, tapi Anda terkunci ke vendor CDN dan debugging lokal jadi lebih sulit. Pembagian yang berguna: negosiasi CDN untuk halaman marketing, <picture> eksplisit untuk UI produk yang butuh perilaku deterministik.

5. Cara Mengonversi Gambar Antar Format

5.1 Di browser, tanpa upload

Jalur tercepat untuk konversi sekali pakai atau batch kecil adalah cukup di browser. Drop sebuah JPEG ke kompresor gambar gratis, pilih WebP atau AVIF sebagai output, dan file tidak pernah meninggalkan mesin Anda. Input AVIF didukung di mana-mana; output AVIF memakai encoding browser native di Chrome 85+ dan secara transparan fallback ke WebP di browser yang belum bisa meng-encode AVIF.

5.2 Command line untuk pipeline build

Untuk pipeline produksi, Anda butuh output deterministik dan build yang reproducible. Tiga perintah berikut nyata:

# AVIF: cavif (Rust, mudah dipasang via cargo atau brew)
cavif --quality 60 --speed 4 input.jpg -o output.avif

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

# Keduanya, plus resize, via libvips (tercepat untuk batch)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed berjalan dari 0 (paling lambat, paling kecil) sampai 10 (paling cepat, paling besar). Default 4 cocok untuk nightly build; naikkan ke 9 untuk preview PR di mana kecepatan mengalahkan ukuran byte.

5.3 Integrasi pipeline build

Sebagian besar framework situs statis sudah membungkus encoder ini. Pilih yang sesuai dengan stack Anda:

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

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

Untuk aset kecil (ikon di bawah ~5 KB, avatar inline, header email), lewati jaringan sepenuhnya dan inline sebagai data URI memakai encoding Base64. Itu menukar satu request HTTP dengan beberapa byte HTML tambahan, biasanya menguntungkan di bawah ~5 KB.

Kalau Anda sedang memilih antara library kompresi sisi klien dan sisi Node (Sharp vs Squoosh vs browser-image-compression), panduan kompresi gambar: browser vs Node.js membahas benchmark dan trade-off-nya lebih dalam.

6. Jebakan dan Kesalahpahaman

6.1 “AVIF selalu menang”: tidak untuk screenshot dan line art

Kekuatan AVIF adalah foto continuous-tone. Pada screenshot dengan teks tajam, capture UI, dan pixel art, WebP sering menghasilkan file lebih kecil pada kualitas setara. Deblocking AVIF bisa memunculkan banding halus pada area warna datar. Jalankan konversi ke dua arah, lalu pilih pemenang per kelas aset.

6.2 “WebP lossless menggantikan PNG transparan dengan sempurna”: mendekati, bukan identik

WebP lossless memang lebih kecil daripada PNG, biasanya sekitar 26%. Tangkapannya: “lossless” berlaku untuk gambar yang dikompresi, tapi encoder masih mungkin mengubah pembulatan alpha-channel di area gradien tinggi. Untuk reproduksi pixel-exact (citra medis, aset arsip, apa pun yang secara hukum wajib cocok dengan sumber), pertahankan PNG. Untuk yang lain, WebP lossless adalah keuntungan bersih.

6.3 “Tinggal upload file .avif”: CDN Anda mungkin tidak mengenalinya

Konfigurasi nginx dan Apache lama lahir sebelum AVIF ada. Kalau /etc/nginx/mime.types tidak mencantumkan image/avif avif;, nginx menyajikan AVIF sebagai application/octet-stream. Browser melihat Content-Type yang salah, menolak me-render gambar, lalu diam-diam fallback ke JPEG, dan seluruh optimisasinya hilang. Lakukan curl ke URL aset Anda setelah deploy, lalu periksa header Content-Type. Lima detik paranoia menyelamatkan satu minggu pertanyaan “kenapa AVIF rusak di production”.

6.4 Crash AVIF iOS 16.0–16.3

Beberapa file AVIF memicu crash decode Safari di iOS 16.0–16.3. Bug ini sudah diperbaiki di 16.4 (Maret 2023), tapi enterprise MDM dan update OEM yang lambat membuat perangkat lama tetap hidup. Mitigasi: jangan pernah merilis AVIF tanpa sumber WebP yang berfungsi di dalam <picture> yang sama, dan jangan pernah memasang AVIF langsung di src <img>. Mengikuti pola di bagian 4 sudah cukup melindungi Anda.

7. Cheat Sheet 2026

Skenario	Utama	Fallback	Encoder
Halaman marketing statis	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp di CI
Postingan blog dan dokumentasi	WebP q75	JPEG q80	kompresor gambar gratis (manual) atau Sharp (build)
Upload pengguna	WebP (sisi klien)	JPEG (browser tanpa encode WebP)	browser-image-compression + Sharp sisi server untuk AVIF
HDR / fotografi profesional	AVIF 10-bit q70	(tidak ada — drop fallback SDR atau lewati AVIF sama sekali)	cavif + libavif mode HEIF
Pengiriman CDN real-time	Hasil negosiasi (AVIF atau WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Dua pengingat sebelum rilis. Selalu pasang width dan height pada <img> untuk mencegah CLS. Selalu verifikasi header Content-Type produksi pada setidaknya satu respons AVIF; konfigurasi MIME yang rusak lebih sering diam-diam mematikan AVIF di production daripada kegagalan lain mana pun di daftar ini.

FAQ

Apakah saya masih butuh fallback JPEG di 2026?

Ya. AVIF menjangkau kira-kira 93% pengguna global dan WebP sekitar 97%. Itu menyisakan populasi kecil tapi nyata (Edge lama, Firefox di bawah 93, iOS sebelum 16.4, plus zona bug iOS 16.0–16.3) yang masih butuh JPEG. Drop JPEG hanya kalau analytics Anda menunjukkan trafik praktis nol dari browser-browser tersebut dan Anda bisa membuktikannya.

Bagaimana menjaga build CI tetap cepat saat encoding AVIF lambat?

Tiga tuas. Pakai cavif --speed 6 atau lebih tinggi (default 4) untuk menukar ~5% ukuran demi ~3× kecepatan. Paralelkan lintas core dengan GNU parallel atau worker pool dari build tool Anda. Lalu lakukan cache berdasarkan content hash supaya gambar sumber yang tidak berubah melewati encoder sepenuhnya. Digabungkan, ketiganya biasanya memotong waktu build AVIF di bawah baseline single-threaded WebP yang lama.

Apakah decoding WebP benar-benar lebih cepat daripada AVIF?

Ya. libwebp men-decode kira-kira 2–3× lebih cepat daripada libavif, dan jaraknya melebar di perangkat mobile kelas bawah. Kalau bottleneck performa Anda adalah decode (misalnya galeri gambar panjang di Android budget) bukan jaringan, WebP adalah format utama yang lebih baik. Untuk sebagian besar trafik web, penghematan jaringan lebih dominan dan AVIF tetap menang secara keseluruhan.

Bisakah pengguna iPhone melihat AVIF?

iPhone yang menjalankan iOS 16.4 (Maret 2023) atau lebih baru mendukung AVIF secara native di Safari. Perangkat di iOS 16.0–16.3 punya bug decode yang sudah terdokumentasi dan bisa membuat Safari crash pada file AVIF tertentu; versi iOS lebih lama tidak mendukung AVIF sama sekali. Selalu rilis fallback WebP atau JPEG di dalam <picture> supaya pengguna yang terdampak tetap melihat sesuatu.

Sebaiknya pakai `<picture>` atau negosiasi Accept-header?

Proyek lebih kecil diuntungkan dengan markup <picture> eksplisit: perilaku deterministik, bisa di-debug lokal, dan tambahannya sekitar 80 byte HTML per gambar. Situs trafik tinggi lebih untung dengan negosiasi Accept di sisi CDN: satu URL per gambar, upgrade format otomatis, dan CDN meng-cache tiap format terpisah. Hibrida yang lazim: <picture> untuk UI aplikasi, negosiasi CDN untuk aset marketing.

Kenapa PNG saya jadi lebih besar setelah dikonversi ke WebP?

Hampir selalu karena PNG sumber sudah dioptimalkan agresif oleh pngquant, oxipng, atau ZopfliPNG, dan encoder berbasis Canvas di browser tidak bisa menyamai tools tersebut. Encode ulang dari aslinya (export Photoshop, master design tool, RAW), bukan dari PNG yang sudah dioptimalkan. Kalau PNG yang sudah dioptimalkan itu satu-satunya sumber yang Anda punya, berarti aslinya sudah mendekati optimal: biarkan saja.

Apakah AVIF mendukung transparansi?

Ya. AVIF mendukung alpha channel penuh 8- sampai 12-bit, dan encoding alphanya umumnya lebih ringkas daripada WebP. Ilustrasi PNG transparan yang dikonversi ke AVIF biasanya menyusut 50–70%, dibandingkan 30–40% sebagai WebP. AVIF adalah pengganti terkuat untuk PNG transparan di konteks apa pun yang tidak menuntut output lossless pixel-exact.

Bisakah browser melakukan encoding AVIF secara native via toBlob(‘image/avif’)?

Hanya Chrome 99+ saat ini. Safari dan Firefox bisa men-decode AVIF tapi tidak bisa meng-encode-nya via Canvas API per Mei 2026. Untuk encoding AVIF di sisi klien, Anda saat ini butuh library WebAssembly seperti libavif-wasm atau jsquash, yang menambah payload 1–2 MB. Sebagian besar stack produksi mengompresi ke WebP di browser dan menyerahkan pembuatan AVIF ke worker server.