JPEG XL（JXL）とは？JPEG・PNG・WebPとの違いとDjangoへの安全な導入方法を解説

JPEG XL（JXL）とは？JPEG・PNG・WebPとの違いとDjangoへの安全な導入方法を解説

初回公開: 2026年8月28日 / 最終確認: 2026年8月28日

この記事の要点

• JPEG XLは非可逆圧縮と可逆圧縮、HDR、透過、アニメーション、プログレッシブ表示に対応する次世代画像形式である。
• JPEGからJPEG XLへ画質を変えずに再圧縮し、元のJPEGを再構築できる機能がJPEG XLの大きな特徴である。
• 2026年8月時点ではSafariがJPEG XLを実装済みで、ChromeとFirefoxも正式搭載へ向けて動いている。
• 現時点のWebサイトではJPEG XLだけを配信せず、<picture>でJPEG・PNG・WebPなどのフォールバックを残すべきである。
• Djangoでは元画像をImageFieldに保存し、JPEG XLを派生ファイルとして生成する構成が安全で移行しやすい。
• Pillow 12.3.0ではJPEG XLを標準対応形式として扱えないため、libjxlまたは外部Pillowプラグインが必要になる。
• libjxlを利用する場合は古いディストリビューションパッケージを無条件に使わず、セキュリティ修正を含む最新版を確認する必要がある。

結論：JPEG XLは有望だが、2026年8月時点では「追加配信」が正解

JPEG XL（ジェイペグ・エックスエル、拡張子.jxl）は、従来のJPEGを置き換える可能性を持つ次世代画像形式です。

JPEG XLはISO/IEC 18181として標準化されています。非可逆圧縮だけでなく可逆圧縮、HDR、広色域、高ビット深度、アルファチャンネル、アニメーション、プログレッシブ表示などを1つの形式で扱えます。

特に興味深い機能が、既存JPEGを画質劣化なしでJPEG XLへ再圧縮できることです。

libjxlではJPEGを入力すると、JPEGビットストリームをJPEG XLコンテナへ可逆的に変換できます。対応するJPEGであれば、後から元のJPEGを再構築できます。

ただし、2026年8月28日時点ではブラウザー対応が完全ではありません。

Safariは17.0からJPEG XLをサポートしています。一方、Chrome 145ではJPEG XLデコーダが導入されたもののフラグや試験機能として扱われています。Mozillaは2026年8月24日にFirefoxへの正式搭載方針を発表しました。Chrome側も正式有効化へ動いています。

したがって、現時点で推奨する構成は次です。

JPEG / PNG / WebP
        │
        │ Djangoへアップロード
        ▼
   元画像を保存
        │
        ├───────────────┐
        │               │
        ▼               ▼
   JPEG XL生成       元画像を維持
        │               │
        └──────┬────────┘
               ▼
          <picture>
               │
        ┌──────┴──────┐
        ▼             ▼
  JXL対応ブラウザー   非対応ブラウザー
      .jxl          JPEG/PNG/WebP

元画像をJPEG XLへ置き換えて削除するのではなく、JPEG XLを追加の配信形式として生成する設計がおすすめです。

この記事で分かること

この記事では次の内容を扱います。

• JPEG XLとは何か
• JPEG・PNG・WebP・AVIFとの違い
• JPEG XLの圧縮方式
• JPEGから無劣化で変換できる仕組み
• 2026年8月時点のブラウザー対応状況
• DjangoとJPEG XLの関係
• libjxlを利用したJPEG XL生成
• Djangoモデル設計
• <picture>を使ったフォールバック配信
• NginxのMIMEタイプ設定
• 動作確認方法
• セキュリティ上の注意点
• 本番導入で避けるべき設計

対象読者・前提環境

この記事は次の環境を想定しています。

Django 5.2はLTSです。2026年8月4日にはセキュリティ修正版のDjango 5.2.17も公開されています。

JPEG XLとは

