# WebP to AVIF

> WebPをブラウザ内でAVIFに変換。アニメーションは1枚の静止画になり、ロスレスも非可逆になり、実測では319,834バイトが485,143バイトに増えました。

- URL: https://bytescope.dev/ja/image-convert/webp-to-avif/
- Locale: ja · Also: [en](https://bytescope.dev/en/image-convert/webp-to-avif.md) · [zh-Hant](https://bytescope.dev/zh-Hant/image-convert/webp-to-avif.md)
- Runs: ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。
- Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile.
- Updated: 2026-09-08

## What it does

### WebPからAVIFにすると失われるもの

まず動きが消えます。このサイトでWebPから出ていく経路のうち、コマが残らないのはここだけです。アニメーションとして書き出せる相手はGIFとWebPの2つで、それ以外は静止画の経路に入ります。したがって複数コマの素材は一度開かれ、アニメーションと認識されたうえで先頭のコマだけを残して閉じられ、その旨の警告が出ます。以降のコマも、コマごとの表示間隔も、ループ回数もまとめて捨てられます。アニメーションを小さくしたくて来たのなら、WebPのまま再エンコードすれば動きは残りますし、GIFでも残ります（バイト数は大きく増えますが）。

2つ目の損失は、WebPをUI素材に使っている人に効きます。ロスレスで書かれたWebPは画素が完全に一致していますが、この変換ではその約束を持ち越せません。設定のロスレスのチェックはWebPのエンコーダー用で、こちらの出力は常にスライダーの品質で非可逆に書かれます。フラットな図版、アイコン、スクリーンショット、図解 — まさにロスレスWebPの出番だった素材 — は近似になって戻り、1画素の鋭い境目があったところにぼんやりした縁が出ます。少なくともアルファは無傷で、背景は当たらず、半透明の画素も半透明のままです。

残りはファイルを画素から作り直す代償です。素材のRIFFコンテナにある`EXIF`と`ICCP`のチャンクは転送されないので、撮影情報と色の定義は消え、結果はsRGBとして読まれます。デコード後のバッファは8ビットなので、10ビットや12ビットを扱えるという形式の能力に届くものは何も渡りません。そして両側とも非可逆なので、これは2世代目です。新しいエンコーダーには1世代目のなまし具合と本物の細部を区別する手段がなく、そのまま保存します。

### 実測でファイルサイズがどう変わったか

2026-09-12、スクリプトは1280 × 854の品質85の非可逆WebP、319,834バイトを測り、品質85・速度8でAVIFに再エンコードしました。結果は485,143バイトで、約52%増です。よく引かれる15–25%という優位は、同じ非圧縮の原本から2つのエンコーダーが書き出したものを、見た目の品質を揃えてテスト画像群で比べた数字です。ここでは2つ目のエンコーダーに別の目盛りの同じ数字を指定し（libaomの85はlibwebpの85より高いところを狙います）、しかもすでに一度量子化された画像を渡しました。当然その再現にビットを使います。品質スライダーを下げてサイズ表示を見てください。スライダーの数字は形式をまたいで共通の単位ではありません。

### WebPをAVIFにしない方がよい場面

動かしておきたいアニメーションと、厳密なまま置いておきたいロスレス素材は変換しないでください。この経路が破る約束はその2つです。蔵書をまとめて変換し直すのもやめた方が無難で、同じスライダー位置ではバイト数が増えかねないうえ、1枚ごとに非可逆の世代が1つ増えます。小さな素材はそもそも意味がありません。アイコンやサムネイルはコンテナの分が大半で、コーデックに働く余地がないからです。価値があるのは大きな写真1枚を、品質を下げて結果を見比べながら変換する場合、そして配信用のコピーではなく原本から変換する場合です。

変換はすべてブラウザ内で完結します — アップロードなし、待ち行列なし、ウォーターマークなし。ファイルはいくつでもドロップでき、個別またはZIPでダウンロードできます。

## Limits

まず動きが消えます。このサイトでWebPから出ていく経路のうち、コマが残らないのはここだけです。アニメーションとして書き出せる相手はGIFとWebPの2つで、それ以外は静止画の経路に入ります。したがって複数コマの素材は一度開かれ、アニメーションと認識されたうえで先頭のコマだけを残して閉じられ、その旨の警告が出ます。以降のコマも、コマごとの表示間隔も、ループ回数もまとめて捨てられます。アニメーションを小さくしたくて来たのなら、WebPのまま再エンコードすれば動きは残りますし、GIFでも残ります（バイト数は大きく増えますが）。

2つ目の損失は、WebPをUI素材に使っている人に効きます。ロスレスで書かれたWebPは画素が完全に一致していますが、この変換ではその約束を持ち越せません。設定のロスレスのチェックはWebPのエンコーダー用で、こちらの出力は常にスライダーの品質で非可逆に書かれます。フラットな図版、アイコン、スクリーンショット、図解 — まさにロスレスWebPの出番だった素材 — は近似になって戻り、1画素の鋭い境目があったところにぼんやりした縁が出ます。少なくともアルファは無傷で、背景は当たらず、半透明の画素も半透明のままです。

残りはファイルを画素から作り直す代償です。素材のRIFFコンテナにある`EXIF`と`ICCP`のチャンクは転送されないので、撮影情報と色の定義は消え、結果はsRGBとして読まれます。デコード後のバッファは8ビットなので、10ビットや12ビットを扱えるという形式の能力に届くものは何も渡りません。そして両側とも非可逆なので、これは2世代目です。新しいエンコーダーには1世代目のなまし具合と本物の細部を区別する手段がなく、そのまま保存します。

## FAQ

### アニメーションWebPは変換後も動きますか？

動きません。先頭のコマだけが残り、警告が出ます。アニメーションとして書き出せるのはGIFとWebP自身なので、動きが要るならWebPのまま再エンコードしてください。全コマと表示間隔が残ります。GIFでも残りますが、ファイルはかなり大きくなります。

### ロスレスのWebPをこの経路に通すとどうなりますか？

非可逆になって戻ります。設定のロスレスはWebPのエンコーダー用で、こちらの出力には同等の選択肢がありません。画素が一致していた図版もスライダーの品質で近似されるので、アイコンやフラットな図版では避けたい劣化です。

### 同じ品質設定なのに、なぜ出力の方が大きいのですか？

その設定が共通の単位ではないからです。各エンコーダーが85を自分の量子化器に割り当てており、新しい側はより高いところを狙うので、一度圧縮済みの画像をより忠実に、つまりより大きく写し取りました。実測では319,834バイトが485,143バイトです。

### 画像はどこかにアップロードされますか？

いいえ。変換はcanvas APIとWeb Workerを使ってブラウザ内で行われ、ファイルがデバイスから外に出ることはありません。アップロード工程も待ち行列もなく、ファイルサイズの制限もお使いのマシンのメモリ以外にはありません。

### 変換後の画像にEXIFメタデータは残りますか？

いいえ — そしてそれは意図した機能です。canvas経由の再エンコードは、GPS位置情報、カメラの機種、タイムスタンプ、カラープロファイルといったすべてのメタデータを除去します。出力に含まれるのはピクセルだけで、画像を公開共有する前に望ましい状態になっています。

### 多くの画像を一度に変換できますか？

はい。何枚でもファイルをドロップまたは貼り付けてください。それぞれがバックグラウンドで変換され、個別の進捗とダウンロードボタンが付きます。すべてを.zipアーカイブとして一括ダウンロードすることもできます。

### 変換すると画質は落ちますか？

変換先によります。このコンバーターは、どの形式の組み合わせでも常に生のピクセルにデコードしてから再エンコードします。メタデータが除去されるのも同じ仕組みによるものです。ロスレスの変換先（PNG、および256色の範囲内のGIF）ではデコードしたピクセルと完全に同一のまま保たれ、JPEG・WebP・AVIFでは品質スライダーでトレードオフを調整できます。すでに非可逆の画像を変換すると、劣化がもう一世代ぶん重なります。