画像を100KBに圧縮(オンライン)

Webページ、アップロード、メール向けに画像を100KBまで圧縮します。結果パネルに実際の出力サイズと解像度が表示されるので、その容量に何を払ったかが常に分かります。

100キロバイトで何ができるのか

100KBは102,400バイトで、このサイトの容量目標の中で、答えが妥協でなくなる最初の水準です。1ピクセルあたりおよそ3分の1バイトの写真なら約300,000ピクセル、つまり700×450程度が収まります。記事中の画像、カテゴリーのサムネイル、マーケットプレイスの出品、プロフィール写真として、ブラウザが表示するどのサイズにも十分な大きさです。多くの写真は1ピクセルも失わずに100KBへ到達します。スマートフォンのカメラが書き出す準ロスレスに近い設定から、画面上では誰も気づかない0.6〜0.8程度までエンコーダーの品質を落とすだけで済むからです。このツールはまずその道を試します。解像度を削り始めるのは、ファイルが容量の8倍を超える場合だけです。そこを超えると品質の削減だけでは到達できないことが明らかであり、原寸での初回試行はそれを証明するために秒数を費やすだけになります。そのあとは測定ループが引き継ぎます。エンコードして実際のバイト数とピクセル数を読み、この画像の1ピクセルあたりの実コストを計算し、収まるサイズを解き、最大5回まで繰り返します。この容量で興味深いのはスクリーンショットです。PNGで保存されたスクリーンショットは定義上ロスレスであり、PNGには手放せる品質設定がないため、フルHDの画面キャプチャは何をしても100KBを大きく上回ります。このページは出力がロスレスであることを検知し、不足を謎めいた失敗ではなく形式の問題として報告し、出力をJPEGに切り替えるのが実際の解決策だと伝えます。メタデータは処理の過程で除去され、すべての工程はブラウザ内でローカルに行われます。

100KBがWeb向けの妥当な目標である理由

1枚あたり100KBは、画像のせいでページが遅い状態からおおむね抜け出せる水準です。ページが速く感じられるかを決めるCore Web Vitalsの指標であるLargest Contentful Paintは、たいていファーストビューの最も大きな画像で決まるため、その画像を数百キロバイト以下にすることは、多くのサイトにとって最も安上がりな改善策です。本文中の画像は積み重なるとさらに効いてきます。2MBの写真を15枚含む長文記事は30メガバイトのページであり、モバイル回線がまともに描画してくれることはありませんが、同じ記事が1枚100KBなら読者が興味を失う前に読み込みが終わります。この数値には明確な制限としての側面もあります。多くのフォーラム、Wiki、求人サイト、チケットシステム、メール配信プラットフォームが添付や本文画像を100KBに制限しており、古いイントラネットのアプリケーションでもよく見られます。メールはそれ自体が特殊なケースです。多くの企業のゲートウェイは数メガバイトを超えるメッセージを今も拒否しますが、1枚100KBの画像を12枚埋め込んだニュースレターであれば、元のままなら無理だったところを余裕で通ります。この数値が繰り返し出てくるもう一つの理由は、通常の記事幅で表示される写真にとって、そのあたりから効果が頭打ちになるからです。100KBを下回ると鮮明さを目に見える形でバイトと交換し始め、上回ると余分なデータの大半は表示サイズでは解像されないディテールに費やされます。品質のパーセンテージではなく固定の目標として選ぶことで、検証可能な答えが得られます。ファイルは94KBで、解像度は維持されたのか。目で判断して足りていることを祈るしかない設定とは違います。

画像の多いページのLargest Contentful Paintを改善する
長文記事をモバイル回線でも読み込み続けられるようにする
フォーラム、Wiki、ニュースレターの添付制限に収める
多くの場合、解像度をまったく落とさずに目標へ到達できる

画像を100KBに圧縮する方法

Web用途では先に表示幅を決めてください。800ピクセルで描画される枠に3000ピクセルの写真を流し込む意味はありません。余分なピクセルはバイトを食うだけで何も生みません。

1

100KB以下にしたい画像をアップロードします。まとめてでも構いません

2

写真では形式を「元の形式を維持」のままにし、PNGのスクリーンショットを目標に届かせる必要がある場合はJPEGに切り替えます

3

「適用」をクリックして各結果行を確認します。解像度の行が「変更なし」であれば、代償はエンコーダーの品質だけだったということです

4