JPEG XLは、JPEG Committeeが策定した新しい画像圧縮規格です。

正式な規格は次の4部で構成されています。

リファレンス実装がlibjxlです。

拡張子は次のようになります。

.jxl

MIMEタイプはIANAへ正式登録されています。

image/jxl

JPEG・PNG・WebP・AVIF・JPEG XLを比較

JPEG XLの位置付けを理解するには、既存形式と比較するのが一番分かりやすいでしょう。

画像形式比較表

JPEG、PNG、WebP、AVIFについてはMDNでもWeb向け画像形式として案内されています。WebPは非可逆・可逆圧縮、アルファ、アニメーションを扱えます。

JPEG XLはこれらの多くの機能を1つの形式へ統合した設計になっています。

JPEG XLは本当にJPEGより小さくなるのか

ここは誤解されやすいポイントです。

「JPEG XLなら必ず○％小さくなる」と考えてはいけません。

画像の内容、解像度、元画像、品質設定、エンコーダー設定によって結果は変化します。

ただし、JPEG XLには既存JPEGをそのまま再圧縮する特殊なモードがあります。

WebKitはSafari 17でJPEG XLを導入した際、既存JPEGの可逆再圧縮について平均約20％程度の削減、新しい元画像からの圧縮ではJPEGに対して最大60％程度小さくなるケースがあると説明しています。これは保証値ではなく、実際のサイトでは自分の画像を使って測定する必要があります。

Mozillaが2026年に公開した比較でも、興味深い結果が出ています。

Web向け非可逆圧縮ではAVIFがJPEG XLより小さくなった例がある一方、可逆圧縮ではJPEG XLがAVIFやWebPより小さくなった例があります。

つまり、

JPEG XL = 常に最小

ではありません。

実際には、

写真の低～中ビットレート
        ↓
AVIFが強い場合がある

高品質写真
        ↓
JPEG XLが有力

可逆画像
        ↓
JPEG XLが有力

巨大画像
        ↓
JPEG XLのプログレッシブ表示が有利

既存JPEG資産
        ↓
JPEG XLのJPEG再圧縮が非常に有力

という使い分けになります。

JPEGを「無劣化」でJPEG XLへ変換できる

JPEG XL最大の特徴の1つです。

普通の画像変換では、

JPEG
 ↓ デコード
RGB画像
 ↓ 再エンコード
WebP / AVIF / JPEG

となります。

JPEGは一度展開して再圧縮すると、新たな量子化誤差が発生する可能性があります。

JPEG XLには別の方法があります。

JPEG bitstream
      │
      ▼
JPEG XLコンテナへ可逆変換
      │
      ▼
     .jxl
      │
      ▼
元JPEGを再構築可能

libjxlのcjxlはJPEG入力に対して、この可逆再圧縮を標準動作として利用できます。djxl側では元JPEGの再構築も可能です。

大量のJPEG画像を保管している写真サイトやブログでは非常に興味深い機能です。

JPEG XLのプログレッシブ表示

プログレッシブ表示とは、

ダウンロードが全部終わるまで真っ白にするのではなく、途中段階から粗い画像を表示して徐々に鮮明にする仕組み

です。

JPEG XLではプログレッシブデコードを重要な機能として設計しています。

Mozillaが公開した例では、JPEG XL画像の一部分だけを受信した段階でも画像の概要を表示できることが紹介されています。

大きな写真では、

0 KB       30 KB        80 KB       完了
 │           │            │           │
 ▼           ▼            ▼           ▼
ぼんやり → 概要判明 → かなり鮮明 → 完全表示

となります。

Core Web VitalsのLCPが直接必ず改善するわけではありませんが、ユーザーが感じる画像表示待ち時間を短くできる可能性があります。

2026年8月のブラウザー対応状況

JPEG XLをWebサイトへ導入するとき、最大の問題はここです。

Safari

SafariはSafari 17.0からJPEG XLをサポートしています。

AppleのSafari 17 Release NotesにもJPEG XL追加が明記されています。

