変換ラボ

画像フォーマットの解説はたいてい「WebP は PNG より小さい」「JPG がいちばん小さい」と書いています。このサイトのページにも、かつて同じような書き方がありました。問題は、そうした主張が成り立つのは一部の画像だけで、しかも例外の幅が小さくないことです。当サイトの PNG → JPG のページでは、写真は 85% 小さくなる一方、アプリのスクリーンショットは 142% も大きくなります。同じページ、同じ設定で、結論が正反対なのです。

そこで「主張する」のをやめ、「計測する」ことにしました。以下に挙げるコンバーターはすべて同じ少数のテスト画像で計測されており、各ページに表示されているファイルサイズは、実際のブラウザでツールから出てきたバイト数そのものです。このページでは、その手順、あえて計測しなかったもの、そして数値を検証したい人のためのテストファイルの入手先をまとめます。

テストファイル

ベンチマークの誠実さは入力で決まります。ストックフォトは意図的に使いませんでした。ライセンスが付き、再配布できず、誰も再現できない数値は根拠になりません。4 枚はすべて、乱数シードを固定したスクリプトがゼロから描いたものです。だから毎回まったく同じバイト列が生成され、元ファイルはすべて下でダウンロードできます。それぞれ、異なる圧縮の思い込みを崩すために選んであります。

写真ふう

なめらかなグラデーションに細い線と粒状ノイズを重ねた、実際の写真に近い高周波のディテール。

ダウンロード: PNG 1.88 MB JPG 330.2 KB JFIF 330.2 KB WEBP 351.5 KB BMP 2.75 MB TIFF 2.75 MB AVIF 122.3 KB HEIC 886.6 KB

UI スクリーンショット

広い単色面と 1 ピクセルの鋭い罫線。アプリの画面をキャプチャしたような画像です。

ダウンロード: PNG 18.0 KB JPG 45.3 KB JFIF 45.3 KB WEBP 7.3 KB BMP 2.75 MB TIFF 2.75 MB GIF 10.2 KB AVIF 1.4 KB HEIC 21.9 KB

フラットイラスト

6 色の単色を大きな図形で置いただけ。グラデーションは一切ありません。

ダウンロード: PNG 34.7 KB JPG 25.6 KB JFIF 25.6 KB WEBP 10.8 KB BMP 2.75 MB TIFF 2.75 MB AVIF 3.2 KB HEIC 26.0 KB

透明背景のロゴ

輪郭がはっきりしていて色数が少なく、背景が透明です。

ダウンロード: PNG 28.8 KB WEBP 7.6 KB GIF 4.3 KB HEIC 25.1 KB

ベクター図

手書きの SVG。単色の図形と曲線が 1 本、テキストにしてわずか 574 バイトです。

ダウンロード: SVG 574 B

5 ページの混合 PDF

テキスト 4 ページと全面写真 1 ページ。ページごとの「重さ」が大きく異なります。

ダウンロード: PDF 334.1 KB

3 ページのテキスト PDF

文字だけの文書 —— 結合テスト用の 2 つ目のファイルです。

ダウンロード: PDF 2.8 KB

数値の作り方

どこにも推定の工程はありません。どの表のどの行についても、スクリプトは次のことを行います。

1. ブラウザの canvas にテスト画像を描き、ディスクに書き出す;
2. 公開ビルドの実際の /convert/… ページを開く;
3. そのページ自身のファイル入力欄にファイルを渡す(利用者とまったく同じ経路);
4. ダウンロードリンクが現れるのを待ち、生成された blob を取得して正確なバイト長を読む。

サイト上のすべての数値は、2026-07-28 に Chromium 151.0.7922.34 でこの方法により得られたものです。表に明記がない限り、各ページの初期設定を使っています。

隠さずに書いておきたい前提が 2 つあります。1 つ目、画像エンコーダーはブラウザ側にあり、当方のサーバーにはありません。したがってブラウザが違えば、あるいは Chromium が新しくなれば、サイズはわずかに変わり得ます。これらの数値は「再現可能」であって「普遍」ではありません。2 つ目、ファイルサイズは画質ではありません。小さいファイルのほうが見劣りすることは普通にあり、これらの表は「どう見えるか」を一切計測していません。

計測しなかったものと、その理由

ブラウザの canvas がエンコードできるのは 3 形式だけです。Chromium 151 に image/avif・image/gif・image/bmp・image/tiff を要求すると PNG が返ります。つまり PNG・JPEG・WebP 以外は、エンコーダーを自分で書く必要があります。すでに 3 つ書きました。無圧縮 24 ビットの BMP、無圧縮 baseline の TIFF(スキャナーの出力はしばしばこれです)、そして LZW 圧縮付きの GIF89a です。

GIF は一部だけの対応で、理由は GIF 自身にあります。色数が最大 256 色なのです。自分たちのテスト画像の色数を数えました。UI キャプチャは 13 色、透明ロゴは 12 色なので、どちらも正確にエンコードできます。しかしフラットイラストは 490 色、写真は 200,374 色ありました。円のアンチエイリアス輪郭と粒状ノイズが、何百もの中間色を生むからです。これらを減色すれば別の画像になり、元の PNG とサイズを比べても意味がありません。そこで GIF の行には本当に収まる 2 枚を使っています。そしてその 2 枚は、現実に GIF が使われている用途そのもの——平面の UI キャプチャと透明ステッカー——です。