送り先が現代的なWebサイトであればWebPを選んでください。同じ100KBの中で目に見えて多くのディテールを保てます

よくある質問

通常の記事幅であれば大丈夫です。100KBは写真を長辺およそ700〜900ピクセルで保持でき、これはほとんどの記事カラムの描画幅と同等かそれ以上です。甘く見えるのは、それよりずっと広く表示した場合や全画面で開いた場合だけです。
送り先が対応しているならWebPです。同じ見た目の品質でWebPが必要とするバイト数はおよそ4分の1少ないため、100KBという固定の枠の中では、ファイルが小さくなるのではなく解像度が上がります。現行のブラウザはすべてデコードできますが、一部のアップロードフォームや古いデスクトップツールは今も受け付けません。
PNGがロスレスだからです。全ピクセルを厳密に再現し、下げられる品質設定がないため、小さくする唯一の方法はピクセルを減らすことですが、100KBに収まるまで縮めたスクリーンショットは文字が読めません。結果パネルはこれを形式上の制限として明示し、正直な答えであるJPEGを勧めます。
本文中の画像であれば妥当な目安です。全幅のヒーロー画像はそれ以上でも正当化できます。本当に重要な指標は、実回線で最大の可視画像が届くまでの時間です。適切なサイズの画像を配信することのほうが、単一のバイト数より重要です。300ピクセル幅で表示される100KBのファイルは、やはり無駄です。
多くの場合、保てます。ファイルが目標のおよそ8倍未満であれば、ツールはまずエンコーダーの品質だけで削減を試み、それで足りない場合にのみピクセルを減らします。解像度が変わったかどうかは結果行に明記されるので、推測する必要はありません。
CSSピクセルあたり2デバイスピクセルの画面では、線方向におよそ2倍、つまりピクセル数で4倍の解像度が必要です。それを見込んで容量を配分してください。画像がCSS上で800ピクセル幅に描画され、Retina画面でも鮮明にしたいなら、100KBでは厳しく、200KBのページから始めるほうが適しています。
いいえ。すでに容量内のファイルはアップロードされたそのままで返され、「すでに100KB未満」と表示されます。あえてエンコーダーに通しても、見返りなしに1世代分の品質を失うだけです。
多数のファイルをまとめて選択またはドロップし、結果を1つのZIPでダウンロードできます。処理は並列ではなく順番に行われるため、大量のバッチでもスマートフォンのメモリを使い切ることがなく、結果一覧にはファイルごとの合否が表示されます。

その他の画像ツール

画像編集のニーズに応える他の強力なツールをご覧ください

画像圧縮

サイズ縮小

画像切り抜き

領域を切り取る

形式変換

形式を変更

フォトエディター

写真を編集

画像回転

画像を回転

画像反転

水平/垂直反転

透かしを追加

透かし

枠線追加

画像枠線を追加

角丸

角丸を追加

フィルター

明るさ/コントラスト

顔をぼかす

顔を隠す

モザイク

領域をぼかす

背景削除

背景を削除

画質向上

AI拡大

テキスト追加

画像にテキストを追加

コラージュ

複数の画像を結合

HTMLから画像

Webを画像に

GIF からシーケンス

フレーム抽出

画像の余白を削除

空白の縁を削除

画像を一括リネーム

ファイル名を安全に一括変更

円形切り抜き

画像を円形に切り抜き

白黒

画像をグレースケールに変換

画像分割

画像をグリッドに分割

画像結合

画像を1つに結合

DPI変更

画像のDPIメタデータを設定

画像→Base64

画像をBase64にエンコード

画像をPDFに結合

複数の画像を1つのPDFにまとめる

HEIC→JPG

iPhoneのHEIC写真をJPGに変換

EXIF除去ツール

GPS位置情報を含む写真の隠しメタデータを表示・除去

ファビコン ジェネレーター

完全なアイコンセットとHTML

カラーパレット

画像から色を抽出

Base64→画像

Base64をデコードして画像に戻す

HEIC→PNG

iPhoneのHEIC写真をロスレスでPNGに変換

文字を被写体の後ろに

写真の被写体の後ろに文字を回り込ませる。すべてブラウザ内で完結

カラーピッカー

任意のピクセルのHEX・RGB・HSLを取得

署名メーカー

署名を手書きして透過PNGでダウンロード

署名の背景削除

紙の上のインクを透過に

背景透過ツール

背景を透明にする