# JPG to AVIF

> JPGをブラウザ内でAVIFに再エンコード。実測では351,967バイトが480,106バイトに増えました。品質85という数字は、コーデックが違えば同じ意味になりません。

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

## What it does

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

構造として手放すものは何もありません。アルファチャンネルもコマも8ビットを超える深度も、元から入っていないからです。代わりにJPGが抱えているのは来歴で、この組み合わせの本題はそこにあります。最初のエンコーダーはすでに画面を8 × 8のブロックに切って量子化し、色を縦横とも半分の解像度で保存しました。ブロックの境目、強いエッジの周りのリンギング、にじんだ色は、いまやデコード後の画素そのものです。それを受け取るAV1エンコーダーには、ブロックの境目と屋根の輪郭、量子化の輪と本物のハイライトを見分ける手段がありません。だから前のエンコーダーの失敗まで忠実に再現し、そこにビットを費やします。元の損失が直ることはなく、上に層が1枚増えるだけです。

その2枚目の層は1枚目よりずっと穏やかで、それがこの組み合わせの唯一の本当の利点です。AV1のイントラ予測は可変サイズのブロックと方向性予測子で働くので、足りないときもブロックノイズやリンギングではなく質感が少し眠くなる方向に崩れます。ただし形式の美味しい部分は使えません。エンコーダーが受け取るのはcanvasから読み戻した8ビットRGBAなので、10ビット出力も4:4:4の色差も選べず、元のJPGが捨てた半分の色解像度も戻りません。

画素の外側はすべて落ちます。詰め替えではなくファイルを作り直すからです。撮影日時、カメラとレンズ、露出設定、GPS座標、埋め込みのICCプロファイルは出力にありません。効果だけが残るのは向きのタグで、デコーダーには表示されるべき向きの画像を要求するため、横倒しのタグが付いた写真はエンコード前に画素の側で回されます。出てくる画像は正立していますが、以後はタグを書き換えて回すことができません。

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

宣伝文句と食い違うのがこの組み合わせです。2026-09-12、スクリプトは1280 × 854の素材を品質85のJPGにして351,967バイトとし、それを品質85・速度8のAVIFにしました。結果は480,106バイト、約36%の増加です。どちらも85と書いてありますが、そこが落とし穴で、2つの目盛りは別のエンコーダーのもので、狙っている動作点も違います。libaomの85はlibjpegの85よりかなり高いところを狙います。しかもすでに劣化の入った画像を忠実に再現するよう求められるので、その分だけ高くつきます。AVIFがJPGを半分にするというよく聞く話は、非圧縮の原本から両方をエンコードし、見た目の品質を揃えて比べたものです。変換し直したときの話ではなく、この実測がその現実です。

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

見出しの数字を頼りに写真庫をまとめて変換し直すのはやめてください。この実測に照らせば、全ファイルに非可逆の世代を1つ足し、並べ替えの基準になる日付や場所を削り、そのうえ容量が増える可能性まであります。原本が残っているならそちらから書き出してください。50%という数字はその比較から出ています。印刷、メール、拡張子が固定された投稿欄、来歴のためにEXIFが要る相手にも向きません。すでに強く圧縮されたJPGも同様で、その傷を保存するためにAV1のビットを使うだけになります。自分が管理するページ用に大きな1枚を、品質スライダーを下げてサイズ表示を確かめながら変換するのは、十分に理にかなった使い方です。

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

## Limits

構造として手放すものは何もありません。アルファチャンネルもコマも8ビットを超える深度も、元から入っていないからです。代わりにJPGが抱えているのは来歴で、この組み合わせの本題はそこにあります。最初のエンコーダーはすでに画面を8 × 8のブロックに切って量子化し、色を縦横とも半分の解像度で保存しました。ブロックの境目、強いエッジの周りのリンギング、にじんだ色は、いまやデコード後の画素そのものです。それを受け取るAV1エンコーダーには、ブロックの境目と屋根の輪郭、量子化の輪と本物のハイライトを見分ける手段がありません。だから前のエンコーダーの失敗まで忠実に再現し、そこにビットを費やします。元の損失が直ることはなく、上に層が1枚増えるだけです。

その2枚目の層は1枚目よりずっと穏やかで、それがこの組み合わせの唯一の本当の利点です。AV1のイントラ予測は可変サイズのブロックと方向性予測子で働くので、足りないときもブロックノイズやリンギングではなく質感が少し眠くなる方向に崩れます。ただし形式の美味しい部分は使えません。エンコーダーが受け取るのはcanvasから読み戻した8ビットRGBAなので、10ビット出力も4:4:4の色差も選べず、元のJPGが捨てた半分の色解像度も戻りません。

画素の外側はすべて落ちます。詰め替えではなくファイルを作り直すからです。撮影日時、カメラとレンズ、露出設定、GPS座標、埋め込みのICCプロファイルは出力にありません。効果だけが残るのは向きのタグで、デコーダーには表示されるべき向きの画像を要求するため、横倒しのタグが付いた写真はエンコード前に画素の側で回されます。出てくる画像は正立していますが、以後はタグを書き換えて回すことができません。

## FAQ

### JPGをAVIFにしたらなぜ大きくなったのですか？

2つのエンコーダーを、対応していない目盛りの85どうしで並べたうえ、新しい側にすでに劣化の入った画像を忠実に再現させたからです。実測では351,967バイトが480,106バイトになりました。数字を信じず、品質を下げてサイズ表示で確かめてください。

### 品質85はどちらの形式でも同じ意味ですか？

違います。各エンコーダーがその数字を自分の量子化器に割り当てており、libaomの85はlibjpegの85よりはっきり高い忠実度を狙います。同じスライダー位置で比べるのは別々の目標を比べることで、結果が予想と逆に動く原因もそこにあります。

### 手元の写真庫をまとめて変換し直す価値はありますか？

たいていありません。全ファイルに非可逆の世代とメタデータの損失が加わり、実測では容量まで増えました。よく言われる大幅な削減は原本からエンコードした場合の話なので、蔵書をその場で作り直すより、必要な数枚を元データから変換してください。

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

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

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

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

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

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

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

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