JPEG XL 入門 - 全ブラウザ対応へ動き出した画像フォーマットと AVIF の使い分け

2022年10月、Google は Chrome から JPEG XL を削除すると発表しました。「エコシステムの関心が足りない」「既存フォーマットに対する上積みが不十分」という理由で、実際に 2023年2月の Chrome 110 でコードごと消えました。当時これは JPEG XL の終わりを意味すると受け止められました。

ところが 2026年8月24日、Mozilla と Chromium がほぼ同時刻に JPEG XL の Intent to Ship を提出します。Firefox 157（2026年9月29日リリース予定）で既定 ON、Chromium も全ユーザー向けに有効化する方針です。Safari は 2023年から対応済みなので、年内には主要3エンジンすべてが .jxl を表示できるようになります。

この記事では、JPEG XL とはそもそも何なのか、なぜ一度消えて戻ってきたのか、そして実務でいま何をすべきかを整理します。圧縮の一般論についてはデータ圧縮の仕組み 入門が前段になります。

JPEG XL とは何か

JPEG XL は JPEG 委員会（ISO/IEC JTC 1/SC 29）が策定した画像符号化方式で、規格番号は ISO/IEC 18181 シリーズです。4つのパートに分かれています。

技術的なルーツが2つあることが、このフォーマットの性格を決めています。非可逆側は Google の PIK、可逆側は Cloudinary の FUIF（さらにその元は FLIF）です。この2系統がそのまま2つの符号化モードとして残りました。

• VarDCT モード: JPEG と同じ DCT がベースですが、ブロックサイズが 8×8 固定ではなく 2×2 から 256×256 まで可変で、16×8 のような非正方形や AFV・Hornuss といった別変換も選べます。色空間には LMS 由来の XYB を使います。写真の非可逆圧縮はこちら。
• Modular モード: 可逆圧縮のためのモードで、PNG に相当する役割を担います。同時に VarDCT モードの内部でも「サブビットストリーム」として使われ、1/8 に縮小された DC 画像や適応量子化の重み、フィルタ強度などを格納します。

仕様上のスペックも押さえておきます。

MIME タイプは IANA に正式登録されており、登録票にはマジックナンバーとして FF 0A（裸のコードストリーム）または 00 00 00 0C 4A 58 4C 20 0D 0A 87 0A（ISOBMFF コンテナ）が記載されています。

2026年9月時点のブラウザ対応状況

本記事執筆時点（2026年9月2日）の状況です。

Firefox で今すぐ試すなら about:preferences#experimental の Firefox Labs に JPEG XL のチェックボックスがあります（about:config の image.jxl.enabled でも同じ）。Chrome は chrome://flags/#enable-jxl-image-format です。

日付の見通しははっきりしています。Firefox 157 のリリース予定日は 2026年9月29日です。Chromium 側は Chrome Platform Status のエントリで「2026年内」となっているものの、具体的なマイルストーン番号は未定です。Intent to Ship は提出当日に Blink API オーナーの LGTM 3件を取得しています。

JPEG XL は Interop 2026 の investigation area（調査領域）にも選ばれています。フォーカスエリアと違ってブラウザごとのスコアは付きませんが、テストが手薄な現状を改善する作業が進んでいます。専用リポジトリには、高ビット深度・広色域・HDR・ICC プロファイル・CMYK・VarDCT・Modular・プログレッシブレンダリング・アニメーションといった14の機能と、CSS background-image や Canvas、ImageDecoder API など9つの Web 統合ポイントがテスト対象として列挙されています。

一度消され、Rust で戻ってきた

復活の経緯は、フォーマットの圧縮率が改善したからではありません。デコーダの実装言語が変わったからです。

Mozilla は 2021年から実験的対応を持っていましたが、出荷には踏み切りませんでした。理由は Jake Archibald が Mozilla Hacks の記事で明快に書いています。

at 100,000 lines of multithreaded C++, we were concerned about the attack surface this added to Firefox.