ただし、Safari実装には機能差があります。

MDN Browser Compatibility DataではSafariのJPEG XLについて、アニメーション画像は未対応とされています。

Chrome

Chromeでは以前JPEG XLが実験的に実装された後、一度削除されました。

その後状況が変わりました。

Chrome 145ではRust製のjxl-rsを利用したJPEG XLデコーダが導入され、フラグ・試験機能として利用できるようになっています。

2026年8月には正式有効化へ向けた動きも進んでいます。

Firefox

Firefoxも以前から実験的なJPEG XL実装を持っていました。

Mozillaは2026年8月24日、JPEG XLを正式に提供する方針を発表しました。

新実装ではC++のlibjxlではなく、メモリ安全性を重視したRust製jxl-rsが採用されています。

MozillaはChrome側も正式搭載へ向けて動いており、主要ブラウザーでの対応が進むとの見通しを示しています。

なぜJPEG XLはすぐ普及しなかったのか

JPEG XLの規格自体は新しくありません。

しかしブラウザー実装では、画像圧縮性能だけでなくデコーダーの攻撃面も重要になります。

画像ファイルは外部ユーザーから送られてくることがあります。

つまり画像デコーダーは、

攻撃者が作った画像
        ↓
画像デコーダー
        ↓
メモリ破壊バグ
        ↓
ブラウザー / サーバーへの攻撃

という入口になり得ます。

Mozillaは従来のlibjxlが大規模なマルチスレッドC++コードであることを懸念し、安全で高速なRustデコーダーの実装をJPEG XLチームへ求めたと説明しています。

その結果生まれたjxl-rsがFirefoxとChromiumの新しいJPEG XL実装へ使われています。

DjangoではJPEG XLをどう導入するか

ここから実装です。

最初に重要な点があります。

DjangoのImageFieldだけではJPEG XLを扱えない場合がある

DjangoのImageFieldは画像解析そのものを行っているわけではありません。

実際にはPillowを利用しています。

Django ImageField
       │
       ▼
     Pillow
       │
       ▼
JPEG / PNG / WebP / ...

Django公式ドキュメントでも、ImageFieldが利用する画像形式はPillow側の対応状況へ依存すると説明されています。

2026年7月公開のPillow 12.3.0の公式ビルドドキュメントには、JPEG、PNG、WebP、AVIF、JPEG 2000などが記載されていますが、JPEG XLは標準対応ライブラリとして掲載されていません。

そのため、

image = models.ImageField(...)

へ.jxlをそのまま投入できることを前提にする設計はおすすめしません。

推奨するDjango構成

おすすめは次です。

flowchart LR
    U[ユーザー] -->|JPEG / PNG / WebP| D[Django]
    D --> O[(Original Image)]
    O --> W[Background Worker]
    W --> J[cjxl]
    J --> X[(JPEG XL)]
    O --> T[Django Template]
    X --> T
    T --> P[picture要素]
    P --> B{ブラウザー}
    B -->|JXL対応| X
    B -->|JXL非対応| O

ポイントは、

JPEG XLを原本にしない

ことです。

モデルは例えば次のようにします。

from django.db import models


class ArticleImage(models.Model):
    source = models.ImageField(
        upload_to="images/source/",
        width_field="width",
        height_field="height",
    )

    jxl = models.FileField(
        upload_to="images/jxl/",
        blank=True,
    )

    alt = models.CharField(
        max_length=255,
        blank=True,
    )

    width = models.PositiveIntegerField(
        null=True,
        editable=False,
    )

    height = models.PositiveIntegerField(
        null=True,
        editable=False,
    )

    created_at = models.DateTimeField(auto_now_add=True)

重要なのは、

source = ImageField()
jxl = FileField()

という違いです。

sourceはPillowで検証します。

一方、.jxlはサーバー自身が生成した派生ファイルなので、FileFieldとして管理できます。

libjxlをインストールする

