無料一括画像コンバーター

複数の画像をPNG、JPG、WebP間で一度に変換します。品質を調整し、ファイルサイズを比較し、すべてを瞬時にダウンロードします。

データはデバイスを離れません
ここに画像をドロップ またはクリックして参照 (JPEG、PNG、WebP、GIF、BMP、TIFF)

処理中…

画像形式変換について

各画像形式には用途があります。PNGはロスレスでグラフィックに最適です。JPGは写真に最適で、より小さいファイルを提供します。WebPは高品質でモダンな圧縮を提供します。バッチ変換は、複数のファイルを処理するときに時間を節約します。

JPEG(1992)、写真の形式

Joint Photographic Experts Group は1986年11月にニュージャージー州 Parsippany で結成され、メンバーは ISO TC97 SC2/WG8 と CCITT SGVIII グループから引き抜かれました。6 年間の委員会作業の後、CCITT Recommendation T.81 のテキストは1992年9月18日に承認され、同一のテキストが1994年に International Standard ISO/IEC 10918-1 として公開されました。この二重公開は JPEG が世界の写真フォーマットになった瞬間です。数学的コアは 8×8 ピクセルブロックに適用される離散コサイン変換です:各ブロックはコサイン波の合計に分解されます、人間の視覚が最も敏感ではない高周波成分は、目が最初に気付く低周波成分よりも積極的に量子化されます。ユーザー側の「品質」スライダーはまさにそれです、量子化テーブルの乗数。より高い品質はより小さな除数、より高い精度、より大きなファイルを意味します。より低い品質は量子化後により多くのゼロ、より良いエントロピーコーディング、目に見えるブロックと「リンギング」アーティファクトのコストでより小さなファイルを意味します。JPEG は設計上非可逆です:JPEG ラウンドトリップが入力と数学的に同一になる品質設定はありません。自然シーンの写真には、顔、風景、食べ物、滑らかなグラデーションと連続トーンを持つもの、これは重要ではありません、損失は人間の視覚感度しきい値の下で生きていてファイルは可逆フォーマットが生成するサイズの一部を表します。鋭いエッジ、テキスト、ライン アート、または大きな平らな色のグラフィックには、JPEG は間違った選択です:同じ DCT が鋭いエッジをリンギングアーティファクト(「mosquito noise」)で滲ませ、8×8 セル間にブロック境界を生成します。

PNG(1996年10月 / 1997年1月)、可逆グラフィックフォーマット

PNG（Portable Network Graphics）は、既存の選択肢が抱える 2 つの問題、すなわち GIF の特許問題（後述）と TIFF の複雑さへの意図的な回答として、W3C 外の非公式グループによって 1994 年に開発されました。仕様は 1996 年 10 月 1 日に W3C 勧告として承認され、1997 年 1 月 15 日には IETF から RFC 2083 として公開されました。正誤表を取り込んだ第 2 版は 2003 年 11 月 10 日に W3C 勧告となり、APNG、HDR 対応、Exif 処理を加えた第 3 版は 2025 年 6 月 24 日に公開されました。PNG は可逆圧縮で、エンコードされたすべてのバイトを復元できます。内部的には、PNG ファイルは型付きチャンクの並びです（IHDR ヘッダー、IDAT 圧縮データ、IEND 終端マーカー、さらにカラープロファイル・透明度・ガンマ・メタデータ用の任意の補助チャンク）。ピクセルデータは圧縮率を最大化するために走査線ごとに 5 種類の行フィルター（None、Sub、Up、Average、Paeth）のいずれかで前処理され、その後 zip ファイルや gzip と同じアルゴリズムである DEFLATE にかけられます。PNG は 4 つのカラーモードに対応します。グレースケール、アルファ付きグレースケール、インデックスカラー（最大 256 項目のパレット、いわゆる PNG-8）、そして 8 ビットのアルファを任意で持てるトゥルーカラー RGB（PNG-24、アルファ付きは PNG-32）です。アルファチャンネルはピクセルごとに 256 段階の部分透明をサポートしており、これにより、PNG-8 のインデックス透明がかつて生んでいた悪名高い「白いふち」なしに、どんな背景の上でもアイコンの縁をアンチエイリアスできます。PNG はウェブ用フォーマットとアーカイブ用フォーマットを同時に目指して設計されており、その二重の役割こそ、スクリーンショット、ロゴ、線画、チャートなど、ファイルサイズよりピクセル単位の完全な再現が重要なあらゆる画像で今も既定の選択肢であり続ける理由です。

