ここに写真をドロップ
またはクリックして選択 — JPEG, PNG, WebP、枚数制限なし
必要なサイズを入れるだけ — 200KB、1MB、5MB — 収まる品質はこちらで探します。
ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。
ここに写真をドロップ
またはクリックして選択 — JPEG, PNG, WebP、枚数制限なし
「品質74」が欲しい人は、まずいません。欲しいのはアップロードフォームを通る写真です。制限は2MB、スマホから出てきたファイルは5.4MB、やることは片方の数字をもう片方より小さくすること — ただし写真が崩れない範囲で。だからこのページの主役は目標サイズモードです。上限を打ち込めば(200KB、2MB、フォームが要求する数字を)、品質の値はこちらで割り出します。まず当たりをつけてエンコードし、出てきた実際のbyte数を測り、残った範囲を半分に切ってまたエンコードする。両側から挟み込んで、あなたの数字のすぐ下に着地するまで繰り返します。品質パラメータに対する二分探索で、たいてい4〜6回で収束します。しかも毎回、サイズの見積もりではなく本物のエンコード結果を量っています。スライダーを手で動かすのも結局は同じ探索で、ただ遅くて計算が下手なだけです。
既定では形式はそのままです。JPEGを入れればJPEG、PNGを入れればPNG。元のファイルがあった場所に拡張子ごとそのまま戻せるので、相性の心配も出てきません。形式を変えたらどれだけ得なのかを知りたいときは、比較をオンにしてください。同じ画像がWebPとAVIFにもエンコードされ、目標を満たした品質での3つのサイズが横に並びます。差は本物ですし、引き換えになるものもはっきり書いておきます。WebPは今どき問題になる場所がほぼありません。AVIFはサイズで大きく勝つことが多い代わりにエンコードがずっと遅く(大きな写真なら数ミリ秒ではなく数秒)、古いソフトや一部のデスクトップ画像ビューア、いくつかのCMSではまだ開けません。数字を見て、出す先のことを考えて選ぶのが正解です。
フォルダごと放り込めば1回で全部片付きます。各ファイルに圧縮前のサイズ、圧縮後のサイズ、そこに届いた品質、削減率が並び、上にはバッチ全体の合計が大きく出ます。すべてブラウザの中の話です。ファイルはローカルで読み、Web Worker内でエンコードし、ふつうのダウンロードとして返ってきます。アップロードは一切なし — プライバシーの話としてはそうですが、このページでは速度の話でもあります。サーバー方式の圧縮は画像を全部上げて結果を全部下ろす必要があるので、20枚のバッチは1byteも圧縮されないうちに40回の通信になります。ここには往復のコストがそもそも存在せず、上限はあなたのマシンだけ、ネットワークを切っても動き続けます。
正直に書いておくべきことが一つ。これは非可逆の再エンコードです。画像は画素に戻され、より低い品質でもう一度エンコードされるので、画素は変わります。それこそが削れたKBの出どころで、1200万画素の写真を100KBまで絞ると800KBのときより甘く見えるのもそのためです。画素に触らずにファイルを小さくしたいのなら、行き先はメタデータ削除のページです。EXIF・GPS・サムネイルのブロックをbyte単位で切り落とし、画像をデコーダに渡すことすらしないので、出力はビット単位で同一のまま数KBから数百KB軽くなります。可逆でできる節約はそれで全部なので、5MBの写真を2MB以下にすることはできません。ただ、必要だったのが数百KBだけなら、まずタダのほうを取って、足りなかったときにここへ戻ってくればいい話です。
何かの80%ではありません。画素の80%でもファイルサイズの80%でもなく、絶対的な画質の80%でもない。JPEGの場合、この数字は量子化テーブルの組を選ぶもので、8×8ブロックごとの細かい情報をどれだけ大胆に丸めるかが決まります。WebPやAVIFでも、そのコーデックの同等のつまみを動かしているだけです。目盛りはエンコーダごとの独自のものなので、あるエンコーダの品質80と別のエンコーダの品質80は、同じ絵にも同じサイズにもなりません。同じ80でも、ノイズだらけの夜景と平坦なスクリーンショットではファイルサイズが桁違いに変わります。目標サイズモードがある理由はまさにそこです。画像をまたいで意味を持つ数字は「出てきたファイルの大きさ」だけなので、このツールはつまみを信じてもらう代わりに、それを実測します。
一世代目の劣化の上に、二世代目を上乗せして払っているからです。JPEGはすでにデコーダが再構成した絵で、アーティファクトも含めてそれが中身です。それを圧縮するというのは、その再構成をデコードしてもう一度量子化することで、しかも前の世代のブロック境界やリンギングを「保存すべき本物の細部」として扱ってしまいます。ビットの使い道としては最悪です。何度も繰り返せば、エッジや文字のまわりがおなじみのぐずぐずになります。ですから元データがあるなら — カメラのファイル、PNG書き出し、編集ソフトのマスター — 圧縮済みのものを再圧縮するのではなく、そこから一発で圧縮してください。JPEGしか手元にない場合、目標サイズへの丁寧な一回は問題ありません。効くのは五回やることです。
残りません。再エンコードはcanvasを通りますが、canvasが知っているのは画素だけなので、出力にEXIFは一切入りません。GPS座標もカメラの機種も撮影日時も、埋め込みサムネイルもなし。多くの人にとってこれは損ではなく得で、圧縮した写真は同時にメタデータの消えた写真になります。ただし消したいのがメタデータだけなら、そのために圧縮するのは損です。メタデータ削除のページはそのブロックをbyte単位で消して画素をビット単位でそのまま残すので、同じ結果のために画質を一世代払うより明らかに得です。
PNGが可逆形式で、形式の中に回せる品質のつまみが存在しないからです。画素はそのまま正確に格納されるので、PNGを小さくする道は「同じ画素をもっと賢く格納する」か「異なる画素の種類を減らす」しかありません。このツールがやるのは前者だけです。oxipng がフィルタとDeflateの選択をやり直し、同一の画像のより良い符号化を探すので、戻ってくるのは同じ絵のまま小さくなったファイルです。パレット削減はしません — 色を捨てるのは非可逆な加工で、可逆だからPNGを選んだ人に黙ってやることではないからです。効き方はJPEGより小さく読みにくいです。平坦なUIのスクリーンショットは半分になることもあり、PNGで保存された写真はほとんど動きません。写真的なPNGをどうしても指定サイズに収めたいなら、正直な答えはJPEGかWebPに変換することで、その代償がいくらなのかもこのページが数字で見せます。
探索は品質レンジの下限で行き止まりになり、ツールはそれを黙らずに伝えます。上限を超えたファイルをそっと返す代わりに、届いた中でいちばん小さいサイズを報告します。4000×3000の写真を、人が見たいと思える20KBのJPEGにすることはできません。そこまで来ると効くつまみは品質ではなく画素数です。まず縮小してから(同じ写真の横1600px版なら必要なbyteは6分の1程度になります)もう一度試すか、出力をWebPやAVIFに切り替えてください。同じサイズならJPEGより目に見えて良い品質で届きます。その2手のどちらが効くのかを自分の目で確かめられるように、比較ビューがあります。
されません。ファイルはFile APIでローカルに開き、あなたのタブの中のWeb Workerでデコードと再エンコードを行い、ブラウザが生成したダウンロードとして返ってきます。このページは裏にAPIを持たない静的ファイルなので、アップロード先が存在せず、待ち行列もなく、透かしも入らず、マシンのメモリ以外にサイズ上限もありません。一度読み込めばオフラインでも動きます — この主張の手軽な検証にもなります。サーバーが必要なページなら、ネットワークが切れた瞬間に止まるはずですから。
Need a different format, not just a smaller file? Convert here.
Only want the metadata gone with the pixels untouched? Strip it losslessly.
Compare the compressed output against the original, pixel by pixel.