Turn photos into one PDF, without re-compressing them
Most converters decode your photo, draw it onto a page and encode it again, so a 4 MB photo of a product becomes a slightly worse 900 KB photo inside a PDF. This one does not touch the image. A JPEG is embedded straight into the PDF as it is — the same bytes, the same quality, the same resolution — because every PDF reader already knows how to expand a JPEG stream.
Drop photos here, or click to choose
JPG, PNG and WebP. The page order follows the order you add them.
The difference that matters
A PDF page that shows a photo holds two things: a description of where to put the picture, and an image object holding the actual image data. That image object can be either raw pixels or an already-compressed JPEG stream, and PDF has a filter name for the second case: /DCTDecode, which is the same compression a JPEG uses.
So there is no need to decode anything. The file is placed into the object, its width and height are read out of its header, and the reader expands it on display exactly as it would expand a .jpg from disk. The image never passes through a decoder, an encoder or a canvas.
| Canvas-based converters | This tool | |
|---|---|---|
| The image data | Decoded, redrawn, re-compressed | Copied through unchanged |
| Quality after one pass | Visibly softer at 100% | Identical |
| EXIF and colour profile | Lost in the round trip | Kept, still inside the JPEG |
| Speed on a phone photo | Seconds per image | Milliseconds |
| Fine detail, text in a photo | Goes mushy first | Untouched |
When a photo does get re-encoded
Three cases, and the file list says which one applies to each image before you build anything:
- Ideally, never. A JPEG whose orientation tag is absent or says "upright" goes in untouched.
- Rotated phone photos. A portrait photo from a phone is usually stored sideways with a tag telling the viewer to turn it. That rotation has to be baked into the pixels, because a PDF image object has no orientation tag — so those photos are redrawn once, upright, at quality 92.
- PNG and WebP. Neither format can be embedded through
/DCTDecode, which only understands JPEG. They are converted to JPEG at quality 92 first. A PNG with transparency gets a white background, because a PDF page has no transparency to show it against.
Which page size to pick
A4 portrait is the default and the right choice for anything that will be printed: invoices with photos attached, a product sheet, a listing export. Mixed portrait and landscape photos all land on the same page shape, so a stack prints without anyone turning the paper.
A4, matching each photo turns the page sideways for landscape shots. It fills the page better on screen, but a printed stack alternates orientation, which most people find worse than the white space.
Exactly the photo's size gives every page the proportions of its image with no margins. Good for handing back a set of photos without the look of a document. The conversion assumes 96 pixels per inch, which is what a CSS pixel means in a browser.
What it will not do
- No text layer. These are pages holding pictures. A PDF made this way is not searchable and screen readers get nothing but an image. If you photographed a document and need it readable, that is OCR, which is a different job.
- No compression option. Because nothing is re-encoded, there is no quality slider to trade against size. If you need a 2 MB PDF from 20 photos, that is a compression job: run them through Compress to a File Size first, then build the PDF.
- No editing the output. The PDF is generated fresh each time. To reorder or remove a photo, change the list and build again — it takes a second.
- No merging with an existing PDF. That is the merge tool.
Privacy, and why it is not a slogan here
Converting images to PDF is normally a server job: upload, wait, download. That means the photos — product shots, receipts, ID documents, whatever you were packaging — sit on somebody's disk, under somebody's retention policy, usually with no way to delete them on demand.
Here the whole PDF is assembled in memory in this tab. There is no upload request, no job queue, no temporary file on a server. Open the developer tools, watch the Network tab while you build a PDF: nothing leaves. Disconnect from the network and it still works.
Questions
Does the PDF get huge compared with the photos?
It gets slightly bigger than the sum of the JPEGs, by roughly 1 KB per page plus a small object table. The image data is not re-compressed, so there is no size penalty from the conversion itself.
My photos lost their rotation. Why?
Because a PDF page has no orientation tag, the rotation is baked in during conversion. That is a deliberate re-encode, at quality 92, and only for photos whose tag is not "upright". It is the one case where the tool cannot be lossless and stay correct.
Is there a limit on how many photos?
Memory, in practice. Fifty phone photos at 4 MB each is 200 MB of image data held in the tab, which a desktop browser handles comfortably and a phone may not. Build in batches if a tab becomes sluggish.
Will the PDF open on a phone or in a print shop?
Yes. The output is a PDF 1.4 file with plain image objects and no compression filters beyond the JPEGs themselves, which is about as widely supported as a PDF can be.