Setelah bertahun-tahun nyaris hanya hidup di kalangan fotografer dan penggemar format gambar, JPEG XL (.jxl) akhirnya benar-benar masuk ke browser mainstream. Chrome 155 mulai mendekode JPEG XL secara default sejak 6 Oktober 2026, dan sepekan kemudian Firefox 158 menyusul dengan decoder barunya sendiri. Safari sudah lebih dulu membuka file JXL sejak versi 17 pada 2023. Artinya, untuk pertama kalinya dalam beberapa tahun, tiga mesin browser besar bisa menampilkan satu format gambar modern yang sama.

Bagi pengelola situs pemerintahan, desa, sekolah, atau aplikasi web internal, ini bukan sekadar berita format gambar. Halaman yang penuh foto kegiatan — rapat, sosialisasi, dokumentasi pembangunan — biasanya justru berat di aset gambar, bukan di kode. Format yang lebih efisien berarti halaman lebih cepat dibuka di jaringan seluler yang pas-pasan, tanpa harus menurunkan kualitas foto.

Kenapa JPEG XL berbeda dari format sebelumnya

Menurut pengumuman resmi Chrome for Developers, JPEG XL menawarkan kompresi 30–50% lebih baik dibanding JPEG, mendukung kompresi lossless, HDR bawaan, dan yang paling praktis: transcoding JPEG lama secara lossless. Tidak seperti WebP atau AVIF yang harus meng-encode ulang dari sumber, file JPEG yang sudah ada bisa dikonversi ke JXL dan nantinya direkonstruksi kembali menjadi JPEG yang identik bit-per-bit. Jadi arsip foto lama tidak perlu dikorbankan.

Yang juga menarik dari sisi engineering: decoder JPEG XL di Chrome dan Firefox bukan port C++ lama, melainkan jxl-rs, implementasi ulang dalam Rust yang dibuat tim Google Research. Mozilla bahkan menantang Google lebih dulu — bangun decoder yang aman, cepat, ringkas, dan kompatibel dalam Rust, maka Firefox akan mengirimkannya. Tantangan itu dipenuhi, dan decoder yang sama kini jadi inti dukungan JPEG XL di Firefox. Bagi developer, ini contoh nyata bagaimana bahasa yang memory-safe dipakai untuk menutup permukaan serangan di komponen yang memproses data tak tepercaya dari jaringan.

Status dukungan browser per Oktober 2026

• Chrome 155+ (desktop dan Android): decode JXL aktif secara default sejak 6 Oktober 2026. Versi 145–154 masih perlu flag.
• Firefox 158+: aktif default sejak 13 Oktober 2026. Header Accept untuk gambar kini menyertakan image/jxl, jadi server bisa memilih format secara otomatis lewat content negotiation.
• Safari 17+: mendukung JXL diam (still image) sejak 2023, tetapi belum punya progressive rendering dan animasi.
• Edge, Opera, dan browser lama: belum aktif default; masih perlu flag atau belum mendukung sama sekali.

Karena itu, memasang .jxl tanpa fallback bukan pilihan yang aman. MDN sendiri masih menandai dukungan JPEG XL sebagai belum universal dan menyarankan menyediakan alternatif AVIF, WebP, atau JPEG.

Pola pemasangan yang aman: picture dengan fallback

Gunakan elemen <picture> sehingga browser yang tidak mendukung JXL otomatis mengambil file cadangan. Tidak perlu JavaScript deteksi format.

<picture>
  <source srcset="/img/kegiatan-2026.jxl" type="image/jxl">
  <source srcset="/img/kegiatan-2026.avif" type="image/avif">
  <img src="/img/kegiatan-2026.jpg" alt="Rapat koordinasi desa"
       width="1200" height="800" loading="lazy">
</picture>

Urutan source menentukan prioritas: browser memilih format pertama yang dikenali. Sertakan selalu width dan height agar layout tidak bergeser saat gambar dimuat, dan tambahkan loading="lazy" untuk gambar di bawah lipatan layar.

JPEG XL atau AVIF? Tergantung jenis gambarnya