GIF(1987年6月15日)、アニメーションのサバイバーと特許サーガ

CompuServe のエンジニアリングリードである Steve Wilhite は、特定の問題を解決するために1987年6月15日に GIF を導入しました:CompuServe オンラインサービスの遅いモデムでカラー画像を共有する方法、ファイルがユーザーの月額割り当てを食いつぶさないように。彼のチームは Lempel-Ziv-Welch(LZW)圧縮アルゴリズムを選択し、カラーパレットを 256 エントリに上限しました。1987年に CompuServe が知らなかったのは、LZW が1985年に Sperry Corporation(後の Unisys)によって特許されていたことです。特許問題は1994年後半に公的に爆発しました。Unisys は1995年にアルゴリズムを使用するソフトウェア(GIF、TIFF、PDF を含む)に収益の約 0.45 % 〜 0.65 % のロイヤリティを請求すると発表しました。オープンソース Web コミュニティは 2 つの並行アクションで応えました:「Burn All GIFs」キャンペーンと PNG の設計、特許のない GIF 置換として明示的に意図されたもの。Unisys の米国特許は2003年6月に失効、他の管轄での対応する特許は2004年まで失効しました。2004年までに、GIF はその歴史で初めて特許のない状態になりました。GIF は PNG が(元々)持っていなかった機能のおかげで生き残りました:アニメーション。それはフレームごとのタイミングと透明パレットインデックスを持つフレームのシーケンスをサポートします、それはループするリアクション画像と Web バナーのリングアフランカにします。256 色パレットは写真の実際の制限で、1 ビットの透明度はカラー背景にレイヤーされたときに醜いエッジを生成しますが、漫画タイプのコンテンツの短いループアニメーションには、GIF はまだ普遍的サポートで勝ちます。

BMP(1990年5月)と TIFF(1986年秋)、レガシーサバイバー

BMP(Bitmap、Windows Device Independent Bitmap とも呼ばれる)は1990年5月22日にリリースされた Windows 3.0 に組み込まれ、そこで Windows グラフィカル環境でビットマップストレージの標準になりました。それは本質的に非圧縮で、生のピクセル配列、行ごとに 4 バイトに整列されたオプション、先頭に小さなヘッダー。1920×1080 24 ビット BMP は約 6.2 MB です、品質 85 の JPEG での同じ画像はおそらく 200 KB です。2026年の BMP の役割は本質的にレガシー交換フォーマットと Windows スクリーンショットが歴史的に使用したフォーマットです。TIFF(Tagged Image File Format)は1986年秋に Aldus Corporation によって最初に公開されました(リビジョン 3.0)、1992年6月のリビジョン 6.0 は CMYK と YCbCr カラー、JPEG-in-TIFF を追加しました。Adobe は1994年に Aldus を買収し、現在著作権を所有しています。TIFF は単一のエンコーディングスキームではなくコンテナフォーマットであるという点で独特です、単一の TIFF ファイルは複数の画像を含むことができ(マルチページ TIFF、ファックスとスキャンされた本の章で一般的)、いくつかの圧縮方法のいずれか(なし、LZW、ZIP、JPEG、ファックス用 CCITT グループ 3/4)を使用でき、そのタグ付きフィールド構造を介して本質的に任意のメタデータを保存できます。この柔軟性は TIFF をプレプレスワークフロー、スキャン、ドキュメントアーカイブのデフォルトにします、Web 画像にはほぼ決して使用されません。入力リストでの存在は印刷意図またはスキャンされたソースを Web フレンドリーフォーマットに変換するユーザーのためです。

WebP(2010年9月30日)、現代の Web フォーマット

