PNGとJPG: 実際に保存すべきはどちらですか？

ロスレスとロスィ、JPGにはないアルファチャンネルとテキストをぼやけさせるクロマサブサンプリング、両フォーマットのファイルサイズの測定結果。

August 9, 2026

PNGとJPGは1つの質問で異なります: ファイルはすべてのピクセルを正確に記憶していますか？ PNGはそうです。 JPGは人間の視覚が捉えにくい詳細を捨て、その代わりにはるかに小さくなります。この1つの分岐がほぼすべてのケースを決定し、ビーチの写真では1つの方向に、スプレッドシートのスクリーンショットでは別の方向に進みます。

以下のすべての数字は、LeanImgの独自ツールがブラウザタブで実行された結果で、2つのテストファイルから得られました: texture.jpg（3840x2160、538.6 KB）と、透明な背景を持つalpha.png（900x606、942.4 KB）。これらのツールはAPIルートやサーバーアクションなしで構築されているため、ファイルはあなたのマシンから出ることはありません。このカテゴリのほとんどのサイトは、画像をサーバーにアップロードし、1時間後に削除すると約束します。ここには削除するものは何もないため、私たちのプライバシーページは短いです。

どちらを選ぶべきですか、PNGそれともJPG？

写真はJPGに。 スクリーンショット、ロゴ、チャート、線画、透明性が必要なものはPNGに。 MDNのフォーマットガイドも同じ線を引いています。 スマートモードでは、私たちのコンプレッサーがtexture.jpgを538.6 KBから286.1 KBに、MozJPEGを使用して品質80で、47%削減しました。 スライダーを60にすると、同じ写真は212.4 KBになります。 30では131 KB、76%減です。

この分岐は各フォーマットの圧縮方法から来ています。 JPGの設計は隣接するピクセルが互いに混ざり合うことを前提としており、これはグラデーションやフィルムグレインに適しています。 スクリーンショットは、すべてのテキストエッジでその仮定を破ります。 PNGは各ピクセルを隣接ピクセルから予測し、その後差分を圧縮するため、ユーザーインターフェースが構成する同一色の平坦な部分で最も良い結果を出します。

ロスレス圧縮は実際にファイルサイズにどのように影響しますか？

ロスレスとは、デコードされたピクセルがビット単位で同一であることを意味し、これはPNG仕様で要求されています。 ファイルが縮小できないわけではありません。 私たちのコンプレッサーのPNGモードはoxipngをレベル3で実行し、alpha.pngを942.4 KBから383.9 KBにしました。 これはすべてのピクセル値が保持された状態で59%の削減です。

「小さいファイルサイズ」PNGオプションは異なる動物です。 これはimagequantを実行し、PNGが書き込まれる前に画像をカラーパレットに減少させ、alpha.pngは98.3 KBになりました。 これは90%の削減です。 これはロスィの結果であり、.png拡張子が示唆するものとは関係ありませんので、その画像がマスターコピーである場合は元のものを保持してください。

なぜJPGは色付きテキストや細い線をぼやけさせるのですか？

JPGは色を明るさよりも低い解像度で保存するからです。 このフォーマットは、ITU-T T.81で指定されているように、ルミナンスを2つのクロマチャンネルから分離して保持し、エンコーダは通常クロマをダウンサンプリングして1つの色サンプルが2x2のピクセルブロックをカバーするようにします。 texture.jpgのような3840x2160の写真ではそれを見つけることはできません。 白に対して1ピクセルの赤い線では、その線の色は3つの白い隣接ピクセルと平均化され、品質設定が適用される前に、スライダーの位置では戻すことができません。

スクリーンショットではそれが問題になります。 WebPに切り替えても回避できません。なぜなら、WebPのロスィモードは4:2:0クロマに固定され、同じ平均化が適用されるからです。 PNGは各ピクセルの正確なRGB値を保持するため、UIキャプチャ、QRコード、テキストオーバーレイはそこに属します。 PNGがまだ重すぎる場合は、量子化してフォーマットを保持してください。

JPGとして保存すると透明性はどうなりますか？

それは埋められます。 JPEGはどのモードでもアルファチャンネルを持たないため、透明なピクセルの背後に何があるかを決定する必要があります。 私たちのPNGからJPGへの変換ツールは、エンコードする前にそれらを白に合成し、コンプレッサーもターゲットフォーマットにアルファがない場合は同じことを行います。 そのステップがなければ、完全に透明なピクセルは通常RGB 0,0,0を持っているため、黒で出力されます。

その往復を元に戻すことはできません。 JPGからPNGへの変換を行うと、透明性があった場所に白い長方形があるPNGが手に入ります。さらに、最初のパスで焼き付けられたJPGアーティファクトも含まれます。 圧縮はすべてのメタデータを削除します: EXIF、GPS、ICCプロファイル、埋め込まれたサムネイルはすべて消えますが、方向は生き残ります。 PNGマスターを保持してください; あなたはそれを必要とするでしょう。 写真から被写体を切り取る場合、私たちの背景除去ツールはこの理由から常にアルファ付きPNGを書き込みます。これが切り抜きが投入したJPGよりも重くなる理由でもあり、アイコンジェネレーターはデフォルトで背景色を#ffffffに設定しているため、透明なロゴはそのフィールドを変更するまで白い四角に置かれます。

なぜ私のPNGはJPGよりもはるかに大きいのですか？

写真のノイズはPNGの予測器に何も作業を提供しません。 各行は上の行から推測され、残った差分が圧縮されます。これは平坦なボタンでは素晴らしいですが、粒状のものではほとんど役に立ちません。 2つのテストファイルを見てください。 alpha.pngは900x606で942.4 KBに達し、texture.jpgは3840x2160で、ピクセル数が15倍以上で538.6 KBに達しました。 パレットの量子化がそのギャップを埋めるレバーであり、alpha.pngは98.3 KBになりました。

WebPまたはAVIFを保存してこの質問をスキップすべきですか？

時には、測定する価値があります。 私たちはtexture.jpgをすべての3つのフォーマットで同じスライダー位置80でコンプレッサーに通し、その後63で再度実行しました。

スライダー80で最も大きなファイルを生成するAVIFは逆に見え、原因は私たち自身のコードにあります。 JPEGソースの場合、コンプレッサーはスライダーをソースの量子化テーブルから読み取った品質で乗算します。したがって、スライダーが80のときに60と見積もられたソースは実際には48でエンコードされます。 WebPとAVIFは80をそのまま受け取ります。 スマートモードのデフォルトである63では、順序が反転します: AVIFは186.9 KBで、WebPは200.6 KBで、538.6 KBのソースに対してです。 AVIFはまた、JPEGとWebPが瞬時に完了するのに対し、エンコードごとに10から11秒かかりました。コミットする前にブラウザサポートを確認する価値があります。 私たちはWebPが本当にJPGを超えるかどうかについての作品でその比較を詳しく分解しました。

目の前のファイルで何をすべきですか？

コンプレッサーを開いてください。 ファイルを2回実行します。 写真の場合は、最初にスマートモードを選択し、次にスライダーを60に上げて、2つの出力をフルズームで比較します。 テキストや透明性がある場合はPNGに留まり、両方のPNGモードを試してください: ロスレスでalpha.pngは383.9 KBになり、パレットモードで98.3 KBになります。 画像が800pxのカラムに向かう場合は、最初にリサイズしてください。なぜなら、リサイズツールはPNGをロスレスで書き込み、他のすべてをデフォルトで品質90で再エンコードするからです。 目的地がドキュメントである場合、JPGはPDFページに再エンコードされ、品質92で1回追加の生成が行われます。