# PNG to WebP

> PNGをブラウザ内でWebPへ変換。透過はそのまま、アニメーションPNGは動いたまま残ります。実測では1,689,485バイトが319,834バイトへ、約81%減りました。

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

## What it does

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

失われると思われがちなもののうち、二つは残ります。WebPは8ビットのアルファチャンネルをそのまま持てるので、JPGへ向かうときのように透過部分を背景色で塗りつぶす必要がありません。アニメーションPNGも同じです。変換前にブラウザのImageDecoderでファイルを開き、複数フレームがあってWebPが出力先なら、各フレームを再エンコードして元の表示間隔とループ回数を保った動くWebPを組み立てます。組み立てに失敗したときだけ静止画へフォールバックし、その事実を警告として画面に出します。黙ってアニメーションを捨てることはありません。

消えるのは画素の外側にあるものです。いったんデコードしてcanvasに描き、改めてエンコードするため、補助チャンクは引き継がれません。埋め込まれたICCプロファイル、色空間を説明する`gAMA`や`cHRM`、テキストチャンク、カメラや編集ソフトが付けたEXIFブロックはいずれも出力に入りません。Display P3として記録された広色域の画像も、タグのない画素値として届き、表示側はsRGBとして解釈します。色深度も同じです。PNGは1チャンネル16ビットまで扱えますが、描画先のcanvasは8ビットRGBAなので、48ビットの原版はエンコーダーが見る前に丸められ、その精度は結果から取り戻せません。

最後の一つは構造上の制約ではなく設定の問題です。初期値では非可逆で出力するため、細かな質感、ディザのかかった階調、スクリーンショットやUI書き出しにありがちな1ピクセル幅の輪郭は近似されます。上の設定にあるロスレスの切り替えを入れるとWASMエンコーダーに変わり、画素を厳密に保ったまま、平坦な図版なら元より小さく収まることも珍しくありません。この一覧の中で、自分の判断で止められる損失はこれだけです。

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

2026-09-12にapps/web/scripts/measurePairs.tsで測定しました。libheifのサンプル写真から作り、「最適化 (oxipng)」をオンにして書いた1280 × 854のPNGは1,689,485バイトです。このツールではそのオプションは既定でオフなので、同じ絵を最適化なしでPNGにすると出発点はもっと大きくなります。これを@jsquash/webpの品質85でエンコードすると319,834バイトになり、この写真サンプルでは約81%小さくなりました。ただし一例であって比率の約束ではありません。非可逆WebPが最も差をつけられるのは写真で、平坦なロゴ、単色面積の広いスクリーンショット、すでに減色済みの画像はPNG側も十分小さく、差は一気に縮みます。ロスレスを選べば逆転することさえあります。

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

編集して何度も書き出す原版は、そのまま置いておいてください。品質85の非可逆エンコードは、通すたびに新しい近似を重ねます。スクリーンショットの自動比較のように画素の一致が前提の用途も、ロスレスに切り替えないなら向きません。届け先が現代のWebの外にある場合も同じで、メールクライアントの対応はいまだにまちまち、印刷や製版の工程では受け付けないことがあり、ファビコンやアプリアイコンの生成はPNGやICOを求めるのが普通です。高さマップ、深度パス、計測用の画像といった16ビットのPNGは、そもそもこの経路に通さないでください。問題はエンコーダーではなく8ビットのcanvasにあります。Webページに載せる写真やスクリーンショットという普通の用途なら、これは最も安上がりな軽量化です。

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

## Limits

失われると思われがちなもののうち、二つは残ります。WebPは8ビットのアルファチャンネルをそのまま持てるので、JPGへ向かうときのように透過部分を背景色で塗りつぶす必要がありません。アニメーションPNGも同じです。変換前にブラウザのImageDecoderでファイルを開き、複数フレームがあってWebPが出力先なら、各フレームを再エンコードして元の表示間隔とループ回数を保った動くWebPを組み立てます。組み立てに失敗したときだけ静止画へフォールバックし、その事実を警告として画面に出します。黙ってアニメーションを捨てることはありません。

消えるのは画素の外側にあるものです。いったんデコードしてcanvasに描き、改めてエンコードするため、補助チャンクは引き継がれません。埋め込まれたICCプロファイル、色空間を説明する`gAMA`や`cHRM`、テキストチャンク、カメラや編集ソフトが付けたEXIFブロックはいずれも出力に入りません。Display P3として記録された広色域の画像も、タグのない画素値として届き、表示側はsRGBとして解釈します。色深度も同じです。PNGは1チャンネル16ビットまで扱えますが、描画先のcanvasは8ビットRGBAなので、48ビットの原版はエンコーダーが見る前に丸められ、その精度は結果から取り戻せません。

最後の一つは構造上の制約ではなく設定の問題です。初期値では非可逆で出力するため、細かな質感、ディザのかかった階調、スクリーンショットやUI書き出しにありがちな1ピクセル幅の輪郭は近似されます。上の設定にあるロスレスの切り替えを入れるとWASMエンコーダーに変わり、画素を厳密に保ったまま、平坦な図版なら元より小さく収まることも珍しくありません。この一覧の中で、自分の判断で止められる損失はこれだけです。

## FAQ

### PNGをWebPにしても透過は残りますか？

残ります。WebPは8ビットのアルファチャンネルを持てるので、半透明の画素、やわらかい影、アンチエイリアスの効いた輪郭がそのまま通り、背景色を敷く処理も入りません。透過のある画像でJPGではなくWebPを選ぶ最大の理由がこれです。

### アニメーションPNGは動くWebPになりますか？

なります。複数フレームを検出すると、先頭だけ残すのではなく、元の表示間隔とループ回数を引き継いだアニメーションWebPを組み立てます。組み立てに失敗した場合だけ静止画にフォールバックし、警告を出すので、どちらになったかは必ず分かります。

### WebPは必ず元のPNGより小さくなりますか？

いいえ。実測した写真サンプルでは約81%小さくなりましたが、平坦な図版、小さなアイコン、すでに減色済みの画像では元とほとんど変わらず、ロスレスでは大きくなることもあります。思い込みで決めず、変換後のサイズ表示を見比べてください。

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

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

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

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

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

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

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

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