JPGを100 KB未満にリサイズするにはどうすればよいですか？

538.6 KBの写真に対する測定された品質の階段、スライダーが131 KBで止まる理由、ピクセルを削ることが実際にバイト予算に達するレバーである理由。

August 9, 2026 · Updated August 21, 2026

アップロードフォームには最大100 KBと表示されています。あなたの写真は538.6 KBです。反射的に品質スライダーを左に引っ張りたくなりますが、大きな写真ではそれでは目的を達成できません。私たちは1つのファイルを取り、全体の階段を実行しました：texture.jpgは3840x2160、ディスク上で538.6 KBです。品質30でも131 KBにしかならず、その時点で画像は目に見えて劣化しています。

JPEGサイズを実際に制御する数値はピクセル数です。Baseline JPEGは画像を8x8ブロックにエンコードするため、両方の寸法を半分にすると、保存するブロックは4分の1になります。スライダーしかない場合、このサイズのファイルでは約131 KBで止まります。以下のすべての数値は、ブラウザタブで動作する私たち自身のコンプレッサーとリサイザーから得られたものです。待つ必要のあるアップロードステップはありません。

なぜ品質スライダーでは100 KBに到達しないのですか？

これが階段です。毎回同じソースファイルを使用し、画像コンプレッサーで手動モードで実行しました。スマートモードは各エンコーダーのデフォルトを選択し、JPEGとWebPは80、AVIFは63、PNGはロスレスです。

スライダーの60ポイントで216.8 KBを購入しました。最後のストレッチ、60から30までで、81.4 KBのために多くの目に見える詳細を放棄しました。3840x2160の写真は800万以上のピクセルを記述する必要があり、そのサイズでそれらを記述するバイト数には下限があります。その下限は現実です。

なぜ品質30は本当に30ではないのですか？

これは多くの人をつまずかせるもので、私たちが説明する必要があります。ソースがJPEGの場合、私たちのコンプレッサーはファイルの最初の64 KBから量子化テーブルを読み取り、保存された品質を推定します。その後、スライダーがその推定をスケールします。品質60で保存された写真は、スライダーが80のとき、48でエンコードされます。再スケーリングは、2回目のパスがピクセルが提供できない品質を主張するのを防ぎます。品質60のファイルを90で再エンコードすると、既に焼き込まれた損傷を説明するためにバイトを消費するだけです。下のエンコーダーはMozJPEGです。もう一つ知っておくべきこと：圧縮はすべてのメタデータ、EXIF、GPS、ICCプロファイル、埋め込みサムネイルを削除します。向きは生き残ります。

なぜスライダーの横の推定値が結果と一致しないのですか？

それはエンコードではなく曲線だからです。パネルは何も実行される前にその数値を印刷しますが、それはファイルサイズとスライダー位置の2つの要素からのみです。それは元のバイトをスライダーを100で割った値で掛け、1.8のべき乗に上げたものです。それは画像のピクセルを一切見ず、上記の再スケーリングについても知りません。そのため、品質60の例では、エンコーダーが48を使用しようとしているときに、80の数字を印刷します。

同じ538.6 KBのテストファイルでは、ギャップが広く、範囲全体で方向が変わります。スライダー90では、パネルは実際の347.8 KBに対して445.5 KBを予測し、28%高いです。スライダー30では、実際の131 KBに対して61.7 KBを予測し、53%低いです。100 KBの制限を目指している場合は、2番目のものをもう一度読んでください：推定では38 KBクリアしたと表示されているときに、エンコーダーは31 KB不足しようとしています。結果カードのKBが唯一の価値のある数値です。パレットPNGモードでは推定値がまったくなく、パネルはその代わりに警告を印刷します。

実際に100 KB未満のJPGを取得するにはどうすればよいですか？