Google は2010年9月30日に同等の品質で JPEG より小さいファイルを生成する Web 上の非可逆圧縮トゥルーカラーグラフィックの新しいオープンフォーマットとして WebP を発表しました。フォーマットは VP8 ビデオコーデックのキーフレームエンコーディングに基づいています、Google が On2 Technologies の購入で取得しました。最初は WebP は非可逆のみでした。2011年11月18日、Google は可逆圧縮モードと可逆と非可逆の両方の透明度サポートを発表しました、libwebp 0.2.0 は2012年8月16日に安定可逆実装に到達しました。Google の開発者ドキュメントによると:可逆 WebP 画像は同じ画像の PNG より約 26 % 小さく、非可逆 WebP 画像は同等の SSIM 品質で比較可能な JPEG より 25-34 % 小さい。これらの削減は魔法ではありません、JPEG と PNG が設計された 1990 年代初期の基礎に対して根本的に新しいコーデック設計(予測フレーム内コーディング、現代の算術エントロピーコーディング、よりスマートなカラー変換)から来ます。ブラウザサポートは徐々に構築されました:Chrome 17 が2012年2月(非可逆)、Chrome 23 が2012年11月(可逆)。Apple は10年のほとんどの間持ちこたえ、最終的に2020年9月の iOS 14 と macOS 11 Big Sur と一緒に出荷された Safari 14 で WebP サポートを追加しました。その2020年9月の日付は、iPhone ユーザーの JPEG フォールバックなしで WebP が主要な Web フォーマットとして実用的に使用可能になった瞬間です。今日のカバレッジはグローバルトラフィックの約 97 % です、WebP は留保付きの「現代」フォーマットではなくなりました、それはデフォルトです。

WebP を超えて、AVIF(2019年2月)、HEIC(2017)、JPEG XL(2018-)

AVIF v1.0.0 は2019年2月19日に Alliance for Open Media(AOMedia、Google、Netflix、Microsoft、Mozilla、Cisco、Intel、Amazon、Apple のコンソーシアム)によって公開されました。それは AV1 ビデオコーデックの静止画像プロファイル、HEIF コンテナの上に構築され、最良の圧縮を持つ現在広く展開されている画像フォーマットです、同等の視覚品質で、AVIF ファイルは通常 JPEG より 50 % 小さく、WebP より 20-30 % 小さいです。ブラウザサポートは 3 波で到来:Chrome 85(2020年8月)、Firefox 93(2021年10月)、iOS 16(2022年9月)と macOS Ventura(2022年10月)の Safari。HEIC は2017年の iOS 11 以降の iPhone のデフォルトフォーマットです、HEVC 圧縮画像を持つ HEIF コンテナ、正式には ISO/IEC 23008-12。圧縮は優れています(通常 JPEG より 50 % 小さい)が HEVC は特許で重荷になっています、それが Chrome、Firefox、非 Apple Edge が HEIC をネイティブにデコードすることを拒否する理由です。JPEG XL(ISO/IEC 18181、2022)は技術的に優れているがニッチなフォーマットです、既存の JPEG を可逆に約 20 % 小さく再圧縮でき、HDR、ワイドガマット、アニメーション、プログレッシブデコードをサポート、特許がありません。Chrome は2022年10月31日に実験的フラグを廃止しました(「Halloween 決定」)、Apple は2023年9月に macOS Sonoma、iOS 17、visionOS にネイティブ JPEG XL を持つ Safari 17 を出荷しました。フォーマットは Safari 17+ でネイティブにサポートされ、Firefox と Chrome 145(2026年2月)でフラグの後ろにあります、しかし一般トラフィック用のデフォルト出荷はまだ保留中です。この変換器は現在 AVIF、HEIC、JPEG XL を出力しません、上流で処理することを決められるようにここにリストされています。

正しい出力フォーマットを選ぶ

上のフォーマット別の物語はツアーです。実用的な質問はより短い:特定の画像と特定の使用が与えられた場合、どの出力フォーマットが正しいか?

品質スライダーが実際に行うこと

