Phone Photos to PDF: Why the File Comes Out Huge and a Page Turns Sideways
Images to PDF puts each photo on its own page at full pixel size, so three 3.2 MB phone-sized JPEGs became a 41.5 MB PDF, and a portrait photo came out on a landscape page. Shrink the photos before converting, and rotate the sideways page afterwards.
Images to PDF turns JPEG, PNG, GIF or BMP files into one PDF, one image per page, in upload order. It does not shrink anything, and it ignores the rotation flag that phones write into portrait photos. In one test run, three 3.2 MB JPEGs came back as a 41.5 MB PDF, and a photo flagged as portrait landed on a landscape page. Shrink the photos before you upload them, and fix the sideways page afterwards with Rotate.
The worked example
The input was three JPEGs of 4032 × 3024 pixels, about 3.2 MB each (9.7 MB together), the pixel size of a typical phone camera frame. They were synthetic images with fine noise, so they compress worse than most real photos; treat every size below as one run on 2026-10-04 against a local server built from the current source, not as a promise. The request:
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
| Step | Result |
|---|---|
| 3 JPEGs, 4032 × 3024 px | 9.7 MB in total |
| Images to PDF | 3 pages, 41.5 MB, each page 4032 × 3024 pt |
| Compress on that PDF | 39.9 MB, about 4% smaller |
| Same 3 photos resized to 1600 px on the long edge first | 1.7 MB in total |
| Images to PDF on the resized photos | 3 pages, 6.2 MB, each page 1600 × 1200 pt |
| Compress on that PDF | 6.2 MB, no smaller |
The output is named after the first file, so the download above is IMG_0001.pdf.
Why 10 MB of photos become 41 MB
A JPEG stores a photo as lossy compressed blocks. Images to PDF does not copy those bytes into the PDF. It decodes each image, converts it to 8-bit RGB, and stores the raw pixels with lossless Flate compression. One 4032 × 3024 frame is 36.6 million bytes of RGB (4032 × 3024 × 3). Flate brought that down to about 13.8 MB per page here, still more than four times the JPEG it came from. Nine copies of the same three photos made a 124.6 MB PDF.
That also explains the Compress rows. Compress recompresses streams and packs objects; it does not downsample or re-encode images. The pixels are already Flate-compressed, so there is little left to remove (why). The way to a smaller file is fewer pixels before the PDF is built.
There is a second cost. Every page takes the size of its image, one pixel to one point, so a 4032-pixel photo makes a page 56 inches wide. Viewers fit it to the window and printers scale it to the paper, but the page boxes are not A4 or Letter. The form has no option for paper size, fit, color type or auto-rotate, and the server does not read the API fields fitOption, colorType or autoRotate.
Shrink first, then convert
Resize the photos before you upload them. On a Mac, sips -Z 1600 IMG_0001.jpg --out small1.jpg does it. With ImageMagick on any system:
magick IMG_0001.jpg -resize 1600x1600 -quality 85 small1.jpg
Both turn a 4032 × 3024 photo into 1600 × 1200. In this run the three JPEGs fell from 9.7 MB to 1.7 MB and the three-page PDF from 41.5 MB to 6.2 MB. On a Letter sheet, 1600 pixels across 11 inches is about 145 dpi: readable for a photographed form, coarse for small print. Pick the size from the smallest text you need to read, not from the file-size target alone.
Size matters twice because the tools that follow also have a ceiling. A single request body is limited to 100 MiB. The 124.6 MB PDF above was rejected with a 413 (payload_too_large) when sent to Compress. See When a Large PDF Upload Is Rejected for the way around it.
The sideways page
Many phones store a portrait photo as landscape pixels and add an EXIF orientation tag that tells the viewer to rotate it. Photo apps usually obey the tag. Images to PDF does not read it: a 1600 × 1200 JPEG tagged orientation 6 (rotate 90° clockwise) produced a landscape 1600 × 1200 page.
The fix is Rotate: enter the page number, here 1, and an angle of 90. The result had /Rotate 90 set on that page, so a viewer shows it upright. Use 270 for photos tagged the other way (orientation 8) and 180 for upside-down ones (orientation 3); only orientation 6 was tested here. Rotate sets an absolute angle on the page rather than adding to the current one, and it does not re-encode the image. If you would rather not fix pages one by one, rotate the photo in your photo app and save a copy before converting.
What this tool will refuse
- HEIC and other formats. The page accepts
.png,.jpg,.jpeg,.gifand.bmp. A real HEIC file returned 400,unsupported_file_type; export it as JPEG first. - A file that is not an image. Uploading a PDF to this endpoint returned the same 400 with the message "The file is not a supported image."
- SVG. An SVG file got the same 400.
- Searchable text. Text in a photographed page stays pixels. OCR returns Markdown text; it does not add a text layer to this PDF (how it works).
- Transparency. Images are converted to RGB and the alpha channel is dropped.
Check before you send
Open the PDF and count the pages against the photos, in order. Page order is upload order; in a test, uploading a portrait PNG before a landscape one produced the portrait page first. Then look at the file size before attaching it.