10万行のマルチスレッド C++ をブラウザに取り込むことへの懸念です。画像デコーダは信頼できないバイト列を処理する典型的な攻撃面で、歴史的に脆弱性の温床でした。そこで Mozilla は Google Research の JPEG XL チームに「安全・高速・コンパクト・互換性のあるデコーダを Rust で書けば出荷する」と条件を出します。その成果が jxl-rs で、Firefox と Chrome の双方が同じこの Rust デコーダを採用しました（Safari だけは C++ の libjxl のままです）。

Rust によってメモリ安全性のクラスの脆弱性は排除されますが、パーサのロジックバグが無いことを保証するわけではありません。しかも Gecko と Blink が同一のデコーダを共有するため、1つの欠陥が両エンジンに同時に効くという新しい構図にもなっています。

実測: 何が得意で何が苦手か

ここからは手元で計測します。「JPEG XL は AVIF より優れている」といった一般論はほぼ成立せず、可逆か非可逆か、写真かスクリーンショットかで結論が入れ替わります。

計測環境は macOS（Apple Silicon）、cjxl / djxl 0.12.0、libavif 1.4.2（aom 3.14.1）、libwebp 1.6.0 です。品質評価には libjxl 付属の SSIMULACRA 2 を使いました。0〜100 のスケールで 70 が高品質、80 が「1:1 の並列比較で原画と区別できない」水準、90 が視覚的可逆にあたります。

テスト画像は2枚です。

• 写真: Kodak テスト画像の kodim23.png（768×512、PNG 544.5 KB）
• スクリーンショット: 本ブログのトップページ（1280×1600、PNG 837.2 KB）

可逆圧縮では JPEG XL が最も小さい

写真で PNG 比 32.8%、スクリーンショットで 26.8% の削減です。注目すべきは AVIF の弱さで、スクリーンショットでは可逆 AVIF が元の PNG より大きくなっています。AVIF は動画コーデック AV1 のイントラフレームを流用した設計なので、可逆モードは本質的に不得手です。

非可逆では品質を揃えると AVIF が勝つ

非可逆の比較は「同じ品質で何バイトか」で見ないと意味がありません。SSIMULACRA 2 のスコアが目標値になるまで各エンコーダのパラメータを二分探索し、そのときのファイルサイズを比べました。

写真（kodim23.png）:

スクリーンショット:

写真では AVIF がわずかに小さい程度ですが、スクリーンショットでは AVIF が JPEG XL の約6割のサイズに収まりました。Mozilla が自ら「AVIF は Web 品質の写真と、シャープなエッジと平坦面が混在する画像が得意」と書いているとおりの結果です。ただしスクリーンショットに非可逆を使うと文字の周囲にリンギングが出ます。この用途はそもそも可逆で配信すべきで、そこでは上表のとおり JPEG XL が有利です。

JPEG を「バイト完全に」小さくできる

JPEG XL 固有の機能で、他のどのフォーマットにも無いのがこれです。既存の JPEG をデコードせずに再圧縮でき、しかも元の JPEG ファイルをバイト単位で完全に復元できます。cjxl は JPEG を入力すると既定でこのモードになります。

# 既定で可逆トランスコード（-d や -q は指定しない）
cjxl photo.jpg photo.jxl
 
# 元の JPEG を復元
djxl photo.jxl restored.jpg
 
# バイト単位で一致するか確認
cmp photo.jpg restored.jpg && echo "byte-identical"
shasum -a 256 photo.jpg restored.jpg

手元の結果です。

libjpeg-turbo q85 baseline : 58,733 B  ->  jxl 49,914 B  (-15.0%)
mozjpeg q85 progressive    : 54,767 B  ->  jxl 47,367 B  (-13.5%)
 
byte-identical
7347454fa93ecfb2d7f4f92b1455e6a6ae51a276009ece696acf01d8496e4ead  photo-q85.jpg
7347454fa93ecfb2d7f4f92b1455e6a6ae51a276009ece696acf01d8496e4ead  restored.jpg

