圧縮ツールや変換ツールに画像を通したら、ダウンロードしたファイルのほうが元より大きかった。たいていの場合、これは不具合ではありません。エンコーダーは受け取ったピクセルを指定された形式で書き直すだけで、その書き方が元のファイルより長くなることがあるのです。
結論から言うと: 容量が増えるのは、新しい設定が元のファイルより多くの情報を残すとき（強く圧縮された JPEG を高い品質で保存し直す）、非可逆の写真を可逆形式に移すとき（JPG から PNG）、元のファイルが使っていた工夫をエンコーダーが捨てるとき（パレット PNG を 32 ビットで保存し直す）、小さな画像で形式の固定コストが中身を上回るとき、そしてピクセル数が増えたときです。今回のテストでは、135 kB の JPEG が PNG にすると 2.21 MB になり、504 バイトのアイコンが WebP で 1,104 バイトになりました。対処はたいてい「元のファイルを使う」「別の形式を選ぶ」「品質を下げる」のどれかです。どれが効くかは以下のケースごとに書いています。
9 つのケースのまとめ
ここに載せた数値は、すべて手元のマシンで 1 回ずつ実行した結果です。サイズは正確なバイト数で、本文中の 1 kB は 1,000 バイトを指します。
| ケース | 入力 | 出力 | 変化 |
|---|---|---|---|
| 最適化済み JPEG を品質 80 で再保存（ブラウザーのエンコーダー） | 135,151 | 168,059 | +24% |
| 同じ JPEG を PNG に変換 | 135,151 | 2,213,889 | 16.4倍 |
| 同じ JPEG を品質 90 で WebP に変換 | 135,151 | 212,204 | +57% |
| 写真の PNG をブラウザーの canvas で PNG として再保存 | 637,432 | 846,413 | +33% |
| パレット PNG のロゴをブラウザーの canvas で再保存 | 45,525 | 170,429 | 3.7倍 |
| スクリーンショットの PNG を品質 90 で JPG に変換 | 100,728 | 106,602 | +6% |
| 32 x 32 のアイコン PNG を品質 90 で WebP に変換 | 504 | 1,104 | 2.2倍 |
| 320 x 480 の JPEG を 640 x 960 に拡大 | 28,034 | 62,114 | 2.2倍 |
| 12 フレームのベタ塗り GIF を APNG に変換 | 5,519 | 5,758 | +4% |
どうやってテストしたか
テストは 2026-10-16（UTC）に、macOS 26.6.2 の Apple M4 Mac で行いました。
- ブラウザーのエンコーダー: ヘッドレスモードの Google Chrome 155.0.8059.85 を使いました。当サイトの画像圧縮ツールが使っている browser-image-compression 2.0.2 を空のローカルページに読み込み、圧縮ツールの既定値で呼び出しています。既定値は、品質 0.8、サイズ目標 1 MB、長辺の上限 1920 px、元の形式を維持、EXIF を削除、再試行は最大 30 回です。変換のケースでは、変換ページと同じ canvas の処理を使いました。画像を描画し、JPG の場合は背景を白で塗り、変換ツールの既定品質 90% で
canvas.toBlobを呼びます。サイトそのものをクリックして操作したわけではありません。処理のコードは同じですが、それを包むページはテスト用のものです。 - その他のエンコーダー: Node v26.12.0 上の sharp 0.35.5（libvips 8.18.7、mozjpeg、libwebp 1.6.0、libaom 3.15.1、libimagequant 2.4.1、libpng 1.6.58）と、当サイトの GIF から APNG への変換ツールが使っている PNG/APNG エンコーダーの upng-js 2.1.0 です。
- 画像: Bonnie Moreland による CC0 の風景写真（Wikimedia Commons）。以前のベンチマークで当サイトの圧縮ツールが出力したもの（1920 x 1280、250,382 バイト）と、それを mozjpeg の品質 70 で再エンコードしたもの（135,151 バイト）を使いました。ほかに、Kodak のテスト画像 kodim04（512 x 768 の PNG、Kodak が利用制限なしで公開）、当サイトの /compress ページのスクリーンショット（1440 x 900 の PNG）、Enzy Cell による CC0 の「NEW LOGO R」（Wikimedia Commons）とそのパレット版、このテストのために描いた 32 x 32 のアイコンと 12 フレームの GIF、kodim04 から切り出した幅 320 px のサムネイルです。
どの数値も 1 回分の結果です。ブラウザーの PNG エンコーダーは実行ごとに出力がバイト単位で一致するとは限らないので、同じことを試すと少し違う数値になるかもしれません。私たちは ImgCompress.app を作っている当事者で、運営者については運営者情報ページに書いています。本文の下書きには AI アシスタントを使い、すべての数値を元の出力ファイルと照らし合わせて確認しました。
JPEG を圧縮し直すと大きくなるのはなぜ？
「品質 80」は決まった圧縮量ではないからです。あくまで特定のエンコーダーに対する設定値で、エンコーダーが違えば、あるいは品質の数値が違えば、残すディテールの量も変わります。
テストに使った 135 kB の JPEG は、小さなファイルを作るように調整された mozjpeg の品質 70 で作ったものでした。これを Chrome 内蔵のエンコーダーが品質 80 で保存し直すと、168 kB と 24% 大きくなりました。ブラウザーは JPEG をいったんただのピクセルに戻します。そこには mozjpeg が残したブロック状の圧縮ノイズも含まれます。そのピクセルを、元より細かい量子化でエンコードし直したわけです。最初に失われた情報は戻ってきません。新しいファイルは、同じ絵と古い圧縮ノイズを表すためにより多くのバイトを使っているだけです。
同じ写真でも圧縮の弱い 250,382 バイトの版では、結果が違いました。Chrome の品質 80 では 250,670 バイトとなり、増えたのは 288 バイトだけです。そのファイルを作ったのと同じエンコーダー・同じ設定で保存し直すと、元のサイズとほぼ同じになりました。
当サイトの圧縮ツールでの対策
当サイトの圧縮ツールは、最初の結果をチェックしています。browser-image-compression では、出力が元より大きい（またはサイズ目標を超えている）場合、前回の品質に 0.95 を掛けた値（PNG は 0.85）でエンコードし直し、両方の条件を下回るか再試行の回数が尽きるまで繰り返します。このループで縦横のサイズまで縮むのはサイズ目標を超えているときだけなので、小さな写真はピクセルサイズがそのまま保たれます。
250 kB のファイルは、品質 0.76 での再試行 1 回で 240,546 バイトになり、3.9% 小さくなりました。135 kB の mozjpeg のファイルは、品質 0.56 まで 7 回下げてようやく 134,643 バイトです。すでに圧縮済みのファイルで、品質をかなり下げて減ったのは 508 バイトでした。結果カードに表示される削減率が数％以下なら、元のファイルを使ってください。
それでも小さくならず、形式も変わっていない場合、圧縮ツールは元のファイルをそのまま返します。同じ形式のまま大きくなったファイルを渡すことはありません。
品質の数値についての詳しい説明は、JPEG 圧縮のガイドにまとめています。
JPG から PNG に変換すると容量が大きく増えるのはなぜ？
PNG は可逆形式で、すべてのピクセルを正確に保存します。JPEG の写真をデコードすると、隣とわずかに色が違うピクセルが大量に出てきます。フィルムの粒子、センサーのノイズ、そして JPEG 圧縮が加える 8 x 8 のかすかなブロック模様です。可逆形式はそれをすべて残さなければなりません。
| 元の JPEG | PNG にした結果（canvas） | 増加 |
|---|---|---|
| 250,382 バイト | 2,691,460 バイト | 10.7倍 |
| 135,151 バイト | 2,213,889 バイト | 16.4倍 |
今回のテストでは、JPEG を強く圧縮してあるほど増え方が大きくなりました。元のファイルは小さいのに、PNG が保存すべきピクセル数は変わらないからです。また、PNG に変換しても JPEG で生じた劣化は元に戻りません。同じぼやけやブロックノイズが、今度は劣化なしで保存されるだけです。
JPG から PNG への変換は、PNG でなければならない場面で使ってください。PNG しか受け付けない編集ソフト、何度も編集するマスター用のコピー、JPG をはじく入力フォームなどです。ファイルを小さくしたいだけなら、JPG のままにするか、WebP や AVIF を選びましょう。
PNG を保存し直したら大きくなったのはなぜ？
ブラウザーでは、2 つの要因が裏目に出ます。
1 つ目は、Chrome の canvas の PNG エンコーダーが、受け取ったファイルよりずっと粗くデータを詰め込むことです。kodim04 の写真を canvas.toBlob で保存し直すと、ピクセルは同じなのに 637,432 バイトが 846,413 バイトになり、33% 増えました。丁寧に可逆で保存し直しても、必ず小さくなるとは限りません。sharp で libpng の圧縮レベル 9 を指定すると 638,304 バイトとなり、元のファイルより 872 バイト多くなりました。
2 つ目は、canvas がすべての画像を 32 ビットの RGBA として扱い、Chrome もそのまま書き出すことです。パレット PNG は、各ピクセルを小さなカラーテーブルの番号として保存します。TinyPNG や pngquant のようなツールがファイルを小さくできるのはこの仕組みのおかげです。テストに使ったロゴのパレット版は 45,525 バイトでした。これを canvas に描いて保存し直すと、カラーテーブルがなくなってすべてのピクセルがそのまま記録され、170,429 バイトと 3.7 倍になりました。
当サイトの圧縮ツールは、PNG に素の canvas.toBlob を使っていません。browser-image-compression はピクセルを UPNG に渡し、色数の上限を 4096 x 品質に設定します。既定の 0.8 なら 3,276 色です。同じ実行での結果は次のとおりです。
| 画像 | 元のサイズ | 圧縮ツールの既定値 | 変化 |
|---|---|---|---|
| kodim04.png（写真） | 637,432 | 542,951 | -15% |
| スクリーンショット | 100,728 | 80,419 | -20% |
| ロゴ（フルカラー、アルファあり） | 152,010 | 113,515 | -25% |
| ロゴ（パレット） | 45,525 | 45,032 | -1% |
この処理は色数を減らすので、可逆ではありません。写真は 31,716 色から 3,277 色に、スクリーンショットは 2,002 色から 1,314 色に減りました。すでに最適化されたパレット PNG はほとんど縮む余地がないため、どのツールで圧縮し直しても、当サイトのものも含めて、手間のわりに得るものはわずかです。
スクリーンショットは JPG で保存するべき？
たいていは JPG に向きません。JPEG はなめらかな写真のディテール向けに設計されていますが、スクリーンショットはベタ塗りの色と、文字まわりのくっきりした輪郭でできています。Chrome は JPG を 4:2:0 のクロマサブサンプリングで保存しました。これは色の情報を、明るさに比べて縦横それぞれ半分の解像度で持つ方式で、色付きの文字や細い色付きの線から影響が出ます。品質 90 で 2 倍に拡大して見比べたところ、PNG との違いはほとんど分かりませんでしたが、それでもファイルは大きくなっていました。
| スクリーンショットの出力 | バイト数 | 100,728 バイトの PNG との比較 |
|---|---|---|
| JPG、品質 90（変換ツールの既定値） | 106,602 | +6% |
| JPG、品質 80 | 82,331 | -18% |
| 当サイトの圧縮ツールを通した PNG | 80,419 | -20% |
| WebP、品質 90（非可逆、canvas） | 59,638 | -41% |
| WebP ロスレス（sharp） | 38,590 | -62% |
| パレット PNG（libimagequant、品質 80） | 30,544 | -70% |
提出先がどうしても JPG を求めるなら、PNG から JPG への変換を 80% で使えば、今回のテストでは PNG より小さくなりました。90% では小さくなりませんでした。WebP が使えるなら、スクリーンショットは PNG から WebP への変換のほうが向いています。いちばん小さくなったのはパレット PNG ですが、当サイトには 256 色のパレットモードがありません。最後の 50 kB まで削りたいときは、pngquant や Squoosh のようなツールを使ってください。この 2 つの形式の使い分けは WebP と PNG の比較記事で詳しく扱っています。
WebP や AVIF にしたのに元より大きくなるのはなぜ？
理由は 2 つあり、それぞれ別のテストで現れました。
圧縮済みの JPEG を高い品質で変換した場合
同じ見た目の品質なら、WebP や AVIF は JPEG より小さくなることが多いと言われます。ただしこの比較は、きれいな元画像から始めることが前提です。JPEG から変換すると、新しいエンコーダーは JPEG の圧縮ノイズまでディテールとして再現しようとします。
| 135,151 バイトの JPEG から | バイト数 | 変化 |
|---|---|---|
| WebP、品質 90（canvas、変換ツールの既定値） | 212,204 | +57% |
| WebP、品質 75（sharp） | 109,124 | -19% |
| AVIF、品質 50（sharp） | 93,940 | -30% |
250 kB の JPEG も、品質 90 の WebP にすると 250,382 バイトから 269,556 バイトになり、7.7% 増えました。形式の違いより品質の数値のほうが効きます。JPG から WebP への変換を使うときは、スライダーを既定の 90% から下げてサイズを見比べるか、JPG から AVIF への変換を試してください。AVIF が細かい質感をどう扱うかは、AVIF の解説記事に書いています。
小さな画像と固定コスト
どの形式にも、ヘッダーなどの固定コストがあります。透過付きの非可逆 WebP なら、アルファチャンネルも別に保存されます。画像全体が 504 バイトしかないと、こうしたコストが大きく響きます。
| 504 バイトのパレット PNG アイコンの変換先 | バイト数 |
|---|---|
| WebP ロスレス（sharp） | 364 |
| WebP 品質 75（sharp） | 436 |
| AVIF 品質 50（sharp） | 667 |
| canvas で再保存した PNG | 833 |
| WebP 品質 90（canvas） | 1,104 |
| AVIF ロスレス（sharp） | 1,089 |
| JPG 品質 90（canvas） | 1,367 |
ロスレス WebP は PNG より 140 バイト小さくなりましたが、ほとんどの選択肢ではアイコンが大きくなり、AVIF は両方の設定で増えました。アイコンや小さな UI 素材は PNG のままにするか、ベクターの元データがあれば SVG を使ってください。今回のテストで WebP と AVIF が容量を減らせたのは写真のほうで、アイコンでは減りませんでした。
拡大やメタデータで容量は増える？
拡大すると、ディテールは増えないのにバイト数だけが増えます。320 x 480 のサムネイルは 28,034 バイトでした。同じサイズのまま品質 80 で保存し直すと 28,513 バイト、先に 640 x 960 に拡大すると 62,114 バイトで、2.2 倍の容量なのに画像はむしろぼやけました。当サイトの圧縮ツールの 1920 px は上限なので、拡大することはありません。一方、リサイズツールは大きな数値を入力すればそのとおり拡大します。書き出す前に、画像リサイズツールで出力サイズを確認してください。拡大で画質を取り戻せない理由は、画質を落とさずにリサイズする方法で説明しています。
今回のテストでは、メタデータの影響は小さなものでした。サムネイルには 480 バイトの Display P3 カラープロファイルと 258 バイトの EXIF タグが含まれていて、28,290 バイトの約 2.6% です。当サイトの圧縮ツールは既定で EXIF を削除し、「EXIF を保持」をオンにしたときだけ残します。カメラのファイルには埋め込みのプレビュー画像のような大きなデータが入っていることがあるので、カメラやスマートフォンから書き出した小さな画像では、EXIF の削除の効果が大きくなる場合があります。GPS の位置情報も一緒に消えます。
GIF を変換するとどうなる？
GIF は古い形式ですが、色数の少ない短いアニメーションなら意外とコンパクトです。パレットの番号で保存するうえ、各フレームで変化した部分だけを保存できるからです。無地の背景の上を点が移動する、240 x 240、12 フレームのアニメーションを描いて試しました。
| 出力 | バイト数 | 5,519 バイトの GIF との比較 |
|---|---|---|
| APNG、ロスレス（UPNG、当サイトの GIF から APNG への変換と同じ） | 5,758 | +4% |
| アニメーション WebP、ロスレス（sharp） | 5,426 | -2% |
| アニメーション WebP、品質 75（sharp） | 5,750 | +4% |
どれもサイズはほとんど変わりませんでした。この結果は小さなベタ塗りのアニメーションに限った話です。写真のフレームが続く長い GIF は試していません。そうした GIF では 256 色の制限とディザリングが GIF にとって不利に働きます。短いベタ塗りのアニメーションなら GIF のままで構いません。もっと小さくしたいときは、GIF 圧縮ツールから始めてください。
結果が大きくなったとき、当サイトのツールはどう動く？
ここまでの処理はすべてブラウザーの中で行われ、当サイトでは画像がアップロードされることはありません。出力が大きくなったときの各ツールの動きは次のとおりです。
- 圧縮ツール（元の形式を維持）: ファイルが元より大きいあいだは品質を下げて再試行し、それでも小さくならなければ元のファイルを返します。
- 圧縮ツール（形式を変更）: 変換後のファイルが大きくても、そのまま受け取ることになります。結果カードには両方のサイズが表示され、削減率は小さくなったときだけ表示されるので、2 つの数値を見比べてください。
- 変換ツール: スライダーの値（非可逆の出力は既定で 90%）で 1 回だけエンコードし、サイズのチェックはしません。変換の目的は形式を変えることなので、サイズはどちらにも転びます。
- 目標サイズ: ファイルが目標を上回っているあいだ、再試行のたびに品質を下げ、「元の解像度を維持」がオフなら縦横も 5% ずつ縮めます。30 回で止まり、目標に届かなかった場合はカードにその旨が表示されます。
圧縮し直す前・変換する前のチェックリスト
- すでに最適化されたファイルではないか？ CDN や CMS、TinyPNG のようなツールを通したファイルなら、もう一度圧縮してもあまり減りません。今回は 3.9% と 0.4% でした。その程度なら元のファイルを使いましょう。
- 写真を PNG にしようとしていないか？ PNG が必須の場合だけにしてください。今回の 2 つの JPEG は 10.7 倍と 16.4 倍に増えました。
- スクリーンショットやベタ塗りの画像ではないか？ PNG のままにするか、WebP を使ってください。今回のテストでは、品質 90% の JPG は PNG より大きくなりました。
- 数 kB 未満の画像ではないか？ アイコンは PNG か SVG のままにしましょう。WebP や AVIF のヘッダーのほうがピクセルより重くなることがあります。
- ピクセルサイズが大きくなっていないか？ 保存する前に出力サイズを確認してください。拡大したサムネイルはバイト数が 2 倍以上になりました。
- 変換ツールが 90% のままになっていないか？ JPG から WebP なら、75〜80% を試して見比べてください。
- メタデータは必要か？ 公開する小さな画像なら EXIF を削除し、保管用の写真なら残しておきましょう。
同じ形式のまま小さくしたいだけなら、まず圧縮ツールを試してください。ダウンロードする前に、結果カードで圧縮前と圧縮後のサイズを見比べるのを忘れずに。