無料画像圧縮オンライン
JPEG、PNG、WebP画像を最大80%まで圧縮。 即座に結果が出て、サーバーへのアップロードは一切ありません。
JPEG、PNG、WebPに対応・各最大50 MB
設定
使い方
- 上記に1つ以上の画像を選択またはドロップします。
- 画質スライダーを調整します(低いほどファイルが小さく、圧縮率が高くなります)。
- 画像はブラウザ内で圧縮されます・アップロードはありません。
- 圧縮された画像を個別にまたは一括でダウンロードします。
なぜ画像を圧縮するのか?
大きな画像はウェブサイトの表示を遅くし、直帰率を上げ、Google検索順位を下げます。 画像を圧縮することで、目に見える品質低下を最小限に抑えながらファイルサイズを50~80%削減できます。 これはウェブ開発者、ブロガー、ECストア、そしてオンラインでコンテンツを公開するすべての人にとって不可欠です。 小さな画像はモバイルデバイスの通信量も節約し、Core Web Vitalsのスコアを向上させます。
「画像圧縮」が実際に意味すること
画像圧縮は、名前を共有する2つの根本的に異なる操作をカバーします。非可逆圧縮は、JPEGと非可逆WebPで使用され、人間の目が気づきにくい画像データ (影の細部の微妙な階調、高周波ノイズ、人間視覚に調整された色対明度比のクロマサブサンプリング) を破棄します。出力は入力より小さいですが、ビット単位で再構築することはできません。可逆圧縮は、PNG、GIF、TIFF-LZW、可逆WebPで使用され、DEFLATE (LZ77 + Huffman) などのアルゴリズムを使用して正確なピクセルデータをよりコンパクトにエンコードします。出力は小さく、解凍するとオリジナルをバイト単位で再現します。どちらが正しいかは画像によります: 写真はそのコンテンツが目がピクセルレベルで追跡できないテクスチャでいっぱいなので、非可逆を美しく許容します; ロゴ、スクリーンショット、シャープな色遷移を持つグラフィックは、すべてのピクセルが意図的なので可逆を要求します。
JPEGコンプレッサーの品質設定 (このツールのスライダー、10-100%) は、DCTステップ後に適用される量子化テーブルを制御します。品質100ではテーブルは周波数係数をほとんど丸めません; 品質50では積極的に丸めます。より高い品質は、より細かいディテールを持つより大きなファイルを意味します; より低い品質は、平坦な領域に目に見えるブロック状のアーティファクトを持つより小さなファイルを意味します。60%のデフォルトはウェブ使用のスイートスポットにあります: 通常、典型的な画面で知覚できる変化なしに50-80%のファイルサイズ削減です。印刷や大きな表示の作業の場合、80-90%にプッシュしてください。サムネイルやメール向けバージョンの場合、30-50%で問題ありません。
PNGの場合、「品質」スライダーはPNGが常に可逆であるため、通常の意味では適用されません。このツールがPNG入力に対して実際に行うことは、ほとんどのオーサリングソフトウェア (Photoshop、Affinity、Sketch) がデフォルトで気にするより強力なDEFLATEパスを実行することです; これは通常、ピクセルの変更ゼロでファイルサイズを5-25%削減します。フォーマットドロップダウンを使用するとPNGをJPEGまたはWebPに変換することもできます。これは可逆をはるかに小さなファイルと交換しますが、JPEG出力の場合は透明度を失い、(写真コンテンツの場合は) WebPの可逆保証を失います。最大幅オプションは圧縮中に画像をリサイズします: 1920ピクセルにダウンサイズされた4000ピクセル幅の写真は、圧縮が実行される前でも生のピクセル数で75%節約するため、品質削減と重なります。
このツールが内部でどのように動くか
圧縮エンジンはDonald Wong (GitHub: Donaldcwl/browser-image-compression、MITライセンス) によるbrowser-image-compressionです。約95 KBに最小化された純粋なJavaScriptライブラリで、3つのブラウザプリミティブをラップします: バイトを読み取るためのFile API、JPEG/WebP画像のデコード、リサイズ、再エンコードのためのCanvas API (または利用可能な場合はOffscreenCanvas)、Canvasを経由せずにPNGを処理するためのUZIP (小さなDEFLATEライブラリ) です。画像をドロップすると、ブラウザはバイトをライブラリに渡します; ライブラリは入力形式と要求された出力に基づいてパスを選択します。
JPEGおよびWebP入力の場合、パスはcanvasへのデコード、オプションで設定された最大幅にリサイズ、その後canvas.toBlob(mimeType, quality/100)を呼び出します。ブラウザの組み込みJPEGまたはWebPエンコーダーが実際の量子化とHuffmanコーディングを行います。品質はスライダー値を100で割ったもので、第2引数として渡されます。PNGとして保持されるPNG入力の場合、ライブラリはCanvasを完全にスキップし (Canvasラウンドトリップは不必要に可逆データを再ラスタライズします)、代わりにPNGファイルのIDATチャンクで直接UZIPを最大圧縮努力で実行します。これがPNG-to-PNG圧縮がここで本物の可逆である理由です: ピクセルデータは決してデコードおよび再エンコードされず、DEFLATEラッピングのみが締められます。
OffscreenCanvasがサポートされている場合 (現代のChrome、Edge、Safari、Firefox)、重いデコード-リサイズ-エンコード作業はWeb Worker内で実行され、メインUIスレッドの応答性を保ちます。20枚の写真のバッチをドロップして、各写真が処理される間にページをスクロールし続けることができます。古いブラウザでは、ライブラリはメインスレッドにフォールバックし、それでも動作しますが、大きなジョブ中にページをブロックします。パイプライン全体はあなたのタブ内で実行されます。ライブラリは最初の訪問時にCDNから一度ロードされ (約95 KB最小化)、その後キャッシュされます。ファイルコンテンツがブラウザを離れることはありません。バッチを圧縮しながらDevToolsのNetworkタブを開くと、一度限りのライブラリフェッチが表示されますが、それ以外は何も表示されません。
画像圧縮形式の簡単な歴史
- DCT、1972-1974年。 Nasir Ahmedは1972年に画像圧縮の方法として離散コサイン変換を提案しました; 正式なアルゴリズムは1974年にT. NatarajanとK. R. Raoと共に発表されました。この単一の数学的変換は、今日世界のすべてのJPEG、MPEG、H.26xビデオファイルの下にあります。
- JPEG、1992年。 Joint Photographic Experts Group (1986年結成) は1992年にJPEGをITU-T T.81 / ISO/IEC 10918-1として標準化しました。8x8 DCTブロック、オプションのクロマサブサンプリングを持つYCbCrカラー、人間の視覚に調整された量子化テーブル。写真豊富なウェブを可能にしたフォーマットです。
- PNG、1996年。 UnisysのLZW特許主張が開かれたウェブを脅かした後、GIFを置き換えるためにIETFでRFC 2083として作成されました。DEFLATE (LZ77 + Huffman) 圧縮、常に可逆、完全なアルファ透明度、特許の負担なし。3rd Edition仕様 (W3C、2023) は、HDR、APNGアニメーション、EXIFメタデータを公式に追加しました。
- WebP、2010年。 GoogleはVP8ビデオコーデックのフレーム内コーディングに基づく静止画像フォーマットとしてWebPをリリースしました。非可逆WebPは同等の視覚品質でJPEGより25-34%小さく実行されます; 可逆WebPはPNGより約26%小さく実行されます。採用には10年かかりました; 2026年までに世界の96%以上のブラウザがそれをサポートしています。
- AVIF、2019年。 Alliance for Open MediaはAV1ビデオコーデックの静止画像バリアントとしてAVIFをリリースしました。同等の品質でJPEGより約50%小さい。ブラウザサポートは現在95%+ですが、日常のオーサリングツール (Photoshop、Word、Slack) でのエンコーダーサポートは遅れています。SquooshとImageMagickは今日AVIFを生成できます; ほとんどのカメラと電話はできません。
- HEIC、2017年。 AppleはiPhoneのデフォルト写真フォーマットとしてHEIF/H.265ベースのHEICを採用しました。同等のJPEGの約半分のサイズです。ロイヤリティが負担されているため、オープンウェブで提供されることはめったにありません。ほとんどのオンラインアップローダー (このツールを含む) は、JPEGへのデスクトップ変換後にのみHEICを受け入れます; その変換は、電話の写真を非Apple受信者に送信するための日常的なワークフローです。
対応フォーマット
- JPEG · 写真や複雑な画像に最適。 品質を調整できる非可逆圧縮。
- PNG · グラフィック、ロゴ、透明度のある画像に最適。
- WebP · Googleの最新フォーマットで、同等の品質でJPEG/PNGより小さなファイルサイズを実現。
実世界の圧縮ワークフロー
- ブログとウェブサイトの画像。 電話カメラから直接の2 MB JPEGと250 KBの圧縮されたJPEG: 典型的な画面で人間の目には同じですが、小さいファイルは約8倍速く読み込まれます。Core Web Vitals (LCP) スコアが直接改善されます。複数の写真があるほとんどのページは、JavaScriptやCSSの最適化からではなく、画像圧縮から最大のLighthouseパフォーマンス向上を見ます。
- ソーシャルメディアのアップロード。 Instagram、Twitter、Facebook、LinkedInはすべて、独自のアルゴリズムを使用してアップロード時に画像を再圧縮します。最初に圧縮することで、何が犠牲にされるかを制御できます; 生の写真をアップロードすると、プラットフォームがあなたのためにそれらの選択を行い、多くの場合目に見える劣化を伴います。
- メール添付ファイル。 ほとんどのプロバイダーはメッセージごとに25 MBの添付ファイルを上限としています (Gmail、Outlook、Apple Mail)。~50 MBから~10 MBへの写真フォルダーの圧縮により、複数の送信に分割したりクラウド共有リンクに移動したりする代わりに、単一のメールですべてを送信できます。
- eコマースの商品写真。 数百から数千の写真がある商品カタログは、大きなCDN帯域幅請求と遅いページ読み込みを見ます。ライブラリ全体を圧縮することで両方をカットします。Shopify、Etsy、Amazonの売り手は、ホスティングコストを下げて検索ランキングを改善するために、アップロード前に圧縮することが一般的です。
- スクリーンショット重視のポートフォリオ。 UIデザインのポートフォリオは、スクリーンショットがJPEGアーティファクトが目に見える鋭い色遷移を持っているため、PNG重視です。より緊密なDEFLATEを通じたPNG-to-PNGは通常、ピクセル変更ゼロで10-20%節約し、レンダリング品質を犠牲にすることなく高速を保つ必要があるデザイナーポートフォリオサイトに役立ちます。
- アーカイブのダウンサイジング。 電話からの12メガピクセルの写真は、画面でのみ閲覧される家族共有アルバムには過剰です。80%品質で4メガピクセルにリサイズ: 結果はそれを見るすべてのデバイスで同じに見え、アーカイブは元のサイズの5分の1に縮小します。オリジナルはソースディスクで安全に保たれ、圧縮版は共有またはバックアップに行きます。
よくある落とし穴とその意味
- JPEGを何度も再圧縮すると劣化します。 各JPEG保存はDCT量子化ステップを再実行し、決して回復できないディテールを失います。損失は最初のパスでは微妙で、3回目または4回目には明らかです。常に最高品質のソース (元のカメラファイル、デザインツールからのエクスポート) から圧縮し、先週保存した以前に圧縮されたJPEGからではありません。調整が必要な場合は、PNGまたはTIFFでマスターコピーを保持してください。
- PNG-to-JPEGは透明度を落とします。 JPEGはフォーマット仕様にアルファチャンネルを単純に持っていません。PNGをJPEGに変換すると、透明なピクセルはすべて白の固体 (またはエンコーダーが置き換えるもの) になります。ロゴ、アイコン、透明な背景を持つスクリーンショット、またはアルファチャンネルを持つグラフィックの場合、PNGに留まるかWebPに移動してください。どちらも透明度を保持します。
- JPEG-to-PNGはファイルを大きくします。 PNGのDEFLATE圧縮は、滑らかなグラデーションや大きな固体領域には優れていますが、JPEG圧縮が残す高周波ノイズパターンにはひどいです。JPEGをPNGに変換すると、品質の向上なしにファイルサイズが2倍または3倍になることがよくあります。JPEGから可逆が必要な場合、すでに手遅れです: 元の情報は失われています。変換は、特にPNGの透明度またはJPEGを受け入れないツールが必要な場合にのみ意味があります。
- EXIFメタデータはデフォルトで削除されます。 browser-image-compressionライブラリは、再圧縮中にEXIFメタデータ (カメラ情報、GPS座標、撮影日、ICC色プロファイル) を破棄することをデフォルトとします。ウェブ使用にとっては通常機能です (GPS座標の漏洩は実際のプライバシー問題です)。メタデータを無傷でアーカイブする写真家にとって、このツールは正しくありません; ImageOptimやjpegtranなどのデスクトップコンプレッサーを明示的なpreserve metadataフラグで使用してください。
- 色プロファイルが生き残らない可能性があります。 埋め込まれたICC色プロファイル (sRGB、Adobe RGB、ProPhoto) は、ディスプレイにピクセル値の解釈方法を伝えます。Canvasベースの再エンコードは、埋め込まれたプロファイルを破棄し、出力をsRGBとしてタグ付けする可能性があります。通常の画面使用には、ほとんどすべてがsRGBであるため問題ありません。印刷準備作業、色管理された写真準備、または広色域配信物の場合、プロファイルデータを明示的に保持する色対応ツール (PhotoshopのExport As、Affinity、RawTherapee) を使用してください。
- 非常に大きな画像はモバイルブラウザタブをクラッシュさせる可能性があります。 Canvasに画像をデコードするには、その寸法に比例したRAMが必要です: 24メガピクセルの写真 (6000x4000ピクセル) はRGBAピクセルバッファだけで約96 MB必要で、エンコーダーのワーキングメモリも必要です。4 GB RAMのモバイルデバイスは、エンコードが完了する前にOSによってタブが終了する可能性があります。入力をリサイズするか、非常に大きな写真にはデスクトップブラウザを使用してください。
プライバシー: 画像はデバイスに残る
すべてのクラウド画像コンプレッサー (TinyPNG、Compressor.io、Optimizilla、Smallpdfの画像ツール、Pixlrのcompressエンドポイント、数十のオンライン画像圧縮サービス) は、ファイルをオペレーターのサーバーにアップロードし、圧縮アルゴリズムを実行し、より小さい画像をダウンロードとして返します。写真はルーチン的に識別可能なコンテンツを含むため、プライバシーへの影響は非自明です: 顔、背景に見える住所、内部UIまたは機密文書のスクリーンショット、子供の写真、プライベートな空間で撮影された写真。ほとんどのオペレーターは、1時間または2時間以内にアップロードを削除し、転送中に暗号化することにコミットするプライバシーポリシーを公開しており、より大きなもの (TinyPNG、Smallpdf) はISO/IEC 27001認証を保持しています。彼らはそれらのポリシーを尊重する強い商業的理由があります。しかし「1時間以内に削除」は「決して見られない」ではありません。その1時間の間、画像コンテンツはオペレーターのインフラストラクチャに存在し、適切なアクセス権を持つ任意のプロセスや人がアクセスでき、適用される保持ポリシーに従ってログとバックアップに表示されます。
このコンプレッサーは何もアップロードしません。browser-image-compressionライブラリは完全にあなたのタブで実行されます; 画像バイトはFile APIによって読み取られ、JavaScript (またはOffscreenCanvasが利用可能な場合はWeb Worker) で処理され、圧縮された出力は同じタブにダウンロード可能なBlobとして返されます。バッチを圧縮する前にブラウザの開発者ツールをNetworkタブに開いて、画像コンテンツを含むリクエストが発火しないことを確認することで、アップロードがないことを確認できます。唯一のネットワークトラフィックは、最初の訪問時のCDNからの一度限りのライブラリフェッチ (~95 KB) で、その後ライブラリはキャッシュされます。ページがロードされた後にブラウザを機内モードに切り替えると、コンプレッサーはローカルファイルで動作し続けます。機密性のあるもの (顔、場所、内部スクリーンショット) を含む写真の場合、ブラウザ側の取引は明らかに価値があります。
別のツールが正しい選択になるとき
- スクリプト化されたパイプラインで500以上の画像をバッチ処理します。 Node.jsで
sharp(標準的なサーバーサイド画像ライブラリ)、コマンドラインでImageMagickまたはGraphicsMagick、Pythonで Pillow を使用してください。これらのツールはブラウザメモリ制限なしで数千のファイルを処理し、CIジョブ、デプロイフック、cronタスクから実行されます。 - 検証可能なビット平等を伴う厳格な可逆保証。 PNG-to-PNGの場合、UZIPはピクセルデータに触れないため、このツールは本物の可逆です。暗号化検証を要求するワークフロー (医療画像、法的証拠) の場合、明示的な`-define png:compression-level=9`とデコードされたピクセルデータのSHA-256検証を持つImageMagickのようなデスクトップツールを使用してください。
- 印刷グレードの色プロファイル保存。 ICCプロファイル保存、ソフトプルーフィング、CMYK出力を伴う印刷準備作業には、Adobe Photoshop、Affinity Photo、またはRawTherapeeを使用してください。Canvasは sRGB で動作し、埋め込まれたプロファイルデータを削除する可能性があるため、ブラウザベースの圧縮は色管理されたワークフローを保証できません。
- 次世代圧縮のためのAVIF出力。 browser-image-compressionは2026年現在AVIFを出力しません。ブラウザでのAVIFエンコーディングには、Squoosh (Googleも、クライアントサイドも) を使用してください; コマンドラインAVIFには、libavifから
avifencを使用してください。AVIFは同等の品質でJPEGより約50%小さいファイルを生成しますが、エンコーダーは計算的に高価です (JPEGエンコーディングよりも10倍遅い)。
よくある質問
圧縮すると画質は低下しますか?
デフォルトの60%品質では、ほとんどの画像がオリジナルとほぼ同じに見えつつ、サイズは50~80%小さくなります。 用途に合わせてスライダーを調整してください。
ファイルサイズの制限はありますか?
各画像は最大50 MBまで対応しています。 処理はブラウザ内で行われるため、非常に大きなファイルはデバイスによって少し時間がかかる場合があります。
画像はサーバーにアップロードされますか?
いいえ。 すべての圧縮処理はブラウザ内のローカルで行われます。 画像はあなたのデバイスから離れることはなく、完全にプライベートで安全です。
どの画質設定を使うべきですか?
ウェブ用途には60~70%が最適です。 印刷やポートフォリオには80~90%を試してください。 最大圧縮(サムネイル、メール)には30~50%が適しています。
よくある質問のさらに
なぜ私のPNG出力はオリジナルよりわずかに小さいだけですか?
PNGは可逆です。節約は、オーサリングツール (Photoshop、Sketch、Figma) がデフォルトで書いたものよりも、同じピクセルデータのより緊密なDEFLATE圧縮を見つけることから完全に来ます。これは通常5-25%を節約します。PNGがすでに十分に最適化されていた場合、残された余地はあまりありません。意味のある追加の削減を得るには、WebPに変換するか (透明度を保持し、PNGより通常25%小さい)、JPEGに変換することによっていくらかの損失を受け入れてください (はるかに小さくできますが透明度を落とします)。
このツールはオフラインで動作しますか?
最初の訪問の後、はい。browser-image-compressionライブラリ (約95 KB最小化) は最初のロードでブラウザによってキャッシュされます。コンプレッサーへのその後の訪問は、ブラウザキャッシュがその間にクリアされていない限り、完全にオフラインで動作します。一度ページを開いてからエアプレーンモードを有効にし、ローカル画像を圧縮することで確認できます。
私のEXIFデータ (カメラ、GPS、撮影日) は保持されますか?
いいえ、EXIFメタデータはデフォルトで圧縮中に削除されます。ウェブ共有にとってこれは通常望ましいです (GPS座標とカメラのシリアル番号は漏洩すべきではありません) が、メタデータを無傷でアーカイブする写真家にとってこのツールは正しくありません。メタデータを保存するために、ImageOptim (macOS) または `-copy all` オプションを持つjpegtranのようなEXIF対応デスクトップコンプレッサーを使用してください。
最大幅リサイズと品質削減の違いは何ですか?
リサイズは画像のピクセル寸法を変更します: 1920x1440にリサイズされた4000x3000の写真はエンコードするピクセルが75%少なくなり、圧縮が実行される前にファイルサイズをカットします。品質削減 (スライダー) は、JPEGまたはWebPエンコーダーがDCT係数をどれだけ積極的に丸めるかを制御し、エンコードされたデータをピクセルあたり小さくします。2つはスタックします: まずリサイズして全体のピクセル数を落とし、次に残りを品質削減します。典型的な「これをウェブフレンドリーにする」ワークフローの場合、最大幅1920、品質70を設定し、出力は元のサイズの約10-15%です。
iPhoneからHEIC画像を圧縮できますか?
HEICのデコードに対するブラウザサポートは限られています (Appleデバイス上のSafariはそれを行います; ChromeとFirefoxは行いません)。非Appleブラウザでは、このツールはHEICファイルを拒否します。iPhone写真のワークフローは、iPhone設定 (カメラ → フォーマット → 互換性優先) を変更してJPEGを直接保存するか、Macまたは専用ツールでHEICをJPEGに一度変換し、それらのJPEGをこのコンプレッサーを通して実行することです。iCloudの「共有」シートは通常、非Apple受信者と共有するときにJPEGに自動的に変換します。
デスクトップまたはコマンドラインに同等のものはありますか?
いくつかあります。バッチ自動化には、Node.jsのsharpが標準的なサーバーサイドライブラリで、ほぼ同一の出力を生成します。ImageMagick (magick input.jpg -quality 70 output.jpg) とGraphicsMagickは巨大なファイルを処理し、任意のシェルから実行します。jpegoptimとoptipngは専門のJPEGとPNG再エンコーダーで、汎用ツールに対して数パーセント余分に絞り出すことがよくあります。このツールのような単発のインタラクティブな作業ですがより多くのコントロールがあるものには、Squoosh (Google Chrome Labs、完全にクライアントサイド) がAVIFを含むより広範な形式をサポートします。