品質スライダーは 5 のステップで 10 から 100 まで進みます。このシンプルな数字の背後には、知覚品質とファイルサイズの間に驚くほど非線形の関係があります。JPEG には、画像処理エンジニアリングの合意は品質 75-85 がスイートスポットということです。品質 80 で、ファイルサイズは正常な画面表示距離で見えない視覚的差異で非圧縮ソースから 70-90 % 落ちます。品質 80 から 85 への落差は急です:代表的なテスト画像は品質 80 で 3.7 MB から品質 85 で 6 MB になる可能性、電話やラップトップ画面で見える改善なしのほぼ倍増。品質 75 は高周波詳細(テキストエッジ、細かいテクスチャ)の近接検査でアーティファクトが検出可能になり始める場所です。品質 90 以上は、ファイルサイズが重要ではないアーカイブ JPEG 用です。デフォルト 80 はスイートスポットの低い端にあります、バッチ Web 最適化に適切で、目標は許容できると感じる画像を維持しながらできるだけ少ないデータを出荷することです。WebP には、canvas API のデフォルト toBlob('image/webp') は品質 0.80 です、品質 70 の WebP は通常品質 80 の JPEG と同じくらい視覚的にきれいです。PNG には、「品質」は誤称です、PNG は常にピクセルデータで可逆です。このツールのスライダーは PNG が出力フォーマットとして選択されたときに効果がありません。バッチ処理の重要な教訓:単一の品質設定は混合バッチのすべての画像にめったに正しくありません。同じカメラで同じ照明で撮られた 50 枚の写真のフォルダはおそらくすべて品質 80 の JPEG に保存して問題ありません。スクリーンショット、写真、ライン アート、ロゴを混合するフォルダはできません、ワンクリックの「すべてを JPG-80 に変換」はスクリーンショットを読めない mosquito noise に変えます。コンテンツが変動するとき入力を別々のバッチに分割してください。

非可逆 vs 可逆、最も重要な区別

可逆エンコーダはデコードされた出力がエンコードされた入力とビット単位で同一であることを保証します。PNG は可逆です。WebP-lossless は可逆です。TIFF(その可逆モードで)は可逆です。トレードオフはファイルサイズです:可逆エンコーダは知覚不可能な知覚的差異を活用できず、すべてを保存しなければなりません。可逆 PNG での 1920×1080 写真は 5 MB かもしれません、JPEG-品質-85 での同じ写真は 200 KB です。PNG はビット完全です、JPEG は視覚的に同等です。非可逆エンコーダは人間の視覚システムが最も気付かない可能性のある情報を破棄します、高周波詳細、彩度の高い色での細かいクロマ変動、すべてのグラデーションの 4 番目の有効桁。JPEG、非可逆 WebP、非可逆 AVIF はすべてこれを行います。バッチ変換器の意味は具体的です:可逆から可逆(PNG から PNG、または PNG から WebP-lossless)は任意の数の変換にわたって本当に可逆です、同じ品質で非可逆から非可逆(JPEG-85 から JPEG-85)は可逆ではありません、各再エンコードが別の量子化ステップを適用、10 回繰り返すと結果は目に見えて劣化します、非可逆から可逆(JPEG から PNG)は既存のアーティファクトを所定の位置に凍結しますがそれらをさらに劣化させません、可逆から非可逆は変換時に非可逆圧縮を導入し、後で破棄された詳細を回復する方法はありません。ユーザーはしばしばノーオプであることを期待して変換を再実行します。可逆から可逆のケース以外、そうではありません。

EXIF、IPTC、XMP、なぜこのツールはそれらを除去するか

カメラと電話の JPEG と HEIC ファイルは EXIF ブロックを持ちます、画像ヘッダーに埋め込まれた Exchangeable Image File Format メタデータ。EXIF はカメラモデル、レンズ、露出設定、日付と時刻、ソフトウェアバージョン、そして最も重要な、写真が撮られた場所の GPS 座標(キャプチャ時に位置情報サービスがオンだった場合)を含みます。IPTC メタデータはキャプション、バイライン、著作権、キーワードを追加します。XMP、元々 Adobe からのもの、は古いフォーマットを包含する XML ベースのスーパーセットで、Lightroom と Photoshop が使用するものです。プライバシーへの影響は重大です。位置がオンの iPhone で撮られた写真は数メートル以内に正確な GPS 座標を埋め込みます。フォーラムで共有、メールに添付、または個人ブログ経由で共有すると、写真家の自宅住所、子供の学校、職場、ハイキングルートを漏らす可能性があります。主要なソーシャルプラットフォーム(Facebook、Instagram、Twitter/X)はアップロード時に画像を他のユーザーに提供する前に EXIF を除去します、しかし元のメタデータ自体を読み取って保存します。小さなフォーラム、WordPress ブログ、Discord、メールクライアント、直接ファイル転送は EXIF をそのままにします。Canvas API を介した再エンコード(このツールが使用するエンジン)はデフォルトですべての EXIF、IPTC、XMP メタデータを破棄します。出力は埋め込まれた来歴のないクリーンな画像で、プライバシー機能であり、Canvas パイプラインの副作用です(canvas はピクセルデータのみを保存、保存するメタデータの概念はありません)。メタデータを保持したいユーザー(露出データをアーカイブする写真家、著作権がファイルと一緒に移動しなければならないコンテンツワークフロー)は別のツールを必要とします、通常 ImageMagick の convert または専用の EXIF 認識ライブラリ。この変換器は反対方向に切ります:設計によりメタデータを除去します、それがプライバシーを意識するユーザーが GPS 座標を追跡されたくない場所のフォーラムに画像を送信するときに望むことです。