JPEG XLの公式リファレンス実装がlibjxlです。

cjxlがエンコーダーです。

djxlがデコーダーです。

Debian / Ubuntu系で確認する

目的

cjxlとdjxlを利用可能にします。

実行場所

Djangoアプリケーションサーバーまたは画像変換専用Workerです。

sudo apt update
sudo apt install libjxl-tools

libjxl公式もDebian系Linuxではlibjxl-toolsを案内しています。

正常例

cjxl --version

例:

cjxl v0.12.0

異常例

cjxl: command not found

この場合はインストールされていません。

libjxlのバージョンには注意する

ここは2026年現在、かなり重要です。

libjxlの公式リポジトリは、多数のセキュリティ修正が入ったv0.12への更新を強く推奨しています。

v0.12では、

• integer overflow / underflow
• out-of-bounds read
• out-of-bounds write
• buffer overflow
• NULL pointer関連

など、多数のhardeningが行われています。

したがって、

sudo apt install libjxl-tools

だけで安心してはいけません。

必ず、

cjxl --version
djxl --version

を確認してください。

特にディストリビューションによっては古いパッケージが提供されています。

例えばEPEL 10では2026年時点でも0.10.4系が掲載されています。

本番サーバーでは、ディストリビューションのバージョンと上流のセキュリティ情報を両方確認してください。

JPEG XLへ変換してみる

PNG → JPEG XL

目的

PNG画像をJPEG XLへ変換します。

cjxl input.png output.jxl

正常例

Compressed to 182345 bytes

output.jxlが生成されれば成功です。

異常例

Error reading input

入力画像破損や未対応形式などを確認します。

Web向けJPEG XLの品質を指定する

libjxlでは--distanceが利用できます。

例えば、

cjxl input.png output.jxl --distance=1.0

です。

distanceは小さいほど高品質になります。

libjxlは概ね次の範囲を実用的な非可逆圧縮として案内しています。

0.5 ～ 3.0

0は可逆圧縮です。

Web画像では、まず、

--distance=1.0

前後から比較する方法がおすすめです。

JPEG → JPEG XL

既存JPEGならさらに簡単です。

cjxl input.jpg output.jxl

JPEG入力ではlibjxlがJPEG再構築情報を保持した可逆変換を利用できます。

ただし、

変換成功
↓
即座に元JPEG削除

はおすすめしません。

本番環境では必ず、

変換
↓
デコード確認
↓
JPEG再構築確認
↓
ハッシュ・画素確認
↓
バックアップ
↓
必要なら原本整理

の順番にします。

Djangoからcjxlを呼び出す

subprocessを利用する場合は、shell=Trueを使わないことが重要です。

例えば画像変換処理を次のように作れます。

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess

from django.core.files import File


def generate_jxl(article_image):
    source_suffix = Path(article_image.source.name).suffix.lower()

    with TemporaryDirectory() as tmp:
        tmp_dir = Path(tmp)

        source_path = tmp_dir / f"source{source_suffix}"
        output_path = tmp_dir / "output.jxl"

        article_image.source.open("rb")

        with source_path.open("wb") as dst:
            for chunk in article_image.source.chunks():
                dst.write(chunk)

        result = subprocess.run(
            [
                "cjxl",
                str(source_path),
                str(output_path),
                "--distance=1.0",
                "--effort=7",
            ],
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            check=True,
            timeout=30,
            shell=False,
        )

        if not output_path.exists():
            raise RuntimeError("JPEG XL output was not generated")

        output_name = (
            f"{Path(article_image.source.name).stem}.jxl"
        )

        with output_path.open("rb") as fp:
            article_image.jxl.save(
                output_name,
                File(fp),
                save=False,
            )

        article_image.save(
            update_fields=["jxl"],
        )

    return result.returncode

なぜshell=Falseにするのか

例えば危険な実装として、

subprocess.run(
    f"cjxl {filename} output.jxl",
    shell=True,
)

があります。

