画像を入れて長辺と容量を選ぶと、1枚ずつ縮んでいく
- 画像を枠に落とすか、「画像を選ぶ」から選ぶ。何枚でもまとめて入れられる。スクリーンショットは、コピーしたあとこのページでCtrl+V（MacはCommand+V）を押せば入る。
- 長辺のピクセルを選ぶ。横長の写真なら横、縦長なら縦の長さがこの値になるように縮める。元より大きくはしない。
- 送り先に容量の上限があるなら、目標の容量を選ぶ。画質を自動で下げ、それでも超えるなら長辺も縮めて、目標以下に収める。
- 1枚ずつ「保存」を押すか、「まとめてZIPで保存」で全部を1つのファイルにする。設定を変えると、入れた画像はすべてその設定で縮め直す。
Canvasで描き直すので、Exifは消えて向きだけが残る
処理はブラウザに入っているCanvasの機能だけで行う。画像を読み込み、指定の大きさのCanvasに描き、JPG、PNG、WebPのどれかで書き出す。書き出すのは描き直した画素だけなので、撮影日時、カメラの機種、位置情報（GPS）といったExifは出力に入らない。
向きだけは別に扱った。スマートフォンで縦に撮った写真には、画素を横向きのまま保存し、回す向きをExifのOrientationという値で持っているものがある。Exifを捨てるとこの指示も消え、縦の写真が横に寝てしまう。そこで読み込むときに、createImageBitmapのimageOrientationに"from-image"を渡し、Exifの向きどおりに回した画素を描いてから書き出している。
目標の容量は、1KBを1,000バイト、1MBを1,000,000バイトとして数える。送り先が1,024で数えていても1,000で数えていても、上限を超えない側に寄せた。画質はスライダーの値から50までの間を二分探索し、目標以下に収まる一番高い画質を選ぶ。画質50でも超えるときは、超えた割合から縮める幅を決めて長辺を縮め、同じ探索をやり直す。長辺100ピクセルまで縮めても収まらなければ、そう表示する。画質を30まで下げる案も試したが、写真の空や肌にブロック状の模様が出たので、先に長辺を縮めるほうを選んだ。
PNGは画質の指定がない形式で、スライダーは効かない。PNGで目標の容量を選ぶと、長辺を縮めるだけで合わせる。JPGで書き出すときに透明な部分があれば白で埋め、GIFのアニメーションは最初のコマだけになる。Canvasは色をsRGBで扱うので、色の範囲の広い写真（Display P3など）の鮮やかな色は、sRGBの中の近い色に置き換わる。
HTMLの仕様がブラウザに書き出しを求めている形式はPNGだけで、JPGとWebPは任意になっている。このページは開いたときに1ピクセルのWebPを試しに書き出し、できなければWebPのボタンを押せなくする。大きい画像を何枚も入れても動くように、処理は1枚ずつ順に行い、使い終わったCanvasはすぐ捨てる。使えるブラウザではOffscreenCanvasを使う。iPhoneとiPadでは、大きすぎるCanvasが真っ白になることがあるので、1枚のCanvasを16,777,216画素（4,096×4,096）までにして描く。
まとめて保存のZIPは、圧縮せずに格納するだけの方式（store）にした。JPG、PNG、WebPは中身がすでに圧縮されていて、ZIPで縮めてもほとんど小さくならないからだ。日本語のファイル名が文字化けしないよう、名前がUTF-8であることを示す印（汎用フラグのビット11）を付けた。
確かめた資料は次のとおり。どれも2026年10月19日に確認した。
- WHATWG「HTML Standard: ImageBitmap and animations」（createImageBitmapとimageOrientation）
- WHATWG「HTML Standard: The canvas element」（toBlobと、書き出しの形式でPNGだけが必須であること）
- PKWARE「APPNOTE.TXT」第6.3.10版（ZIPの形式、格納だけの方式、汎用フラグのビット11）
- CIPA（カメラ映像機器工業会）「規格類」のDC-008（Exifの規格）
確かめ方も書いておく。Pythonの画像ライブラリ（Pillow）で透過のあるPNGと、Exifの向きが6（右に90度回す）のJPGを作り、4,000×3,000のJPGはブラウザの中で描いて、公開したこのページで縮めた。4,000×3,000のJPGは長辺1600・目標200KBで1,600×1,200になり、JPGは画質54で198,401バイト、WebPは画質77で195,080バイトだった。長辺を元のまま・目標100KBにすると、画質50でも収まらず、926×695まで縮んで99,837バイトになった。向き6のJPGは200×320の縦長で書き出され、出力の中にExifの印は残っていなかった。ZIPを組み立てる部分はNodeで動かし、日本語の名前を含むZIP200個・1,065件をPythonのzipfileで開いて、CRCと中身と日時が全部一致した。容量を合わせる探索は、画質と大きさで容量が決まる模型で1,000通り試し、目標を超えたまま「収まった」と出た例は0件だった。
縮めるときに迷いそうなところ
iPhoneのHEICの写真は使えるか
読めるかどうかはブラウザによる。読めないブラウザでは、その画像の欄に「このブラウザはHEICを読めない」と出る。そのときは、iPhoneの設定アプリでカメラのフォーマットを「互換性優先」にすると、以後の写真はJPGで保存される。
位置情報は本当に消えるか
書き出したファイルには残らない。元の写真のファイルは変わらないので、送るのは書き出したほうにする。
500KBを選んだのに488KBより小さく表示される
目標は1KBを1,000バイトとして数え、画面の表示はWindowsと同じ1KBを1,024バイトとして出しているため。500KBの目標は500,000バイト以下で、表示では488KB以下になる。
PNGのスクリーンショットが小さくならない
PNGは画質の指定がない形式なので、画質のスライダーは効かない。小さくしたいなら長辺を縮めるか、出力の形式をWebPかJPGにする。文字の多い画面はJPGだと文字の周りがにじむので、画質を85以上にする。
画像はどこかに送られるか
送られない。読み込み、縮小、書き出し、ZIPの組み立てまで、すべてこのページの中のプログラムで行う。端末に残るのは設定だけで、画像は残らない。
画像を貼る先が重くなるとき
Excelに画像を貼ると、画面で小さく縮めても元の大きさのまま入る。スクリーンショットを何枚も貼ったブックが重くなる仕組みは、Excelのファイルが重いときの記事で測った。貼る前にここで長辺を1200ほどにしておくと、ブックは画像の分だけ軽くなる。
引き継ぎ書や手順書に画面の写真を添えるときも同じだ。書く項目と順番は引き継ぎ書の型の記事に置いた。表の画像やPDFをAIに読み取らせたなら、起こした数字の誤りはPDFの表を起こすときの確かめ方の記事の検査で拾える。