PNG vs JPG vs WebP vs AVIF
PNG、JPG、WebP、AVIFは、同じピクセルをそれぞれ異なる約束のもとで圧縮します。PNGは可逆で透過に対応。JPGは非可逆で、写真ならはるかに小さくなる一方、アルファはありません。WebPとAVIFはその両方をこなし、それぞれ1つ前のフォーマットより約4分の1小さくなります。2026年、4つともすべての主要ブラウザでネイティブにデコードできます。
PNG vs JPG vs WebP vs AVIFとは
どの画像ファイルも、同じ問い——このピクセルをどうすればより少ないバイトで保存できるか——に、それぞれ異なる戦略で答えています。PNGは情報を失うことを拒み、代わりに構造を圧縮します。JPGは情報を、人間の目に見えない形で秩序正しく捨てることで、写真で劇的な節約を手にします。WebPとAVIFは現代の世代で、より優れた数学で両方の役割をこなし、たいていはより小さなファイルになります。
トレードオフは今やほぼ完全に、互換性ではなく内容の問題です。WebPは2020年に主要ブラウザすべてに搭載され、AVIFも2023-2024年までに続きました。したがって2026年、Safariを含め実際に問題となるすべての環境で、4つのフォーマットはネイティブにデコードできます。選択を決めるのは画像の中身です。硬いエッジかグラデーションか、文字か肌か、スクリーンショットか写真か、そして透過や目標のファイルサイズが譲れない条件かどうか。
このガイドは、まさにその軸に沿って4つのフォーマットを比較し、それぞれがどのような内容を苦手にするのかを説明したうえで、コンテナに付随するメタデータについても扱います。ここからリンクされたもの——コンバーター、圧縮ツール、リサイズツール——はすべてブラウザ内でローカルに動作します。手持ちのファイルで仮説を試しても、費用もアップロードも発生しません。
フォーマットを選んだら、それを実行に移す最短の方法は画像コンバーターです。タブ内でそのままPNG、JPG、WebP、AVIFの相互変換ができ、アップロードは一切不要です。
要件がフォーマットではなく厳密なサイズ上限であるときは100KBへの圧縮のウォークスルーが参考になります。品質ダイヤルを少しずつ下げて正確な目標サイズに到達させる方法を、各ステップで品質を目で確認しながら解説しています。
可逆と非可逆：すべての判断はここから決まる
可逆圧縮はデータを組み替え、ビット単位で完全に同一のピクセルを復元します。非可逆圧縮は画像を近似し、人間の視覚が最も見落としにくいものを残します。可逆が定義上小さいわけではありません——ノイズの多い写真では大きく負けることもあります——し、非可逆が定義上見苦しいわけでもありません。どちらも、それぞれが対象として設計された内容の上で威力を発揮します。だからこそ、最初の問いは「どのフォーマットが最良か」ではなく「その画像に何が含まれているか」なのです。
決めるのは内容の3つの性質です。写真や柔らかなグラデーションは、非可逆圧縮にきれいに耐えます。硬いエッジのグラフィック、文字、スクリーンショットは、あらゆるエッジにリンギングアーティファクトを生じさせる形で非可逆圧縮を苦しめます。ノイズはどのフォーマットにも悪影響ですが、可逆の圧縮率は破壊的に落ちます。ノイズは最大限の情報だからです。そして透過は、JPGを即座に失格させる強い要件です。
| フォーマット | 圧縮 | 透過 | 主に適した内容 |
|---|---|---|---|
| PNG | 可逆（DEFLATE） | フルアルファ | スクリーンショット、UI、ロゴ、線画 |
| JPG | 非可逆（DCTブロック） | なし | 写真、連続階調 |
| WebP | 可逆・非可逆の両方 | フルアルファ | 両方の役割をこなす万能型 |
| AVIF | 可逆・非可逆の両方 | フルアルファ | 極小サイズの写真、アニメーション |
PNG：正確なピクセル、アルファ、メタデータ
PNGはピクセルを可逆で保存します。デコーダーは元の画像を毎回正確に復元するため、スクリーンショット、デザインの書き出し、文字を含むあらゆるものの既定の選択肢になっています。圧縮では、各スキャンラインを隣のラインと突き合わせてフィルタリングし、そのあとで汎用のDEFLATE圧縮——ZIPと同じ系統の数学——を適用します。この戦略は反復される構造（フラットな塗り、整然と並んだUI、シャープな境界）を得意とするので、クリーンなアプリのスクリーンショットはしばしば元サイズの何分の一かまで圧縮されます。
同じ戦略こそ、PNGが写真に苦戦する理由でもあります。有機的なテクスチャはほぼランダムに近く、フィルターはそれを予測できず、ファイルは膨れ上がります。一方でPNGはフルの8ビットアルファを備えるため、任意の背景に置いてもソフトエッジのロゴはきれいなままです。さらにコンテナには、EXIFブロックを含む豊富なメタデータを入れる余地があり、この話題はこのガイドの最終セクションで再び登場します。
JPG：非可逆、写真には強く、エッジには極端に弱い
JPGは画像を8×8ピクセルのブロックに分割し、それぞれを周波数データ（離散コサイン変換）に変換して、人間の目が最も感度の低い周波数を捨てます。品質設定はその廃棄ダイヤルです。80-90では、写真は元サイズの何分の一かでほとんど無傷に見え、約50を下回るとブロックそのものが見え始め、このフォーマット特有のブロック状のアーティファクトになります。
この設計には、実務上重要な帰結が2つあります。第一に、透過は一切不可——このフォーマットにはアルファチャンネルがなく、透過に抜きたいファイルは、焼き込まれた背景つきで届きます。第二に、硬いエッジが打撃を受けます。1ピクセルのUIの境界線や小さな文字は、そのエネルギーを複数の8×8ブロックに広げ、復元の際にモスキートノイズやゴースティングへ滲みます。クロマサブサンプリング（色の詳細を半分の解像度で平均化する処理）が、赤や青の文字にさらに甘さを加えます。JPGは、そのために作られたもの——連続階調の写真——に限定して使いましょう。
WebPとAVIF：現代の2フォーマット
Google生まれのWebPは、両方の役割をこなします。ビデオ圧縮（VP8）と同じ予測符号化の考えに基づく非可逆モードと、たいていPNGを4分の1ほど上回る独立した可逆モードです。非可逆モードの写真は、同等の視覚品質でJPGよりおよそ25-35%小さくなり、しかもJPGと違ってどちらのモードでもアルファに対応します——つまり、本物の透過を持つ写真がついに小さなファイルに収まるようになりました。
AV1ビデオコーデックに基づくAVIFは、現在の最前線です。イントラフレーム符号化に加えてより豊富な予測ツールを備え、典型的な内容ではWebPより約20%小さくなります。他のフォーマットではバンディングを起こすグラデーションの扱いは顕著に優れ、8ビット以上の色深度、アニメーション、アルファにも対応します。ただし代償は確かにあります。エンコードは劇的に遅く（高負荷設定ではミリ秒ではなく数秒）、ツールのサポートも薄めです。バイト数が決定的な制約で、エンコード時間が制約でないときに選ぶべきフォーマットです。
| 同等品質でのJPGとの比較 | 典型的な削減幅 | 注意点 |
|---|---|---|
| WebP（非可逆） | ≈25-35%小さく | 可逆モードは別のコーデックで、比較相手はPNG |
| AVIF（非可逆） | WebPより≈20%小さく | エンコードがはるかに遅く、ツールのサポートも薄い |
| WebP（可逆） | PNGより≈25%小さく | それでもPNGに負ける場面はない——同じ可逆の保証 |
2026年のブラウザ対応
互換性の問題はすでに決着がついています。WebPは2020年にSafari 14が対応して以来、どこでも使える存在です。AVIFは2020-2021年にChrome 85とFirefox 93へ、2023年にSafari 16.4へ搭載され、2024-2025年のリリースを通じて、エバーグリーン環境を完全にカバーするに至りました。アニメーションWebPもアニメーションAVIFも、現在の環境ならどこでもデコードできます。
残る注意点は主流ではなく周辺部のものです。非常に古いSafari（iOS 13以前）はWebPに対応しておらず、特殊な高ビット深度や12ビットプロファイルを使う一部のAVIFファイルはデコードできるエンジンが限られます。また、ブラウザ以外のソフト——OSのプレビュー、古いデザインツール、CMSパイプライン——におけるAVIF対応は、ブラウザに比べてまだ遅れています。ユーザー提供の画像については、picture要素でWebPやJPGのフォールバックを添えてAVIFを配信するのが、今もなお防御的なパターンです。
| フォーマット | 全環境に普及した時期 | フォールバックが依然有効なケース |
|---|---|---|
| PNG、JPG | 1990年代 | 不要——真に普遍的 |
| WebP | 2020年（最後まで残ったのはSafari 14） | iOS 13以前、レガシーな埋め込み |
| AVIF | 2023年（主要エンジンで最後だったのはSafari 16.4） | 古いSafari、ブラウザ外のビューア、CMSパイプライン |
EXIF：メタデータはピクセルではなくコンテナに宿る
画像ファイルは2つの部分から成ります。ピクセルデータと、それを包むコンテナです。コンテナはメタデータを運べます——EXIFブロックには、カメラの機種、露出、向き、タイムスタンプ、そしてしばしばGPS座標が記録されています。ここから重要な性質が導かれます。メタデータが属するのは絵ではなくファイルだということです。JPGをコピーすればEXIFも一緒についてきます。同じ写真をWebPやAVIFに再エンコードした場合、ツールが意図して古いメタデータを引き継がないかぎり、新しいコンテナは空の状態から始まります。
これには2つの実務的な側面があります。プライバシー：カメラからそのまま共有した写真は、位置情報を明かしてしまう可能性があります。だからこそ、まともなコンバーターであればメタデータの除去は必須の機能です——再エンコードこそ確実な除去手段です。ワークフロー：向きやタイムスタンプは役立つこともあります。パイプラインがそれを必要とするなら、ツールにEXIFの保持を指示しなければなりません。勝手に保持されると思い込んではいけません。いずれにせよ、判断はコンテナに宿り、その判断が行われるのは変換のときです。
よくある質問
ここで画像を圧縮したり変換したりすると、アップロードされますか？
いいえ。デコード、再エンコード、リサイズはすべて、ブラウザ自身の画像コーデックを使ってブラウザ内で動作します。ファイルがタブの外に出ることはありません。DevToolsで確認できます。Networkパネルを開き、画像を変換すると、リクエスト一覧が空のままでいるのがわかります。サイトのContent-Security-Policyも、ページスクリプトによる外向きの接続を禁じています。
スクリーンショットやUIキャプチャには、どのフォーマットを使えばよいですか？
PNG、そしてサイズが重要なら可逆モードのWebPです。スクリーンショットは硬いエッジ、文字、フラットな塗りだらけ——可逆圧縮なら見事に縮め、非可逆なら滲ませてしまう内容です。JPGのスクリーンショットでは、すべての文字やボタンの境界の周りにリンギングが現れます。同じキャプチャのPNGは、内容が高度に予測しやすいぶん、むしろ小さくなるのが普通です。
同じ写真なのに、PNGのほうがJPGより大きくなるのはなぜですか？
写真は、可逆コーデックにとってほぼランダムなデータだからです。PNGはすべてのピクセルを正確に復元しなければならず、有機的なテクスチャ、センサーノイズ、グレインはその予測器を打ち負かすため、ほぼすべてを高いコストで保存することになります。JPGはその逆で、知覚できない部分を捨てます。同じ写真が、良いJPGやWebPの5〜10倍の大きさになることもざらにあります。
画像を変換すると、EXIFデータは取り除かれますか？
別のフォーマットへの再エンコードは新しいコンテナから始まるため、EXIFは既定では生き残りません——おかげでGPSやカメラのデータは手間なく除去されます。ただし同じフォーマット内では、メタデータを引き継ぐツールもあるため、意図せず除去が済むことは決して保証されません。プライバシーが重要なら、一度変換してから結果のプロパティを確認してください。向きが重要なら、ツールがEXIFを保持するか焼き込むかを確かめてください。
AVIFは常にWebPより小さくなりますか？
いいえ——同等の品質なら平均しておよそ20%小さいものの、ばらつきは大きいです。AVIFが最も差をつけるのは写真とグラデーションです。単純なフラットなグラフィックはほぼ同じサイズに圧縮されることもあり、少数ながら順位が逆転する画像もあります。エンコード時間も代償です。高負荷設定のAVIFは桁違いに時間がかかり、ビルドパイプラインではこれが問題になります。
非可逆画像の品質設定は、いくつにすればよいですか？
写真なら75-85あたりから始めてください。それより下ではブロックノイズやぼやけがすぐ現れ、90を超えるあたりからは、目に見えない差のために本物のバイトを支払うことになります。文字やエッジを含むグラフィックは、どの設定でも非可逆圧縮にうまく耐えられないため、可逆を選んでください。判断は、手持ちの内容を100%のズームで目で行ってください。設定は互いだけでなく、解像度や内容とも影響し合います。