EXIF Orientation — the sideways photo problem

Open a JPG on a phone and you see it the right way up. Open the same file on an old Windows machine and it's lying on its side. The pixels haven't changed — the difference is whether the viewer respects an EXIF tag called Orientation.

Why phones do this

A phone camera sensor has a fixed physical orientation. It always reads pixels in the same spatial pattern — a row corresponds to the long axis of the sensor. Saving the file means writing those pixels in their natural order, which is "landscape" for almost every phone camera regardless of how you held the phone.

To save a portrait photo correctly, the phone has two options:

1. Rotate the pixels in memory before saving (CPU work, slows down burst shooting).
2. Save the pixels in sensor order and write a metadata tag saying "this should be displayed rotated 90°" (free, instant).

Phones do option 2. The Orientation EXIF tag carries one of eight possible values:

The eight orientations

Values 2, 4, 5, 7 (with flips) appear almost exclusively in old scanner output and are rare in real-world phone photos.

What JPG2PDF does

JPG2PDF reads the EXIF Orientation tag of each input. If the value is anything other than 1, the JPEG is rotated to its visual upright orientation before embedding into the PDF. The PDF's pixel data already reflects the correct orientation, so the page renders right-side-up in any viewer.

Modern auto-rotate utilities perform this step losslessly when possible — rotating in the DCT domain rather than decoding to RGB and back — which keeps the JPEG's pixel data byte-identical to a "correctly oriented from start" file. When the image dimensions don't fall on the block boundaries that lossless rotation requires, the utility may pad or crop a few pixels at the edges; the visual difference is imperceptible.

Why this matters for PDFs

PDF Image XObjects don't have an Orientation tag. There is no PDF mechanism for "this image should be displayed rotated"; the only way to encode rotation is in the page's content-stream matrix (cm) or by physically rotating the pixels.

If the PDF tool ignores EXIF Orientation and embeds the JPEG bytes as-is with a default placement, every user opening the PDF sees the photo on its side. The PDF reader has no signal that anything is wrong.

This is the single most common complaint about JPG-to-PDF tools that don't read EXIF: "I can see the photo right-side-up in my Photos app, but when I make it a PDF it's sideways." The fix is on the converter side, not the user side.

The /Rotate page flag is not a substitute

PDF's /Rotate property sits on the Page object and rotates the entire page in 90° increments. Some converters use it as a shortcut: leave the JPEG in sensor orientation and set /Rotate 90 on the page.

This works in viewers but has edge cases:

• Tools that paste the page into another document (combining PDFs) may or may not respect /Rotate when re-laying out.
• OCR tools that run over the PDF often ignore /Rotate and read the underlying pixel orientation, producing garbage text.
• Print shops sometimes flatten /Rotate incorrectly and print the photo sideways anyway.

JPG2PDF prefers physical rotation of the JPEG over /Rotate for these reasons.

How to check a JPEG's orientation

Open the file's EXIF panel in any photo viewer (right-click → Properties on Windows, "Get Info" on Mac, or any photo-management app's info panel) and look for the Orientation tag. Common readouts: "Rotate 90 CW" (value 6, the most common phone-photo case) or just the integer value 1–8. If the tag is missing, the photo has no rotation hint and is treated as orientation 1.