ブラウザでの画像リサイズのしくみ
すべてのリサイズは JavaScript のみで動く短いパイプラインです。コーデックライブラリのダウンロードは不要で、サーバーも関与しません。ブラウザ組み込みの Canvas API がファイルをデコードし、目標サイズで再描画し、メモリ上で再エンコードして、ページがプレビューや ZIP にまとめられる Blob を渡します。すべての処理がタブのサンドボックス内で行われるため、元のファイルはネットワークに届きません。
- アップロードされた各ファイルを Blob として読み込み、オブジェクト URL を生成して、ブラウザがサーバーにバイトをコピーしたりディスクに書き込んだりせずにデコードできるようにします。
- 選択したモード（最長辺の上限、幅と高さの指定、またはパーセント倍率）から目標寸法を計算します。縦横比ロックにより、一方のフィールドを編集したときに比率が正しく保たれます。
- 目標サイズのオフスクリーン Canvas を作成し、
ctx.drawImage(source, 0, 0, width, height)を呼び出してデコード済みピクセルを再描画します。ブラウザはスケール結果を滑らかにする補間を処理します。 canvas.toBlobを呼び出してソース形式で再エンコードします。PNG はロスレスのまま、JPEG と WebP は高品質設定で再エンコードされます。ページは前後比較カードを表示し、画像ごとのダウンロードまたは fflate でメモリ上に構築した単一 ZIP を提供します。
なぜ画像をリサイズするのか
- 巨大な画像はページが遅くなる最も一般的な原因です。4000×3000 のスマホ写真を 600 ピクセル幅のレイアウトにそのまま入れると、画面が表示できるより約 40 倍多いピクセルが送信されます。アップロード前に最長辺を 1600 px に制限するだけでページの重さを大幅に削減し、Core Web Vitals の LCP を改善できます。
- アップロードフォームは厳格な寸法を要求します。アバタースロット、証明写真ポータル、ECサイトの商品リスト、OG ソーシャルカードにはすべて固有のピクセルサイズがあります：Open Graph プレビューは 1200×630、アプリアイコンは 512×512、サムネイルは 150×150。正確な数値を指定すれば、アップロード却下のループを回避できます。
- メールやチャットツールは大きなファイルを静かに再圧縮することがあり、きれいなスクリーンショットが台なしになる場合があります。自分で適切な幅にリサイズすることで、他者の非可逆処理パイプラインに委ねるのではなく、結果を予測可能に保てます。
- ギャラリーやカタログではバッチの一貫性が重要です。混在したサイズの写真フォルダを単一の 800×800 ターゲットで処理することで、すべてのカードがグリッド上に揃い、巨大な画像がレイアウトを崩すことがなくなります。
主な活用シーン
元の寸法と送り先の要件が一致しないとき、いつでもリサイズが必要になります。同じパターンが繰り返し登場します。
- Shopify や WooCommerce ショップの商品写真を準備する。4000 ピクセルのカメラ原本フォルダを最長辺 1600 px に制限することで、ストアフロントの読み込みが速くなり、縦横比が維持されるので画像が歪みません。
- 一つのマスターファイルからソーシャルとアプリのアセットを生成する。Open Graph カード用に 1200×630 を正確に設定し、次にアプリアイコン用に 512×512 を設定して、重いエディタを開かずに数クリックで書き出せます。
- QA やサポートのスクリーンショットをチケットに添付する前にバッチで圧縮する。50 枚フォルダを 50% にスケールすると、バグトラッカーに入れる前のアーカイブサイズを通常約四分の三削減できます。
実践例: 4000 px 写真を 1600 px の Web 画像へ
スマートフォンから取り出したばかりの 4000×3000 写真は、あらゆる Web レイアウトが必要とする以上にはるかに大きい一般的なペイロードです。リサイズが節約できる量を測る公平な基準です。
写真をアップロードゾーンにドロップし、モードを最長辺を制限のままにして値を 1600 に設定します。Canvas パイプラインは縦横比を維持したまま 1600×1200 で画像を再描画し、元の形式で再エンコードします。出力カードには新しいサイズとファイルサイズが表示されます。典型的な JPEG では数メガバイトから数百キロバイトに下がります。カードのダウンロードをクリックして単一ファイルを取得するか、一度に複数の画像をリサイズした場合はDownload .zip をクリックしてください。ドロップからダウンロードまでの全行程は一瞬で完了し、ページ自体の読み込み後は帯域幅を一切消費しません。
リサイズモードは何種類ありますか？
3 種類あります。最長辺を制限は幅または高さの長い方をピクセル値で制限し、もう一方をそれに合わせてスケールします。変形しない安全なデフォルトです。幅 × 高さを指定は両方の数値を入力でき、最初のフィールドを編集すると元の比率から 2 番目のフィールドが自動計算される縦横比ロック機能付きです。フォームが非比例の正確なサイズを要求する場合はロックをオフにしてください。パーセントでスケールは両方の寸法を一つの係数で乗算します。バッチ全体を一度に半分にしたり 2 倍にしたりするのに便利です。一般的なターゲットをカバーする 6 つのワンクリックプリセット（1920×1080 から 150×150 サムネイルまで）も使えます。
処理はデバイス上で行われますか？
はい。ページはブラウザのネイティブ Canvas API と Web File API を使用してメモリ上で各画像をデコード、再描画、再エンコードします。画像データはサーバーに送信されず、一時アップロードもなく、クラウドとの往復もありません。自分で確認できます：DevTools を開いてネットワークパネルに切り替え、リサイズを実行してください。外向きのリクエストとして見えるのは初期ページ読み込みと広告コールのみです。画像に関するデータはタブを離れません。そのためスキャンした身分証明書、医療画像、その他アップロードしたくない素材にも安全です。
リサイズで品質は下がりますか？
縮小（ダウンスケール）は非常に優秀で、ブラウザがソースピクセルを少ないピクセルに平均化するためディテールが鮮明に保たれ、ファイルも大幅に小さくなります。ソース解像度を超えた拡大（アップスケール）では、もともと存在しなかったディテールを生み出すことはできないため、小さな画像を拡大するとぼやけて見えます。これはこのツール固有の限界ではなく、すべてのリサイザーに共通する制限です。出力はソース形式を維持します：PNG はロスレス、JPEG と WebP は高品質設定で再エンコードされるため、元の画像との見た目の違いはほとんど分かりません。
対応ファイル形式は何ですか？
入力側ではブラウザがデコードできる任意の形式を受け付けます：PNG・JPEG・WebP・GIF・BMP はスマートフォン、カメラ、スクリーンショットツールが生成するほぼすべてのファイルをカバーします。Canvas エンコーダーが対応している場合は出力もソース形式を維持します — PNG・JPEG・WebP はそのまま往復できます。GIF と BMP（Canvas API でデコードはできるが再エンコードはできない）はロスレス PNG として保存されます。リサイズ後のファイル名には新しいサイズが含まれます（例: photo-1600x1200.jpg）ので、バッチの整理が簡単です。
画像をドロップし、サイズを選んでリサイズ。すべてタブ内で完結します。アップロード不要、アカウント不要、サーバーの待機なし。