# JPG to WebP

> JPGを端末内でWebPへ再エンコード。実測の縮小は9.7%どまりで、EXIFとICCプロファイルは消え、向きの情報は画素そのものに焼き込まれます。アップロードはありません。

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

## What it does

### JPGをWebPにすると失われるもの

構造としては、ほとんど何も失いません。元のJPGにはアルファチャンネルもフレームもないので、新しい入れ物が落とすものがそもそもないからです。失われるのはメタデータと世代です。撮影日時、カメラとレンズ、露出設定、GPS座標といったEXIFは丸ごと消え、埋め込まれたICCプロファイルも残りません。詰め替えではなく、画素に戻してから改めてエンコードするためです。スマートフォンで撮った写真なら、あとからライブラリで探す手がかりの大半がこれに当たります。同時に、公開前に消しておきたい情報そのものでもあります。

向きだけは扱いが違うので覚えておく価値があります。デコーダーには「表示されるべき姿」で画像を要求するので、EXIFの`Orientation`が四分の一回転を指示している写真は、エンコード前に画素の側が回されます。タグ自体は消えても、出力はどこで開いても正しい向きで表示されるということです。横倒しにはなりませんが、そのぶんタグを書き換えて回すこともできません。回転は絵の一部になりました。

本当の代償は、これが二世代目の非可逆圧縮だという点です。元のJPGはすでに8 × 8のブロック単位で高周波を捨て、色も半分の解像度で持っています。新しいエンコーダーには、ブロックの段差やリンギングの縁と本物のディテールを見分ける手立てがありません。だから前のエンコーダーの失敗を忠実に再現するためにビットを使い、その上からもう一度量子化します。品質を上げれば今回の劣化は抑えられますが、前回の劣化は直りません。ロスレスにすればアーティファクトまで完璧に保存され、ファイルはずっと大きくなります。この経路で望む結果とは言えないでしょう。

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

2026-09-12のスクリプトは、1280 × 854の素材を品質85でJPGにして351,967バイト、それを@jsquash/webpの品質85でWebPにして317,848バイトという結果を出しました。縮小率は約9.7%で、よく引用される25〜35%には遠く及びません。あの数字は、同じ無圧縮の原版に対して両方のエンコーダーを競わせた比較です。ここでは同じ品質で一度量子化済みの画像を渡しているので、賢いエンコーダーがビットを節約できたはずのディテールは、もう残っていませんでした。差が大きく開くのは原版から書き出したときで、既存ライブラリの一括変換が期待外れに終わるのもこれが理由です。

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

写真アーカイブの一括変換はやめておきましょう。実測に照らせば、全ファイルに非可逆の世代をもう一回ぶん足して、得られるのは1割に満たないバイト数、しかも並べ替えの基準にしている日時と位置が消えます。原版が残っているなら、そちらから書き出してください。形式の実力が出るのはそこです。メールマガジン、印刷、拡張子が固定された投稿欄に出すファイルも対象外です。証拠写真、権利や来歴をたどる必要のある画像のように、EXIFが付いたまま必要になるものも避けてください。自分でマークアップを書けるページのために数枚変換する、主役の画像をどこまで小さくできるか試す、といった使い方なら十分に理にかなっています。

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

## Limits

構造としては、ほとんど何も失いません。元のJPGにはアルファチャンネルもフレームもないので、新しい入れ物が落とすものがそもそもないからです。失われるのはメタデータと世代です。撮影日時、カメラとレンズ、露出設定、GPS座標といったEXIFは丸ごと消え、埋め込まれたICCプロファイルも残りません。詰め替えではなく、画素に戻してから改めてエンコードするためです。スマートフォンで撮った写真なら、あとからライブラリで探す手がかりの大半がこれに当たります。同時に、公開前に消しておきたい情報そのものでもあります。

向きだけは扱いが違うので覚えておく価値があります。デコーダーには「表示されるべき姿」で画像を要求するので、EXIFの`Orientation`が四分の一回転を指示している写真は、エンコード前に画素の側が回されます。タグ自体は消えても、出力はどこで開いても正しい向きで表示されるということです。横倒しにはなりませんが、そのぶんタグを書き換えて回すこともできません。回転は絵の一部になりました。

本当の代償は、これが二世代目の非可逆圧縮だという点です。元のJPGはすでに8 × 8のブロック単位で高周波を捨て、色も半分の解像度で持っています。新しいエンコーダーには、ブロックの段差やリンギングの縁と本物のディテールを見分ける手立てがありません。だから前のエンコーダーの失敗を忠実に再現するためにビットを使い、その上からもう一度量子化します。品質を上げれば今回の劣化は抑えられますが、前回の劣化は直りません。ロスレスにすればアーティファクトまで完璧に保存され、ファイルはずっと大きくなります。この経路で望む結果とは言えないでしょう。

## FAQ

### JPGをWebPにしても1割ほどしか縮まないのはなぜですか？

入力が同じ品質ですでに圧縮済みで、新しいエンコーダーに節約の余地が残っていなかったからです。よく見る25〜35%という数字は、無圧縮の原版に対する比較です。効果を丸ごと得たいなら、原版から書き出してください。

### JPGからの変換で撮影日時やGPS、向きのタグは残りますか？

日時、GPS、カメラ情報、カラープロファイルは、デコード後の画素から作り直すため残りません。向きだけは結果として例外で、回転がエンコード前に画素へ適用されるので、タグが消えても表示は正しい向きのままです。

### 写真ライブラリ全体をこの方法で変換すべきですか？

ほとんどの場合そうではありません。全ファイルに非可逆の世代が一つ増え、整理の基準になるメタデータを失い、実測では1割未満しか縮みません。特定のページのために選んで変換するのは有効ですが、蔵書ごと置き換える価値は普通ありません。

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

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

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

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

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

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

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

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