ユーザーがファイル名を操作できる場合、シェルインジェクションへつながる可能性があります。

安全側では、

[
    "cjxl",
    input_path,
    output_path,
]

のように引数を分離します。

さらに、

timeout=30

などを設定し、異常に時間のかかる画像でWorkerが占有され続けることを防ぎます。

画像変換はHTTPリクエスト中に実行しない

次の設計は避けるべきです。

画像UPLOAD
   ↓
Django View
   ↓
cjxl
   ↓
変換完了まで待つ
   ↓
HTTP Response

JPEG XLのエンコードはCPUを利用します。

高いeffortを設定するとさらに時間がかかります。

おすすめは、

UPLOAD
  ↓
原本保存
  ↓
HTTP 200
  ↓
Job Queue
  ↓
JPEG XL生成

です。

Celery、RQなどを利用している場合はバックグラウンドWorkerへ渡します。

例えば、

from django.db import transaction


transaction.on_commit(
    lambda: generate_jxl_task.delay(image.pk)
)

という構成にできます。

DjangoテンプレートからJPEG XLを配信する

JPEG XLだけをimgへ指定するのではなく、pictureを使います。

<picture>
    {% if image.jxl %}
        <source
            srcset="{{ image.jxl.url }}"
            type="image/jxl"
        >
    {% endif %}

    <img
        src="{{ image.source.url }}"
        alt="{{ image.alt }}"
        width="{{ image.width }}"
        height="{{ image.height }}"
        loading="lazy"
        decoding="async"
    >
</picture>

JXL対応ブラウザーでは、

image.jxl

が選択されます。

非対応ブラウザーでは、

image.source

が表示されます。

WebKitもJPEG XL導入時に<picture>を利用したフォールバックを推奨しています。

WebPも併用する場合

より積極的に最適化するなら、

<picture>

    <source
        srcset="/media/photo.jxl"
        type="image/jxl"
    >

    <source
        srcset="/media/photo.webp"
        type="image/webp"
    >

    <img
        src="/media/photo.jpg"
        alt="サンプル画像"
    >

</picture>

とできます。

ブラウザーは上から対応可能な形式を探します。

JPEG XL対応
    ↓
JXL

JXL非対応・WebP対応
    ↓
WebP

両方非対応
    ↓
JPEG

現時点では非常に実用的な構成です。

Nginxでimage/jxlを設定する

JPEG XLのMIMEタイプは、

image/jxl

です。

NginxのMIMEマッピングへ.jxlが存在しない場合は追加します。

例えばmime.typesへ、

image/jxl    jxl;

を追加します。

設定変更後は、まず構文を確認します。

目的

Nginx設定に構文エラーがないことを確認します。

実行場所

Nginxサーバー。

sudo nginx -t

正常例

syntax is ok
test is successful

異常例

nginx: [emerg]

この場合はreloadしないでください。

正常確認後に、

sudo systemctl reload nginx

します。

Content-Typeを確認する

目的

JPEG XLが正しいMIMEタイプで返されているか確認します。

curl -I https://example.com/media/photo.jxl

正常なら、

HTTP/2 200
content-type: image/jxl

となります。

次のようになっていたら修正が必要です。

content-type: application/octet-stream

JPEG XLが本当に壊れていないか確認する

djxlを利用します。

djxl output.jxl decoded.png

正常ならPNGへデコードできます。

さらに、

file decoded.png

などで確認します。

JPEGから可逆変換した場合は、JPEG再構築もテストします。

libjxl 0.12ではJPEG再構築を要求する--reconstruct_jpegオプションも追加されています。

PillowからJPEG XLを直接扱いたい場合

サードパーティーのPillowプラグインも存在します。

代表例としてpillow-jxl-pluginがあります。

python -m pip install pillow-jxl-plugin

利用例は次です。

import pillow_jxl
from PIL import Image


with Image.open("input.png") as image:
    image.save(
        "output.jxl",
        quality=90,
    )