SHA-256 が一致しています。つまり「JPEG を JXL に変換して配信し、必要になったら元の JPEG に戻す」が完全に可逆な操作として成立します。既存の JPEG 資産をそのまま持つアーカイブや、劣化を絶対に許容できないワークフローにとって、これは他に代えがたい性質です。すでに mozjpeg で最適化済みの progressive JPEG でも 13.5% 削れました。JPEG 委員会のホワイトペーパーでは 16〜22% の削減とされているので、手元の数値はやや控えめな部類です。

なお、算術符号を使った JPEG や一部の変則的な JPEG は可逆トランスコードに対応していません。その場合は jpegtran で構造を整えてから再試行します。

プログレッシブレンダリングにはコストがある

JPEG XL は 1/8 スケールの DC 画像を先に送れるため、数 KB 受信した時点で被写体が判別できる程度に表示できます。Mozilla がこの機能を jxl-rs に強く要求したのは、AVIF のプログレッシブ対応が2〜3パス程度に留まるためです。

ただし無料ではありません。同じ画像・同じ品質設定でグループ順序を変えると、その分ビットが増えます。

cjxl -d 1.0 -e 7 kodim23.png noprog.jxl        # 56,733 B
cjxl -d 1.0 -e 7 --progressive kodim23.png prog.jxl  # 62,273 B (+9.8%)

小さなサムネイルには不要で、ヒーロー画像のような大きい画像で効いてくる機能です。

cjxl / djxl を使う

参照実装 libjxl の CLI が cjxl（エンコード）と djxl（デコード）です。最新は v0.12.0（2026年7月1日）で、多数のセキュリティ修正を含むため旧版からの更新が推奨されています。

brew install jpeg-xl          # macOS
sudo apt install libjxl-tools # Debian / Ubuntu

主要オプションは2つだけ覚えれば足ります。

-d と -q は排他です。効果を実測すると次のようになります（写真の可逆圧縮）。

effort 7 から 9 に上げると時間は 5.6 倍になるのにサイズは 0.6% しか縮みません。既定の 7 が妥当なバランスで、CI やバッチで大量に処理するなら 5 まで落としても実害は小さいです。

よく使うコマンドをまとめます。

# 数学的可逆（PNG の置き換え）
cjxl -d 0 input.png output.jxl
 
# 視覚的可逆（写真の高品質配信）
cjxl -d 1.0 input.png output.jxl
 
# Web 品質（軽さ優先）
cjxl -d 2.5 -e 7 input.png output.jxl
 
# 中身を確認
jxlinfo output.jxl
 
# PNG に戻す
djxl output.jxl output.png

jxlinfo の出力例です。

JPEG XL file format container (ISO/IEC 18181-2)
JPEG XL image, 768x512, (possibly) lossless, 8-bit RGB
Color space: RGB

Web で配信する

MIME タイプの設定

サーバが .jxl を image/jxl として返さないとブラウザは表示しません。nginx は 2024年に conf/mime.types へ追加済みですが、古い設定ファイルを使い回している場合は自分で足す必要があります。

types {
    image/jxl  jxl;
}

AddType image/jxl .jxl

設定できたかは curl で確認します。

curl -sI https://example.com/hero.jxl | grep -i content-type
# content-type: image/jxl

picture 要素でフォールバックする

まだ全ユーザーが表示できるわけではないので、picture 要素で段階的に落とします。ブラウザは上から順に type を評価し、対応している最初の source を使います。

<picture>
  <source srcset="hero.jxl" type="image/jxl" />
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="説明文" width="1200" height="630" loading="lazy" decoding="async" />
</picture>

サーバサイドで出し分けるなら Accept ヘッダを見ます。JPEG XL に対応したブラウザは image/jxl を Accept に含めます。この場合は Vary: Accept を必ず付けてください。付け忘れると CDN が1つのレスポンスを全ブラウザに配ってしまいます。キャッシュ制御の考え方はCDN キャッシュと s-maxage の実践にまとめてあります。

ツールチェーンの現実