AVIF は別の道を通りました。AVIF の中身は AV1 の映像フレーム 1 枚であり、AV1 エンコーダーは数百行の手書きで書けるものではありません。そこでテストファイルは ffmpeg と libaom-av1 で生成しました。-crf 23 -cpu-used 4 -still-picture 1 -pix_fmt yuv420p です。crf は JPEG と WebP の元ファイルに使った品質 92 に近づけて選びました。低品質の AVIF を高品質の JPG にぶつけても、公平な比較にはならないからです。外部ツールを使ったことで主張が弱くなるわけではありません。ここでの原則はもともと「ファイルはブラウザで生まれなければならない」ではなく、「ファイルを公開し、誰でも同じ数値を再現できるようにする」だからです。3 つの AVIF ファイルと、そのコマンドそのものを公開しています。両方とも検証できます。

HEIC:できないと書きましたが、それは誤りでした。このページには以前、HEIC は計測できないと書いてありました。この ffmpeg には libx265 はあるが HEIF muxer がなく、ブラウザにも npm にも .heic を書けるものはない、と。前半は本当です。後半は、ひとつの道具の限界を一般論にすり替えていました。libheif は自前の x265 エンコーダーを持っており、pillow-heif 経由でそこに届くと、4 つのテストファイルが一度目で出力できました。品質は 92 で、JPEG と WebP の元ファイルに合わせています。4 つとも他のファイルと一緒に公開しています。正確に書いておきます。これらはlibheif で符号化した HEIC であり、iPhone で撮った写真ではありません。Apple のファイルは 10-bit 4:2:0 が多く、独自の方向情報と EXIF も持つため、あなたの数値が私たちのものと完全に一致することはありません。残っている制限は 1 つです。コーパスに透明な AVIF はありません。ffmpeg の AVIF muxer はアルファ補助アイテムを書き出さず、生成されるファイルは不透明だからです。透明でないファイルで「透明が保たれるか」を試すのは、ただの見せかけです。HEIC のほうは透明が保たれました。コーパス生成スクリプトが各ファイルをその場で復号して確認し、失うものは公開せずに除外します。

PDF のページが最初に無かったのは別の理由です。結合や回転はファイルサイズの話ではないと考えていました。その判断は誤りで、しかも数字こそが面白い部分でした。同じテスト文書から 3 ページ目を抽出すると 331.2 KB、4 ページ目なら 1.4 KB です。そこで 9 つの PDF コンバーターも、ページごとの重さが大きく異なる 5 ページの文書で計測しました。

これで38 個すべてのコンバーターに実測値が付きました。36 ではなく 38 になったのは、基準を下げたからではありません。上の段落がもともと誤っていたからです。ああいう文を直すというのは、数字を書き換えることではなく、エンコーダーを探しに行くことでした。

全計測結果

各コンバーターのページに出ているデータを、ここで一度に見られるようにしました。パーセンテージはいずれも元ファイルに対する比です。表を読むより結論を知りたい場合は、判断ガイドにまとめてあります:どの形式に変換すべきか — 画像の中身で分類しています。

自分で再現する

この検証に当方の協力は要りません。上のテスト画像をダウンロードし、対応するコンバーターのページを開いてファイルを渡し、ツールが表示するサイズを表の行と比べてください。ツールはすべてあなたのブラウザ内で動き、元ファイルは当方が使ったものと同一です。

表全体から分かった 6 つのこと

1. 「小さいフォーマット」は存在せず、「この画像にとって小さいフォーマット」しかない。データ中で最も開きが大きいのは、同一のコンバーター・同一の初期設定での結果です。写真 −85%、スクリーンショット +142%。
2. WebP はほぼどこでも勝つ —— ただし「ほぼ」が正直な言葉です。PNG・JPG・BMP・TIFF が元なら、WebP の出力は必ず入力より小さくなりました。AVIF が元の場合は一度も勝てず、勝てるはずもありません。その後 GIF を加えて例外が見つかりました。4.3 KB の透明 GIF が 5.4 KB になり、27% 増えたのです。4 KB のパレット画像に対して、現代的なコーデックが取り戻せる余地はほとんどありません。
3. 可逆形式に変換しても画質は戻らず、容量だけは確実に増える。JPG → PNG で写真は 542% 増えましたが、劣化の度合いは元の JPG とまったく同じです。
4. BMP のファイルサイズは内容と完全に無関係。3 つの BMP 元ファイルはすべて厳密に 2.75 MB で、中身がノイズの多い写真でも 6 色のべた塗りでも変わりません。「無圧縮」とは実際にはこういうことです。
5. ベクターからラスターへは一方通行。574 バイトの SVG はラスタライズすると 6.6〜17.9 KB になり、拡大の自由を失います。逆方向が通るのはべた塗りの図だけで、写真をトレースした結果は 7.74 MB のパスの山でした。
6. 表で最も差が開いた行は AVIF のもので、それは AVIF への賛辞です。1200 × 800 の UI キャプチャは AVIF ならわずか 1,472 バイト。変換の代償は WebP で +378%、PNG で +2442%、JPG で +2942% です。AVIF から離れる理由に容量の話は存在せず、あるのは互換性だけ——その 3 ページはまさにそのために存在します。