透明な背景、PNG から JPEG の選択

PNG はピクセルあたりのアルファチャンネルをサポートします:各ピクセルは 0(完全に透明)から 255(完全に不透明)の不透明度を持ちます。JPEG にはアルファチャンネルがありません。透明度を持つ PNG を JPEG に変換すると選択を強制します:透明ピクセルは何になるべきですか? Canvas API のデフォルトは透明黒に対して合成することです、結果の JPEG は透明ピクセルを不透明黒に解決します。透明背景に変換された PNG ロゴは、ロゴ周りの黒い角で出てきます、ユーザーが望んだことはほぼ確実にありません。緩和策は画像をその上に描画する前にキャンバスを選択した背景色(白が典型的なデフォルト)で塗りつぶすことです。透明度を保持する必要があるユーザーは出力フォーマットとして PNG または WebP を選ぶべきです。WebP は可逆と非可逆の両方のモードで透明度をサポートします、ソースが透明度を持ち宛先が効率的でなければならないときの現代の選択です、50 KB の透明 PNG ロゴはアルファチャンネルを保持しながら 12 KB の非可逆透明 WebP になる可能性があります。

ブラウザでの変換の仕組み

「すべてがブラウザで実行される」という主張は、最近になってバッチ画像変換器を信頼できるクライアント側製品にするのに十分強力になった 3 つの Web プラットフォーム API に依存します。FileReader API と Blob:アップロードゾーンにファイルをドロップすると、各 File は readAsDataURL()(古いコールバック)または file.arrayBuffer()(Promise ベース)のいずれかを公開する Blob のサブクラスです。画像には特に、よりシンプルなパスは URL.createObjectURL(file) で Blob URL を構築し、それを新しい Image 要素に割り当てて、ブラウザの組み込み画像デコーダに JPEG、PNG、GIF、WebP、BMP をネイティブに処理させることです。Canvas API:Image がロードされると、変換は 2 ステップのダンスです、ctx.drawImage(img, 0, 0) で描画、それから canvas.toBlob(callback, type, quality) で canvas を読み戻す。type パラメータは MIME 文字列('image/png'、'image/jpeg'、'image/webp')、quality パラメータは非可逆フォーマット用の 0 と 1 の間の数。OffscreenCanvas と Web Workers:大きなバッチには、メインスレッドですべての canvas 作業を行うと UI がブロックされます。現代のソリューションは OffscreenCanvas で、ワーカーコンテキストで canvas 操作を公開し、それ自体は postMessage を介して Web Worker に転送可能でコピーなし。ワーカーは別のスレッドでデコード-ラスタライズ-エンコードパイプラインを実行し、ページを応答性のあるままに保ちます。一緒に、これらの API は 50 ファイルのバッチをスクロールやボタンクリックをブロックせずに数秒で実行させます。JSZip、MIT ライセンスの純粋 JavaScript ライブラリ、はブラウザの保存ダイアログがトリガーされる前に最終的な ZIP パッケージングをメモリで完全に処理します。アップロードなし、サーバー zip なし、ディスク上の一時ファイルなし。10 年前、ブラウザで実行されるバッチ画像変換器は好奇心の対象だったでしょう。WebAssembly のパフォーマンス、OffscreenCanvas の並列処理、現代の電話 RAM(6-12 GB)とコア数(6-8 CPU)はその画像を反転しました。プライバシー議論はケースを閉じます:サーバー側変換器は画像をサードパーティマシンにアップロードする必要があります、厳密な削除ポリシーがあっても、アップロード自体はログ、傍受、または侵害される可能性のあるネットワークイベントです。ブラウザのみの変換器は決して 1 バイトも送信しません。

