Turning a Stack of Photos Into One PDF: The EXIF Rotation Trap

The most common bug report I get on Toolium's Image to PDF tool is something like: "I uploaded photos of a contract I took with my phone and the resulting PDF has every page rotated 90 degrees sideways." Every single time, the root cause is the same: EXIF orientation metadata, and the fact that pdf-lib does not currently apply it when embedding images. This post explains what is going on, why it is a surprisingly hard problem to fix correctly, and the workaround that works every time.

The mechanics of Image to PDF

The tool does something conceptually simple: it takes a list of images, creates a new empty PDF, and adds one page per image where the page is sized to the image's natural dimensions. Each image is embedded directly - JPEGs go in as JPEG-encoded streams without re-encoding, PNGs go in as PNG-encoded streams. The output PDF size is essentially the sum of the input image sizes plus a small amount of PDF structure overhead.

This is much better than the alternative of re-encoding the images, because re-encoding would either lose quality (lossy re-encoding) or increase file size (lossless re-encoding of an already-lossy source). The "embed directly" approach preserves the original image bytes.

The flow:

Drop your images. They appear as cards in a list.
Drag to reorder. The PDF pages will follow the order top-to-bottom.
Click "Create PDF." Output downloads.

For most uses - a few screenshots assembled into a documentation PDF, a series of receipt photos turned into one expense report - this works perfectly the first time.

The EXIF orientation problem

Phone photos taken in portrait orientation are usually stored on disk as landscape images with an EXIF orientation flag that tells viewers "rotate this 90 degrees when displaying." This is a holdover from the days of cameras with a rotation sensor; the JPEG file itself is always written with the same pixel layout, and the orientation is a metadata field.

Most modern viewers (Photos on macOS, Photos on iOS, Windows Photo Viewer, web browsers when displaying via the <img> tag) read the orientation flag and rotate accordingly. So when you look at a portrait phone photo on your computer, it looks portrait. But when you read the file's raw bytes - which is what pdf-lib does to embed it in the PDF - you get the landscape pixel layout, and the orientation flag gets thrown away.

The result: every portrait phone photo ends up landscape inside the PDF.

The fix is to pre-rotate the image before embedding it, applying the EXIF orientation to the pixel data and stripping the metadata. pdf-lib does not currently do this. Most other browser-based "image to PDF" tools also do not, in my testing. Acrobat does, as does Preview on macOS when you use File > Export As PDF.

The workaround

The reliable fix is to re-save the image with the orientation applied to the pixels. On a Mac, opening the image in Preview and using File > Export (with no quality change) writes a new file with the orientation burnt in. On Windows, opening in the Photos app and using Save As does the same thing. On iOS, sending the photo to yourself via email or AirDrop sometimes applies the rotation; it depends on the destination app.

If you have a lot of photos to convert and the workaround is tedious, ImageMagick on the command line handles this in one command: mogrify -auto-orient *.jpg. This rewrites the files in place with the orientation applied to the pixels and the EXIF flag set to "normal."

I am also planning to add an "auto-rotate based on EXIF" option to the Toolium tool. The reason I have not yet is that detecting orientation from JPEG bytes requires parsing the EXIF segment, which adds complexity and a non-trivial library dependency. I want to be sure the implementation is correct before shipping it, because getting orientation wrong for some photos and right for others would be confusing.

Image quality and file size

Because the tool embeds images directly without re-encoding, the output PDF is the sum of the input image sizes plus a small overhead. Ten 2 MB JPEG photos turn into a roughly 20 MB PDF. This is the cleanest result possible - no quality loss, no surprises.

If the output PDF is too large for email or upload, the right move is to compress the source images first using the Image Compressor, then run Image to PDF on the compressed versions. The Toolium PDF Compress tool on the output cannot help much, because PDF Compress works on document structure, not embedded image data.

Page sizing

Each PDF page is sized to its image. A 1920x1080 image produces a 1920x1080-point page (about 26.7 x 15 inches at 72 DPI, way too big to print but fine for digital viewing). A 600x800 phone photo produces a 600x800-point page.

If you need standard page sizes (US Letter, A4), the current tool does not support that. For document-style PDFs that need to print correctly, a word processor or layout tool is a better fit; export to PDF directly from there. The tool is optimized for "bundle these images" use cases, not "produce a printable document" use cases.

HEIC on iPhone

Modern iPhones default to HEIC for new photos because it is smaller than JPEG at the same quality. Most browsers do not yet support reading HEIC, so the Toolium tool rejects HEIC uploads. The fix is to either change your iPhone setting to "Most Compatible" (Settings > Camera > Formats), which makes new photos JPEG, or to convert your existing HEIC photos to JPEG using the Files app on the phone before uploading.

I would like to support HEIC directly. There are JavaScript libraries that decode HEIC in the browser (libheif compiled to WebAssembly), but they add significant download size and the conversion is slow. For now, the workaround is easier than the in-browser support would be.

What this tool does not do

Multiple images per PDF page. Each image becomes its own page. To put multiple images on one page (a grid, a side-by-side comparison), assemble them into a single image first in any image editor.
Page numbers, headers, footers, or annotations. The output is a clean PDF with no extras. For document-style output, use a word processor.
OCR. If you upload photos of text, the resulting PDF is image-only and not searchable. For searchable text, run OCR after with a separate tool like Tesseract.
Compression. Each image goes in at its original size. Compress before assembling if size matters.