プラグインはJPEG XLのエンコード・デコードやEXIF処理などを提供しています。

ただし、本記事ではDjango本番環境の標準構成としてはlibjxl方式を優先します。

理由は、

1. Pillow標準機能ではない
2. DjangoのImageFieldとの初期化順序まで考慮する必要がある
3. サードパーティープラグインの更新状況とライセンスを追加確認する必要がある

からです。

特にpillow-jxl-pluginはGPL-3.0で公開されています。プロジェクトの配布形態によってはライセンス確認も必要です。

JPEG XLファイルをユーザーから直接アップロードさせるべきか

最初の導入ではおすすめしません。

おすすめは、

JPEG
PNG
WebP
  ↓
Django ImageFieldで検証
  ↓
サーバー側でJPEG XL生成

です。

つまり、

JPEG XLは入力形式ではなく出力形式から導入する

という考え方です。

この方が、

• Django/Pillowとの互換性
• セキュリティ
• バリデーション
• 管理画面
• サムネイル生成
• EXIF処理

を既存環境のまま維持できます。

動作確認

本番反映前に最低でも次を確認します。

1. cjxl

cjxl --version

最新版・セキュリティ修正版か確認します。

2. JPEG XL生成

cjxl test.jpg test.jxl

test.jxlが作成されることを確認します。

3. デコード

djxl test.jxl decoded.png

正常にデコードできることを確認します。

4. Django

python manage.py check

正常例:

System check identified no issues

5. HTTP

curl -I https://example.com/media/test.jxl

確認項目:

HTTP 200
Content-Type: image/jxl

6. ブラウザー

SafariなどJPEG XL対応ブラウザーでDevToolsを開きます。

Networkから、

test.jxl

が実際に取得されていることを確認します。

本番導入前に比較テストする

画像形式は理論値だけで選ばない方がよいです。

例えば100～1000枚程度の実画像を用意します。

測定項目は、

です。

平均値だけでなく、

p50
p95
最大値

も確認すると実運用に近い評価になります。

再発防止・運用設計

JPEG XLを導入した後は、画像形式をコードへ直書きし過ぎない方がよいでしょう。

例えば、

class ImageVariant(models.Model):
    FORMAT_CHOICES = [
        ("jpeg", "JPEG"),
        ("png", "PNG"),
        ("webp", "WebP"),
        ("avif", "AVIF"),
        ("jxl", "JPEG XL"),
    ]

    image = models.ForeignKey(
        ArticleImage,
        on_delete=models.CASCADE,
    )

    format = models.CharField(
        max_length=16,
        choices=FORMAT_CHOICES,
    )

    file = models.FileField(
        upload_to="images/variants/",
    )

    size_bytes = models.PositiveBigIntegerField()

    encoder_version = models.CharField(
        max_length=64,
        blank=True,
    )

のような派生画像モデルにすると、

Original
 ├── JPEG XL
 ├── WebP
 └── AVIF

を管理できます。

さらに、

encoder
encoder_version
quality
distance
effort
generated_at

を保存しておけば、エンコーダー更新後の再生成も簡単です。

libjxl更新時には再検証する

画像デコーダーはセキュリティ上重要なコンポーネントです。

実際、libjxl 0.11.2ではCVE-2025-12474やCVE-2026-1837などが修正され、その後の0.12でも多数のhardeningが行われています。

したがって、

libjxl更新
   ↓
単体テスト
   ↓
代表画像変換
   ↓
巨大画像
   ↓
壊れた画像
   ↓
メモリ使用量
   ↓
CPU使用量
   ↓
本番反映

という流れを作っておくと安全です。

注意点・JPEG XLを急いで全面採用しない方がよい理由

JPEG XLには魅力がありますが、否定的に見るべき点もあります。

1. ブラウザー対応はまだ完全ではない

2026年8月はChromeとFirefoxが正式搭載へ大きく動いたタイミングです。

しかし、

主要ブラウザーが対応予定

と、