Ini bagian yang sering disalahpahami sebagai kompetisi. Jake Archibald dari Mozilla membandingkan keduanya dengan metrik kualitas SSIMULACRA 2 pada satu foto uji: pada kualitas medium-tinggi, AVIF 116 kB sementara JPEG XL 134 kB; pada kualitas sangat tinggi, AVIF 227 kB dan JPEG XL 264 kB. Namun saat masuk mode lossless, urutannya berbalik — AVIF 1,76 MB, JPEG XL 1,45 MB. Untuk screenshot dashboard, selisihnya lebih tajam: lossless AVIF 164 kB versus JPEG XL 92 kB.

Kesimpulan praktisnya: AVIF tetap lebih kecil untuk foto web biasa, sedangkan JPEG XL unggul untuk gambar lossless, arsip berkualitas tinggi, dan gambar besar yang butuh progressive rendering (gambar tampil bertahap saat masih diunduh, bukan kosong lalu muncul sekaligus). Chrome sendiri menyarankan mencoba keduanya pada gambar yang representatif, bukan memilih berdasarkan klaim umum.

Alat encoding di server Linux

Untuk server Debian/Ubuntu, paket libjxl-tools menyediakan encoder cjxl dan decoder djxl:

apt install libjxl-tools

# Konversi PNG ke JPEG XL kualitas visual-lossless (default -d 1)
cjxl input.png output.jxl

# Kualitas sedikit lebih rendah, cocok untuk web
cjxl -d 2 input.png output.jxl

# JPEG lama dikonversi lossless, JPEG asli bisa direkonstruksi
cjxl foto-lama.jpeg foto-lama.jxl
djxl foto-lama.jxl kembali.jpeg

Parameter -d adalah jarak dalam satuan just-noticeable difference: -d 0 berarti lossless matematis, -d 1 secara visual lossless, dan rentang berguna untuk web sekitar 0,5 sampai 3. Ada juga --effort (1–9) untuk menukar waktu encoding dengan ukuran file. Di macOS tersedia lewat brew install jpeg-xl. Jika tidak mau menyentuh terminal, Squoosh dan ImageMagick 7.0.10-54 ke atas juga sudah mendukung JPEG XL.

Langkah uji yang disarankan

1. Ambil 10–20 gambar yang mewakili isi situs: foto kegiatan, screenshot, banner, dan ilustrasi.
2. Encode masing-masing ke AVIF, JPEG XL, dan WebP pada kualitas yang setara secara visual, lalu catat ukuran file dan waktu encoding.
3. Bandingkan total ukuran per halaman, bukan per file. Halaman dengan 30 foto bisa turun drastis hanya dari satu format yang tepat.
4. Terapkan <picture> dengan fallback, lalu uji di Chrome 155+, Firefox 158+, Safari 17+, dan satu browser lama.
5. Periksa jalur upload: banyak CMS dan validasi form masih menolak ekstensi .jxl, jadi pastikan server menerima image/jxl sebelum mengubah kebiasaan tim.

Yang perlu diwaspadai

Pertama, rollout Chrome tidak instan — pengguna dengan versi lama atau pembaruan tertunda masih akan jatuh ke fallback, jadi tetap siapkan cadangan. Kedua, jangan mengonversi seluruh arsip sekaligus tanpa uji; simpan file asli dan jalankan konversi bertahap per folder. Ketiga, untuk yang memakai libjxl di server sendiri, tim proyek menyarankan memperbarui ke v0.12 karena banyak perbaikan keamanan di rilis tersebut. Keempat, Safari mendukung JXL tetapi tanpa progressive rendering, jadi keunggulan utama format ini di gambar besar belum terasa di semua browser.

Yang paling penting: keputusan format sebaiknya berbasis pengukuran di situs sendiri. JPEG XL kini layak masuk daftar kandidat, bukan lagi eksperimen yang harus ditunda.

Sumber: Shipping JPEG XL in Chrome (Chrome for Developers, 6 Oktober 2026), Intent to Ship: JPEG XL (Mozilla Hacks), Firefox 158 release notes for developers (MDN), dokumentasi cjxl dan daftar dukungan perangkat lunak libjxl.