よくある質問

どの画像形式がサポートされていますか?

コンバーターは、ほとんどの一般的な形式(JPG、PNG、GIF、WebP、BMP、TIFF)を処理し、PNG、JPG、WebPに変換します。

JPGとWebPの品質を調整できますか?

はい。品質スライダーを使って圧縮(0-100)を調整します。値が高いほど品質が良くなりますが、ファイルが大きくなります。

複数のファイルをダウンロードするには?

「すべてZIPでダウンロード」を選択して、変換されたすべての画像を1つのZIPアーカイブにまとめ、ダウンロードと保存に便利です。

なぜバッチあたり 50 ファイルの制限ですか?

メモリ上限です。各画像は canvas が再エンコードする前に生のピクセルデータとして RAM にデコードされなければなりません。iPhone 12 メガピクセル写真は約 36 MB のピクセルデータ(1200 万ピクセル × 3 バイト RGB、または 4 バイト RGBA)にデコードされます。一度に 50 個は 1.8 GB の作業メモリです。ほとんどのラップトップは快適に処理しますが、古い電話はそうではありません。50 ファイルの上限はデバイス間でページを予測可能に保ちます。より大きなバッチには、ツールをラウンドで実行してください、たとえば 50 ファイル、ダウンロード、クリア、別の 50 ファイルをドロップ。

ファイルあたりのサイズ制限はありますか?

ハード上限はありません、制限はデバイスの利用可能なメモリです。単一の 50 MP 画像は約 150 MB のピクセルデータにデコードされます、デスクトップでは動作しますが古い電話では苦労します。経験則として、10 MB 未満のファイルは本質的にすべてのデバイスでスムーズに変換されます、50 MB 以上のファイルはローエンドモバイルで遅くなったり失敗したりします。変換がフリーズしたら、ページをリフレッシュしてより小さなバッチでファイルを試してください。

変換器は EXIF メタデータを除去しますか?

はい、設計により。Canvas 再エンコードパイプラインはピクセルデータのみを保存します、つまり EXIF、IPTC、XMP メタデータブロック(カメラモデル、露出設定、GPS 座標、著作権タグ、編集履歴)はラウンドトリップを生き残りません。出力は埋め込まれた来歴のないクリーンな画像で、GPS 座標を追跡されたくないフォーラムやメール連絡先で写真を共有するときのプライバシー勝利です。メタデータが保持される必要がある場合(露出データをアーカイブする写真家、著作権タグを必要とするコンテンツワークフロー)、これは正しいツールではありません、メタデータを明示的に保持する ImageMagick の convert または専用 EXIF 認識ライブラリを使用してください。

PNG を JPG に変換するときに透明背景はどうなりますか?

JPEG にはアルファチャンネルがないので、ソース PNG の透明ピクセルは出力 JPEG で不透明色にならなければなりません。canvas のデフォルト動作はカラー背景(通常白)に対して合成することです。透明 PNG 背景のロゴは JPEG に変換すると透明度を失い、背景塗りつぶしを取ります。透明度が重要な場合は、出力フォーマットとして PNG または WebP を選んでください、両方ともアルファを保持します。WebP-lossy は劇的に小さいファイルサイズで PNG より透明度を保持し、透明 Web グラフィックの現代の選択です。

私の画像はどこかにアップロードされますか?

いいえ。各ステップ、ファイル選択、デコード、canvas 再エンコード、ZIP パッケージング、ダウンロード、は JavaScript を介してブラウザで完全に実行されます。サーバー側処理はありません。変換中にブラウザの DevTools の Network タブを開いて確認できます:画像データを運ぶ発信リクエストはありません。ページは機微なスクリーンショット、ドキュメントスキャン、位置メタデータ付きの個人写真、または見知らぬ人のハードドライブにコピーされたくないあらゆるものに安全です。

関連ツール

PDF → HTML

PDFをHTMLに瞬時に変換します。

Base64エンコーダー

画像をBase64にエンコードします。

テキスト → CSV

データをCSV形式に変換します。