ブラウザがデコードできることと、自分のサイトが JPEG XL を配信できることの間にはまだ距離があります。2026年9月時点の状況です。

sharp の prebuilt に JXL を入れる要望はイシューとして出されましたが、独自ビルドを使う結論でクローズしています。sharp のドキュメントにも、libjxl を有効にした libvips を自前で用意する必要があると明記されています。Next.js を使っているならここが最大の障壁です。

現実的な打ち手は2つです。1つは CDN 側のフォーマット自動変換に任せること。オリジンには可逆 PNG か高品質 JPEG のマスターだけを置き、Accept ヘッダに応じて JXL / AVIF / WebP / JPEG を出し分けてもらいます。もう1つは、自前サーバなら libvips か ImageMagick で初回リクエスト時に変換してキャッシュする方式です。事前に4フォーマット分を全部生成しておくより運用が軽くなります。

いま何をすべきか

結論を先に書きます。本番の配信フォーマットを JPEG XL に切り替えるのは、まだ早いです。

Firefox 157 が既定 ON になるのは2026年9月末、Chrome は年内としか言われていません。しかもユーザーがブラウザを更新するまでには時間差があります。既定でデコードできる利用者の割合が実用水準に届くのは、どんなに早くても2027年に入ってからです。フォールバックの分岐を消せる段階ではありません。

一方で、次の3つは今日から着手する価値があります。

1. アーカイブの JPEG を JXL で保管する。バイト完全に復元できるので、リスクなしで容量が削減できます（手元では 13〜15%）。配信は元の JPEG のままでかまいません。
2. PNG のマスター画像を JXL に置き換える。可逆で 25〜35% 縮み、必要なときに PNG へ戻せます。配信用の派生ファイルはこれまでどおり生成します。
3. picture 要素のフォールバック構造を先に整える。すでに AVIF や WebP を使い分けているなら、source を1行足すだけで JXL に対応できます。この構造さえあれば、対応率が上がった時点で追加作業なしに恩恵を受けられます。

そして「AVIF から JPEG XL へ乗り換える」という発想は、そもそも間違いです。Mozilla 自身が両者を併存する選択肢として説明しています。Web 品質の写真は AVIF、可逆・プログレッシブ・JPEG 再圧縮は JPEG XL。この住み分けが当面の答えです。ブラウザ対応の状況を追うなら caniuse やWeb Baselineの考え方が役に立ちます。

まとめ

• JPEG XL は ISO/IEC 18181 として標準化された、ロイヤリティフリーの画像フォーマット。VarDCT（非可逆）と Modular（可逆）の2モードを持つ
• 2022年に Chrome から削除されたが、Mozilla の要求で Google Research が Rust 製デコーダ jxl-rs を実装したことで復活。2026年8月24日に Mozilla と Chromium が同日 Intent to Ship を提出した
• Firefox 157（2026年9月29日予定）で既定 ON。Chrome は年内予定でマイルストーン未定。Safari は 2023年から部分対応
• 手元の計測では、可逆圧縮は JPEG XL が最小（PNG 比で 27〜33% 減）、Web 品質の非可逆は AVIF が有利という結果になった
• JPEG のバイト完全な可逆再圧縮は JPEG XL 固有の機能で、13〜15% 縮んだうえで SHA-256 が一致する形で元に戻せる
• ブラウザ側は前進したが、sharp の prebuilt に JXL が入っていないなどエンコード側のツールチェーンが遅れている。当面は CDN の自動変換か、アーカイブ用途からの導入が現実的

参考リンク

• Intent to Ship: JPEG XL - Mozilla Hacks
• JPEG XL decoding support (image/jxl) in blink - Chrome Platform Status
• libjxl - JPEG XL 参照実装
• jxl-rs - Rust 製デコーダ
• IANA Media Type: image/jxl
• Interop 2026 - JPEG XL 調査領域
• Interop 2026 JPEG XL Investigation リポジトリ
• JPEG XL 公式ページ（JPEG 委員会）
• Image file type and format guide - MDN
• Can I use: JPEG XL