まずピクセルを削り、次に圧縮します。リサイザーを開き、25、50、75のパーセンテージプリセットを使用します。50%は3840x2160を1920x1080に、ピクセルの4分の1にします。25%は960x540に、16分の1にします。また、1080x1080のInstagramスクエアから2560x1440のYouTubeバナーまで、固定寸法の15のソーシャルプリセットと、カバー、コンテイン、ストレッチフィットモードを備えた正確なピクセルモードがあります。この正確なピクセルモードは、600 x 600のパスポートスクエアを顔を潰さずに入力する方法です。4K写真から100 KBを目指す場合は、25%から始めて上に進んでください。

リサイザーについて知っておくべきことが2つあります。PNG出力はロスレスのままであり、他のすべての形式はデフォルトで品質90で再エンコードされます。そのため、両方のツールを通過するJPEGは2回エンコードされます。アニメーションソースは1つの静止フレームとして出力されます。そして、コンプレッサーの出力が入力したファイルより大きくなる場合、元のファイルがそのまま返されます。

WebPまたはAVIFはより速く到達できますか？

その表を2回読んでください。同じスライダー位置80で、JPEGは最小のファイルを生成し、AVIFは最大のファイルを生成しました。これは、上記の再スケーリングを思い出すまで逆に見えます。JPEGの80はソースの推定品質に対してスケーリングされていたため、実際には80ではありませんでしたが、WebPとAVIFはその数値を文字通りに受け取ります。AVIFのスマートデフォルト63に下げると、モダンなコーデックが先行します：WebPは200.6 KB、AVIFは186.9 KBです。どちらも3840x2160で100 KBからはまだ遠いですが、それがポイントです。AVIFはこのマシンで1エンコードあたり約10〜11秒かかり、JPEGとWebPは即座に戻ってきました。また、ブラウザサポートは若いです。私たちのJPGからWebPへのパスは4:2:0クロマに固定されているため、硬い赤のエッジが少し柔らかくなります。

ファイルが透明性を持つPNGの場合はどうなりますか？

全く異なるレバーです。900x606で942.4 KBの実際のアルファチャンネルを持つalpha.pngを両方のPNGモードで実行しました。「圧縮なし」オプションはレベル3で完全にロスレスのoxipngで、383.9 KBを返しました。これは59%の削減で、すべてのピクセルがそのままです。「より小さいファイルサイズ」オプションはlibimagequantを実行し、画像をパレットに減らし、98.3 KBを返しました。これは90%オフで、寸法に触れずに100 KBの予算をクリアします。パレットは滑らかなグラデーションを帯状にするため、出荷前に空や柔らかい影を確認してください。透明性は両方のモードで生き残ります。JPEG出力を要求すると、アルファチャンネルは消え、白にマット化されます。

クロップして100 KBにすることはできますか？

部分的に。クロップはピクセルを削除するため、バイトも削除されます。私たちのクロッパーは、最大10 MBの1つのファイルを取り、8つのアスペクトプリセットとカスタムW:H比を提供します。ピクセル単位で目標幅を入力するフィールドはないため、正確な出力サイズを目指すことはできません。ロッシーフォーマットのクロップはすべて、ハードコードされた品質92で再エンコードされます。GIFは単一フレームのPNGとして戻ってきます。バイト予算を達成するには、リサイザーのパーセンテージプリセットがより直接的なハンドルを提供します。

これらの操作で写真がアップロードされることはありますか？

いいえ。このアプリにはAPIルートやサーバーアクションはなく、唯一のネットワークリクエストは、同一オリジンのフェッチで自身のアセットとWASMコーデックを取得するものです。ファイルはキャンバスにデコードされ、同じタブでWASMによって再エンコードされます。このカテゴリーの他のツールのほとんどは逆の方法で動作します：画像がサーバーに送信され、保持タイマーが発火するまでそのストレージに保管されます。それが私たちのプライバシーページで説明されている違いです。また、ここでのバッチが10ファイルと50 MBに制限されている理由でもあります。あなた自身のCPUが作業を行っているからです。その同じ制限が300ファイルのフォルダはブラウザの仕事ではない理由でもあります。