現在すべての利用者が利用可能

は別の話です。

しばらく<picture>によるフォールバックは必要です。

2. Django + Pillowではまだ標準的な形式ではない

JPEGやPNG、WebPほど簡単ではありません。

Pillow 12.3.0の標準機能だけで、

Image.open("photo.jxl")

を当然に利用できる環境とは言えません。

JPEG XL導入によって、

• libjxl
• 外部Worker
• MIME設定
• <picture>
• キャッシュ管理

などの運用要素が増えます。

画像数が少ないサイトでは、複雑化に見合う効果が出ない可能性があります。

3. libjxlにはセキュリティ修正が継続している

libjxl 0.12では多数のメモリ安全性関連修正が行われています。

さらに上流自身がリリースについて、最新バージョンを利用するよう注意を出しています。

ユーザー投稿JPEG XLを無制限に直接デコードする構成は慎重に扱うべきです。

画像処理Workerを、

Web Process
    │
    ▼
Queue
    │
    ▼
制限されたImage Worker

へ分離する設計も検討できます。

4. AVIFの方が小さくなる画像もある

「次世代形式だからJPEG XLがAVIFより優れている」と単純には言えません。

Mozillaが公開した比較でも、Web品質の非可逆画像ではAVIFが小さくなる例があります。

したがって、

JPEG XLかAVIFか

ではなく、

実画像で両方測る

ことが正解です。

よくある誤解

JPEG XLはJPEGのバージョンアップ版だから.jpgのまま使える？

使えません。

JPEG XLは別形式です。

JPEG      .jpg / .jpeg
JPEG XL   .jxl

MIMEタイプも異なります。

JPEG XLに変換すれば必ず画質が上がる？

上がりません。

既存JPEGを可逆再圧縮した場合、元JPEG以上の情報が復活するわけではありません。

JPEG XLは既存JPEGをより効率的に保持できますが、失われたディテールを復元する技術ではありません。

JPEGをJPEG XLにしたら元JPEGを削除してよい？

すぐに削除するのはおすすめしません。

少なくともブラウザー対応が十分に普及するまでは、フォールバックとして残す価値があります。

WebPはJPEG XLが普及したら不要になる？

当面は不要になりません。

WebPはすでに主要ブラウザーへ広く普及しており、ツールやCDNの対応も成熟しています。

JPEG XLとは役割がしばらく共存すると考えた方が現実的です。

JPEG XLはどんなサイトに向いているか

特に向いているのは、

• 写真を大量に保管しているサイト
• 高解像度画像を提供するサイト
• HDR画像を扱うサイト
• デジタルアーカイブ
• 写真共有サービス
• ECサイト
• 画像CDN
• 大量のJPEG資産を持つサイト

です。

逆に、

画像が数十枚しかない

ような小規模サイトでは、JPEG XL対応の運用コストの方が大きくなる場合があります。

推奨する2026年の構成

現時点なら次の構成をおすすめします。

                    ┌── JPEG XL
Original ─ Worker ──┤
                    ├── WebP
                    └── AVIF
                         │
                         ▼
                    Django Template
                         │
                         ▼
                      <picture>

優先順位はサイトによって変えて構いません。

例えば、

<picture>

    <source
        srcset="photo.jxl"
        type="image/jxl"
    >

    <source
        srcset="photo.avif"
        type="image/avif"
    >

    <source
        srcset="photo.webp"
        type="image/webp"
    >

    <img
        src="photo.jpg"
        alt="サンプル画像"
    >

</picture>

という構成もできます。

ただし、形式を増やせばストレージ使用量も増えます。

そのため、

JXL + JPEG

または、

JXL + WebP + JPEG

程度から始める方が管理しやすいでしょう。

まとめ

JPEG XLは、単なる「JPEGより少し圧縮率の高い画像形式」ではありません。

JPEG XLは、

非可逆圧縮
+
可逆圧縮
+
JPEG可逆再圧縮
+
HDR
+
広色域
+
高ビット深度
+
アルファ
+
アニメーション
+
プログレッシブ表示

