WebP to PNG

WebP を PNG に変換する理由

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

意外に思われやすいのがアニメーションです。読み込んだファイルはすべてブラウザのImageDecoderで調べられ、フレームが複数あってPNGが出力先だった場合は、先頭フレームだけを残してデコーダーを閉じ、一枚しか変換していないという警告を出します。残りのフレーム、各フレームの表示時間、ループ回数には行き先がありません。この経路が書き出すのはAPNGではなく、ごく普通の一枚画像だからです。動きが目当てなら出力先をGIFにしてください。そちらの経路は全フレームとその間隔を保ちます。元の形式のまま再エンコードするという手もあります。

残るものは、他の変換より多いくらいです。元の8ビットのアルファチャンネルは出力側のアルファにそのまま対応するので、やわらかい影、アンチエイリアスの輪郭、半透明の画素が背景色に触れることなく渡ります。入力がロスレスWebPなら、画素の値は完全に同一です。非可逆WebPなら、デコード結果をアーティファクトごと忠実に記録します。最初のエンコーダーが加えた平滑化やブロック構造は、この時点でもう「絵そのもの」であり、後工程で被写体と切り分けることはできません。

メタデータは渡りません。WebPはRIFFコンテナの中にEXIFやICCPのチャンクを持てますが、この変換はcanvasを経由して画素にするので、それらのチャンクは移らず、出力はタグのない状態になります。撮影日時、カメラの各項目、GPS、元のカラープロファイルは消えるということです。人に渡す前なら好都合で、どれかを当てにしていたなら不都合です。

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

2026-09-12のスクリプトは、1280 × 854・品質85の非可逆WebP、319,834バイトを測りました。これをデコードして「最適化 (oxipng)」をオンにしてPNGにすると1,818,413バイト、約5.7倍です。そのチェックはこのページでは既定でオフなので、初期設定のまま変換するとブラウザ側のPNGの方が少し大きくなるのが普通です。倍率の一部は可逆保存そのものの費用ですが、残りは、前のエンコーダーが入れた平滑化やブロックの縁をディテールとして保存し直す費用です。スクリーンショットや平坦なイラストなら増え方はずっと穏やかで、平坦な図版のロスレスWebPからなら、ほぼ同じ大きさのPNGになることもあります。どちらの形式も同じ画素を、近い仕組みで圧縮することになるからです。

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

これから公開するファイルを変換しないでください。元のほうがすでに小さく、この経路は何も良くしないままバイト数を何倍にもします。もしどこかのブラウザが表示できないとしても、5倍以上のPNGを置くよりJPGの代替を用意するほうがはるかに安上がりです。動くステッカーやリアクション画像を、動きを保ったまま変換することもできません。出力先はGIFにしてください。ぼやけたWebPを直す目的にも使えません。ぼけはもう画素の中にあります。向いているのは、デスクトップの編集ソフト、オフィス文書、プリンタードライバー、投稿欄がファイルを受け付けないとき、その受け渡しで透過を保つ必要があるとき、そして繰り返し編集するための安定した中間ファイルが欲しいときです。

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