Converting JPG to PDF

Where JPG came from, and why it is like this

JPEG and PDF were built for entirely different jobs, and this conversion is about the job rather than the pixels. JPEG stores one photograph efficiently. PDF describes a page — its size, what is drawn on it, and what comes after it.

Putting a JPEG in a PDF gives the photograph a page. That matters when the photograph is standing in for a document, which is what almost every use of this conversion has in common: a phone photograph of a receipt, a passport, a signed form, a utility bill. The image is evidence, and evidence is expected to arrive as a document.

Is this conversion lossy?

The JPEG has already been through lossy compression once, and a browser conversion decodes it to pixels and re-encodes it on the way into the PDF — so this is a second generation. At a high embedding quality the difference is invisible. It is worth knowing about mainly because people repeat the round trip: photograph, convert to PDF, extract, convert again, each pass costing a little more.

File size usually grows rather than shrinks, sometimes substantially, because the PDF wrapper carries the re-encoded image plus the document structure around it. A folder of phone photographs converted into one PDF can be surprisingly large.

What happens to metadata, transparency and colour

EXIF is dropped, and orientation goes with it. This is the failure that actually happens on this conversion. Phone cameras frequently store the image in the sensor's orientation and add an EXIF tag saying which way to rotate it for display. Strip the EXIF and that instruction is gone — so a photograph that appeared upright everywhere else lands sideways in the PDF. If your output is rotated, this is why; rotating the PDF afterwards fixes it.

GPS coordinates go too. A privacy improvement, and a real one for photographs of documents taken at home, but it is a side effect rather than a feature.

The colour profile is dropped, so a wide-gamut photograph will be interpreted as sRGB and can look flatter.

The photograph does not become text. A PDF of a photographed receipt is a picture of a receipt — not searchable, and not readable by anything that expects text.

Why people actually need this

Submitting proof of something. The pattern is nearly universal: a form asks for a document, the person has a phone rather than a scanner, they photograph the thing, and the upload field accepts PDF only. Expense claims, rental applications, insurance, immigration paperwork, student enrolment — all the same shape.

The second situation is multi-page. A two-sided form photographed as two images has to arrive as one file with the pages in the right order, and PDF is the only container everyone involved can open.

What we measured

This conversion was run end to end before this page was written. Not "should work" — run, with the output checked:

And the ceilings measured for Image to PDF, the tool that performs it, on the hardware described on the limits page:

Not tested

The page also refuses files above 20 MB before it starts, which is a guard written into the tool rather than something the browser imposes. Why those are different.

When something else is the better answer

If the photograph is of text and the recipient needs to search it — an accounting system reading receipts, for instance — a picture in a PDF will not do. Run OCR and send the text, or send both.

If the photographs are large and the destination has an upload limit, compress them first. Compressing afterwards means rasterising the finished PDF, which is slower and, per the measured limits, much heavier on memory.

If the output comes out rotated, fix it on the PDF rather than re-photographing — the rotation was lost with the EXIF, not with the image.