← Blog

DPI math — how a 4032×3024 phone photo lands on A4

The math behind embedding a JPEG into a PDF page is straightforward arithmetic, but it routinely confuses people because two intuitions about DPI fight each other. The first intuition: "300 DPI is high quality." The second: "to fit on a page, I should pick a low DPI so the photo is bigger." Both are true — and both are about different things.

DPI is a divisor, not a quality setting

DPI ("dots per inch") is the conversion factor between pixels and inches. For a raster image of W × H pixels, the physical size on a page at D DPI is:

width_in  = W / D
height_in = H / D

Higher DPI → smaller image on paper. Lower DPI → larger image. The photo's pixels don't change. What changes is how many physical inches the renderer is asked to stretch them across.

Page size in points

PDF measures everything in points (1 pt = 1/72 in). A4 portrait is 595 × 842 pt = 8.27 × 11.69 in. US Letter is 612 × 792 pt = 8.5 × 11.0 in. To fit a photo onto a page, you need:

required_DPI_x = pixel_width  / page_width_in
required_DPI_y = pixel_height / page_height_in
required_DPI   = max(required_DPI_x, required_DPI_y)

The max ensures the photo fits in both dimensions; whichever axis is more constrained wins.

Worked example: phone photo on A4

4032 × 3024 pixels (typical 12 MP phone photo) on A4 portrait (8.27 × 11.69 in):

required_DPI_x = 4032 / 8.27 = 487.5
required_DPI_y = 3024 / 11.69 = 258.7
required_DPI   = 488 (rounded up to fit safely)

The photo lands at 8.27 in wide (full A4 width) by 6.20 in tall (centered with white space top and bottom).

If we auto-rotate to landscape A4 (842 × 595 pt = 11.69 × 8.27 in):

required_DPI_x = 4032 / 11.69 = 344.9
required_DPI_y = 3024 / 8.27 = 365.7
required_DPI   = 366

The photo lands at 11.02 in wide by 8.27 in tall (matches A4 height; leaves a thin strip on the long axis). Landscape gives more area for landscape-orientation photos and is what JPG2PDF picks automatically when width > height.

What the cm operator encodes

The DPI is not stored as a number anywhere in the PDF. It is encoded as a transformation matrix in the page's content stream:

q                              % save state
595 0 0 446 0 198 cm           % scale and translate
/Im0 Do                        % paint the image
Q                              % restore state

The cm operator declares the image's bounding rectangle directly: 595 pt wide × 446 pt tall, offset 0 right and 198 up from the page's bottom-left corner. The image is logically a unit square (1 × 1); the matrix scales it to those dimensions.

From the matrix, you can back-compute DPI: DPI = pixel_width × 72 / matrix_width = 4032 × 72 / 595 = 488. The PDF spec doesn't require you to store DPI; it lets the matrix imply it.

What this means for quality

JPG2PDF does not resample the JPEG. The pixels stay byte-identical to the source. DPI affects only how the rendered image is scaled at view/print time:

On a 4K monitor at 100% zoom, a 488-DPI photo on an 8.27-in-wide page is rendered into a screen rectangle of 8.27 × 220 = 1820 pixels (assuming 220 PPI display). The reader scales 4032 source pixels down to 1820, with high-quality resampling.
On print at the page's stated size, the printer fits 4032 source pixels into 8.27 inches, producing 488 effective DPI of physical print resolution. This is well above the threshold of human visual acuity (~250 DPI on print) — the image looks sharp.

If you reduce DPI to make the image bigger on the page (e.g. 96 DPI), the on-screen and on-print scaling stretches the same 4032 pixels across more inches. At 96 DPI the photo would be 42 in wide — far larger than A4 — and you'd see jagged edges on close inspection.

What JPG2PDF picks

For each input JPEG, JPG2PDF:

Reads pixel dimensions from the JPEG header (no full decode needed).
Picks A4 portrait or landscape based on aspect ratio.
Computes the required DPI to fit, then snaps to a value that places the photo nicely (centered, with at most a small margin).
Writes the matrix into the page's content stream.

The default settings produce edge-to-edge or near-edge-to-edge photos. There is no white border by design — if you want margins, post-process the PDF or rebuild with a tool that exposes margin controls.