スマホの写真を PDF にする：ファイルが巨大になり、ページが横向きになる理由
「画像からPDF」は各写真を元のピクセルサイズのまま 1 ページに置く。そのため 3.2 MB のスマホサイズの JPEG 3 枚が 41.5 MB の PDF になり、縦向きの写真が横向きのページに出た。変換の前に写真を縮小し、横向きになったページは後から回転する。
画像からPDFは、JPEG、PNG、GIF、BMP のファイルをアップロード順に 1 枚ずつ 1 ページにして、1 つの PDF にまとめる。何も縮小せず、スマホが縦向きの写真に書き込む回転フラグも無視する。ある実行では、3.2 MB の JPEG 3 枚が 41.5 MB の PDF になり、縦向きのフラグが付いた写真は横向きのページに載った。アップロードする前に写真を縮小し、横向きになったページは後から「PDFの回転」で直す。
実例
入力は 4032 × 3024 ピクセルの JPEG 3 枚で、1 枚あたり約 3.2 MB（合計 9.7 MB）、一般的なスマホのカメラのフレームと同じピクセル数だ。細かいノイズを含む合成画像なので、実際の写真の多くより圧縮が効きにくい。以下のサイズはすべて、2026-10-04 に現在のソースからビルドしたローカルサーバーに対して 1 回実行した結果であり、保証ではない。リクエストは次のとおり。
curl -s -o IMG_0001.pdf \
-F fileInput=@IMG_0001.jpg -F fileInput=@IMG_0002.jpg -F fileInput=@IMG_0003.jpg \
https://pdf123.xyz/api/v1/convert/img/pdf
| 手順 | 結果 |
|---|---|
| JPEG 3 枚、4032 × 3024 px | 合計 9.7 MB |
| 画像からPDF | 3 ページ、41.5 MB、各ページ 4032 × 3024 pt |
| その PDF をPDFの圧縮 | 39.9 MB、約 4% 小さくなった |
| 同じ 3 枚をあらかじめ長辺 1600 px にリサイズ | 合計 1.7 MB |
| リサイズした写真を画像からPDF | 3 ページ、6.2 MB、各ページ 1600 × 1200 pt |
| その PDF を圧縮 | 6.2 MB、小さくならず |
出力ファイルは最初のファイルの名前になるので、上のダウンロードは IMG_0001.pdf になる。
10 MB の写真が 41 MB になる理由
JPEG は写真を非可逆圧縮のブロックとして保存する。画像からPDFは、そのバイト列を PDF にコピーしない。各画像をデコードして 8 ビット RGB に変換し、生のピクセルを可逆の Flate 圧縮で保存する。4032 × 3024 の 1 フレームは RGB で 3,660 万バイトになる（4032 × 3024 × 3）。Flate でこれが 1 ページあたり約 13.8 MB まで減ったが、元の JPEG の 4 倍以上のままだ。同じ 3 枚の写真を 9 枚分にすると 124.6 MB の PDF になった。
これは圧縮の行についても説明になる。圧縮はストリームを再圧縮してオブジェクトをまとめるが、画像のダウンサンプリングや再エンコードはしない。ピクセルはすでに Flate で圧縮されているので、削れるものがほとんど残っていない（理由）。ファイルを小さくする道は、PDF を作る前にピクセル数を減らすことだ。
もう 1 つコストがある。各ページは画像のサイズになり、1 ピクセルが 1 ポイントに対応するので、4032 ピクセルの写真は幅 56 インチのページになる。ビューアはウィンドウに合わせて表示し、プリンタは用紙に合わせて拡大縮小するが、ページボックスは A4 でもレターでもない。フォームには用紙サイズ、フィット、カラータイプ、自動回転のオプションがなく、サーバーは API のフィールド fitOption、colorType、autoRotate を読まない。
先に縮小してから変換する
アップロードする前に写真をリサイズする。Mac では sips -Z 1600 IMG_0001.jpg --out small1.jpg でできる。どの OS でも ImageMagick があれば次のようにする。
magick IMG_0001.jpg -resize 1600x1600 -quality 85 small1.jpg
どちらも 4032 × 3024 の写真を 1600 × 1200 にする。この実行では、3 枚の JPEG は 9.7 MB から 1.7 MB に、3 ページの PDF は 41.5 MB から 6.2 MB に減った。レターサイズの用紙では、11 インチに 1600 ピクセルは約 145 dpi になる。撮影した書類を読むには足りるが、小さな文字には粗い。サイズはファイルサイズの目標だけでなく、読みたい最小の文字から決めること。
サイズが 2 回効いてくるのは、後続のツールにも上限があるからだ。1 回のリクエストボディは 100 MiB に制限されている。上の 124.6 MB の PDF は、圧縮に送ったとき 413（payload_too_large）で拒否された。回避方法は大きな PDF のアップロードが拒否されるとき：100 MiB のリクエストボディ上限と、誤った方向を指すエラーを参照。
横向きになったページ
多くのスマホは、縦向きの写真を横向きのピクセルとして保存し、ビューアに回転を指示する EXIF の向きタグを付ける。写真アプリは通常このタグに従う。画像からPDFはこれを読まない。向き 6（時計回りに 90° 回転）のタグが付いた 1600 × 1200 の JPEG は、横向きの 1600 × 1200 のページになった。
直すにはPDFの回転を使う。ページ番号（ここでは 1）と角度 90 を入力する。結果はそのページに /Rotate 90 が設定され、ビューアでは正立して表示された。逆向きのタグ（向き 8）の写真には 270、上下逆（向き 3）には 180 を使う。ここでテストしたのは向き 6 だけだ。回転は現在の角度に加算するのではなくページに絶対角度を設定し、画像の再エンコードも行わない。ページごとに直したくなければ、変換の前に写真アプリで回転してコピーを保存しておく。
このツールが拒否するもの
- HEIC などの形式。 このページが受け付けるのは
.png、.jpg、.jpeg、.gif、.bmpだ。実際の HEIC ファイルは 400 のunsupported_file_typeを返した。先に JPEG として書き出すこと。 - 画像ではないファイル。 このエンドポイントに PDF をアップロードすると、同じ 400 とメッセージ「The file is not a supported image.」が返った。
- SVG。 SVG ファイルも同じ 400 になった。
- 検索可能なテキスト。 撮影したページの文字はピクセルのままだ。OCR は Markdown のテキストを返すが、この PDF にテキストレイヤーを追加することはない（仕組み）。
- 透過。 画像は RGB に変換され、アルファチャンネルは捨てられる。
送る前に確認する
PDF を開き、ページ数を写真の枚数と順番に照らして数える。ページの順序はアップロード順だ。テストでは、縦向きの PNG を横向きのものより先にアップロードすると、縦向きのページが先に来た。そのあとで、添付する前にファイルサイズを見る。