Firefox 157 で JPEG XL のデコードが既定になる予定でも、JPG と PNG の配信を今すぐ全部差し替えない判断が妥当です。
📑目次
いま分けて見るべき事実は次の通りです。
- テクノロジー現場が決めるのは、「主要ブラウザが年内に揃うから本番を単一フォーマットにする」ことではありません。
- Mozilla の Timothy Nikkel による Intent to ship は Firefox 157 のデコード既定です。Safari 17.0（2023）は安定版でも部分実装（プログレッシブとアニメーションなし）で、Chrome の実験フラグは別件です。
読後に、次の1行を選んでください。
- 検証だけ（Nightly または Labs で
.jxlを1枚表示する） <picture>フォールバックで試験配信する- JPG・PNG のまま待ち、Chrome の Intent to ship を見る
Firefox 157でJPEG XLデコードが既定になる範囲
変わるのは Firefox 157 のデコード既定です。全ブラウザへの本番配信許可ではありません。
Nikkel のメールは、すべてのプラットフォームで JPEG XL デコードを既定にするよう求めていると書いています。いまの事実関係は次の通りです。
- 経路: Nightly の
image.jxl.enabled - Firefox 152 以降: 全チャネルの Firefox Labs にもチェック
- デコーダ: Rust の jxl-rs
- 規格: ISO/IEC 18181
- 追跡: Bug 2065096
157前の確認と残る制限
WebProNews（2026-08-24） は、157 を 2026年9月末と報じています。確定はリリースノートです。157 前に試すなら、Nightly で設定を入れるか、Labs の項目をオンにして .jxl を1枚開いてください。
ただし制限もあります。
- HDR の JPEG XL は、いま SDR として表示されます。
- Safari にはプログレッシブもアニメーションもない、と Nikkel は対比しています。
- Chrome の既定化は、このメールでは宣言されていません。
Firefox の既定化を、Chrome と Safari の既定オンと同一視しないでください。
Firefox 側の別機能を調べるときは、Firefox 無料内蔵VPN「IP Protection」の日本展開状況 も別件として切り分けてください。画像コーデックの既定と、VPN の展開は別判断です。
Safari部分実装とChrome実験フラグの差
「主要ブラウザ対応」は、実装の深さでは揃っていません。Safari は 17.0（2023）から安定版ですが、プログレッシブとアニメーションがない部分実装です。Chrome 145 以降は enable-jxl-image-format があり、既定はオフです。
ブラウザ別の実装差（2026年8月）
| 項目 | Firefox | Safari | Chrome |
|---|---|---|---|
| 2026年8月時点の既定 | Nightly のみ既定。157 で全チャネル既定の予定 | 17.0（2023）から安定版 | 145+ にデコーダ。フラグのみ |
| 有効化 | image.jxl.enabled / Labs（152〜） |
追加操作なし | chrome://flags/#enable-jxl-image-format |
| デコーダ | jxl-rs | OS 側（libjxl 系） | jxl-rs |
| プログレッシブ | あり（Hacks / Nikkel） | なし（Nikkel） | Blink 実装は feature parity と Nikkel |
| アニメーション | あり（Nikkel） | なし（Nikkel） | feature parity と Nikkel |
| 年末までの既定化 | 157（9月末報道） | 済 | Intent to ship なし（Nikkel） |
出典（2026年8月時点）:
「扱う」と既定オンは同じではない
Mozilla Hacks の「Chrome も ship 予定」は、Jake Archibald の見立てです。CyberInsider も同じ見立てを伝えています。
一次メールの Nikkel は、Chrome に Intent to ship はまだないと書いています。年末までに「扱う」ことと、既定オンは同じではありません。
Neowin は、Chrome 110 が 2022年末に対応を外した経緯も書いています。いまの 145+ フラグは、その後の実験経路です。Chromium 系（Edge など）がフラグを継承していても、各ベンダーの既定は別確認です。
JPEG XLとAVIF・既存JPGの使い分け
ウェブ写真の小ささなら AVIF が有利な例が多く、可逆・プログレッシブ・既存 JPEG の可逆再圧縮なら JPEG XL です。テクノロジー判断を「新しい方が常に小さい」にしないでください。
Mozilla Hacks は、同一のキツネ画像を使って次の kB 値を示しています。
Mozilla Hacksの同一キツネ画像
| 条件 | AVIF | JPEG XL | 可逆 WebP |
|---|---|---|---|
| SSIMULACRA 2 62.8（中高品質） | 116 kB | 134 kB | — |
| SSIMULACRA 2 80（高品質） | 227 kB | 264 kB | — |
| 可逆 | 1.76 MB | 1.45 MB | 1.55 MB |
出典：Mozilla Hacks Intent to Ship JPEG XL（2026年8月時点）
プログレッシブの例では、完成が 135 kB、数 kB で被写体が分かる、と Hacks は書いています。Interop 2025 の別スクショでは、SSIMULACRA 2 78 で AVIF 11.6 kB / JPEG XL 23.8 kB、可逆では AVIF 164 kB / JPEG XL 92 kB / WebP 96 kB です。数字は1枚または少数の例です。自サイトの代表画像で測ってください。
可逆JPEGとAVIFが残る場合
JPEG.org は、既存 JPEG を可逆トランスコードでき、元 JPEG をバイト一致で復元できる、と仕様として書いています。サーバーは JPEG XL を1本持ち、JPEG クライアントへ戻す運用も想定しています。
- 典型圧縮比 20:1〜50:1 は用途次第です。
- Neowin と Windows Report は、JPEG から約 20% 縮小と書いています。
- これはブラウザ既定とは独立に、アーカイブ再パックだけで試せます。
CyberInsider も、JPEG XL が AVIF を全面的に置き換えるとは書いていません。Hacks の案内は次の通りです。
- 可逆・プログレッシブ・JPEG の品質を落とさない再圧縮は JPEG XL
- 通常のウェブ品質の写真と、鋭いエッジと平坦部が混ざる画像は AVIF
- AVIF のプログレッシブは基本的、と Mozilla は書いています
納品物がビットマップ固定か、編集可能なネイティブかが先に来る案件では、編集できるPPTXか画像スライドかを決める判断 の切り分けが先です。コーデック比較の前に、成果物の形を決めてください。
テクノロジー現場がJPG/PNG配信を変える前の確認リスト
次の一手は、CDN の MIME タイプとフォールバックを決め、Chrome の既定化を待たずに全面切替しないことです。
判断基準は3つあります。
- 対象は写真か、可逆グラフィックか、巨大画像の初期表示か。
- 受信側で、Safari の部分実装と Chrome のフラグオフを許容できるか。
- 既存 JPEG アーカイブの可逆再パックだけで足りるか（ブラウザ不要）。
確認手順は次の通りです。
- Nightly または Labs で
.jxlを表示する。 <picture>で JPEG XL → AVIF/WebP → JPEG/PNG の順を試験する。- オリジンまたは CDN が
image/jxlを返せるか確認する。 - Chrome の Intent to ship が出るまで、メインビジュアルの単一フォーマット化は保留する。
試験配信の骨組み例です。
<picture>
<source type="image/jxl" srcset="hero.jxl">
<source type="image/avif" srcset="hero.avif">
<source type="image/webp" srcset="hero.webp">
<img src="hero.jpg" alt="代表画像" width="1200" height="800">
</picture>
⚠️ Chrome 145+ で見るには、chrome://flags/#enable-jxl-image-format を Enabled にして再起動します。フラグなしの利用者には、JPEG XL 単体 URL は見えません。公開ページの単一 .jxl は、いまの受信側では壊れます。
生成画像の公開前確認は、コーデックとは別問題です。見た目の出所が曖昧な素材は、AIイラストの公開前確認手順 で先にラベルと権利を見てください。
よくある質問
Firefox 157 でユーザー操作なしに JPEG XL が見えるか？
その予定です。Nikkel の Intent to ship は、全プラットフォーム既定です。時期は WebProNews が 2026年9月末と報じています。確定はリリースノートです。
いま Chrome で見るには？
Chrome 145 以降で enable-jxl-image-format を Enabled にし、再起動します。既定オンではありません。Google が既定にした、という一次宣言は 2026年8月時点ではありません。
Safari は足りるか？
17.0（2023）から安定版です。Nikkel は、プログレッシブとアニメーションがない、と書いています。部分実装として扱ってください。巨大画像の初期表示やアニメーションを JPEG XL に寄せるなら、Safari だけでは足りません。
AVIF をやめてよいか？
Hacks の例では、ウェブ品質の写真は AVIF の方が小さいです。可逆とプログレッシブは JPEG XL が強い例があります。用途別に測ってください。やめない、が既定の答えです。
既存 JPG を捨てる必要があるか？
ありません。JPEG.org は、可逆トランスコードと元 JPEG 復元を仕様の一部としています。アーカイブ用途は、ブラウザ既定と独立に試せます。公開配信の JPG/PNG を消す判断とは分けてください。
関連記事:
- Web API設計の基準【2026年版】｜エラー・認証・バージョニング
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
- MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
まとめ
157 で Firefox のデコード既定は動く見込みです。Safari は部分実装、Chrome はフラグです。JPG/PNG の全面置換はまだ早いです。
テクノロジー現場が今週できることは、Nightly で1枚試し、<picture> フォールバックを1経路用意し、Chrome の Intent to ship を待つことです。読後の1行は、「検証だけ / 試験配信 / 待つ」のどれかにしてください。
残る不確実性は、Chrome 既定化の時期、Safari がプログレッシブとアニメーションを足すか、Hacks の kB が自サイトで再現するか、です。年末までの「対応」見出しを、既定オンの許可には使わないでください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す