をまとめて扱える次世代画像規格です。

そして2026年8月、状況が大きく変わっています。

SafariはすでにJPEG XLを実装しています。

ChromeはRust製JPEG XLデコーダーをChrome 145へ導入しています。

Firefoxも2026年8月24日に正式搭載方針を発表しました。

そのため、JPEG XLをWebで検証し始めるにはかなり良いタイミングです。

ただし、現時点でJPEG・PNG・WebPをすべてJPEG XLへ置き換える必要はありません。

Djangoでは、

ImageField
   ↓
JPEG / PNG / WebPを原本保存
   ↓
Background Worker
   ↓
libjxl
   ↓
.jxl生成
   ↓
<picture>
   ↓
非対応ブラウザーは原本へfallback

という構成が安全です。

JPEG XLを「置き換え」として導入するのではなく、「追加の最適化レイヤー」として導入する。

2026年時点では、この考え方が最も実務的です。

FAQ

Q. JPEG XLの拡張子は？

.jxlです。

Q. MIMEタイプは？

image/jxl

です。IANAへ正式登録されています。

Q. JPEG XLは可逆圧縮できますか？

できます。

JPEG XLは非可逆圧縮と可逆圧縮の両方に対応しています。

Q. PNGの代わりになりますか？

用途によっては可能です。

特に可逆圧縮、透過、高ビット深度を必要とする画像では候補になります。

ただしブラウザー互換性を考えると、現時点でPNGを完全に削除する必要はありません。

Q. WebPより小さくなりますか？

画像によります。

JPEG XLが有利な画像もありますが、必ず小さくなるわけではありません。

実画像で比較してください。

Q. AVIFとJPEG XLではどちらがおすすめ？

Web向け低～中ビットレート写真ではAVIFが有利になる場合があります。

一方、JPEG XLには、

• 可逆圧縮
• JPEG可逆再圧縮
• プログレッシブ表示
• 高品質画像

という強みがあります。

両方をベンチマークするのがおすすめです。

Q. Django ImageFieldへ直接JXLを保存できますか？

2026年8月時点では標準構成としておすすめしません。

DjangoのImageFieldはPillowへ依存しており、Pillow 12.3.0の公式標準対応形式としてJPEG XLは掲載されていません。

元画像をImageFieldへ保存し、JPEG XL派生ファイルをFileFieldへ保存する方法が扱いやすいです。

Q. JPEG XLを今すぐ本番導入してもよい？

JPEG XLのみの配信はおすすめしません。

<picture>でフォールバックを用意するなら、本番環境でも段階的な検証を始められます。

参考情報

JPEG XL / JPEG Committee

JPEG XLはISO/IEC 18181として標準化されています。

JPEG XL公式サイト

libjxl

JPEG XLのリファレンス実装です。

2026年7月公開のv0.12では多数のセキュリティ・hardening修正が行われています。

libjxl公式リポジトリ

Safari 17 Release Notes

Safari 17でJPEG XLサポートが追加されています。

Safari 17 Release Notes

WebKit Features in Safari 17

JPEG XLのプログレッシブ表示やJPEG可逆再圧縮、<picture>の利用例が紹介されています。

WebKit Features in Safari 17

Mozilla – Intent to Ship: JPEG XL

2026年8月24日に公開されたFirefoxのJPEG XL正式搭載方針です。Rust製jxl-rs採用やAVIFとの比較についても説明されています。

Mozilla Hacks – Intent to Ship: JPEG XL

Chrome 145 Release Notes

Rust製jxl-rsを利用したJPEG XLデコーダーについて説明されています。

Chrome 145 Release Notes

Django ImageField

DjangoのImageFieldとPillowの関係について確認できます。

Django 5.2 ImageFieldドキュメント

Pillow

2026年7月時点の安定版ドキュメントはPillow 12.3.0です。

Pillow公式ドキュメント