Turning images into a PDF sounds like it should be trivial, and mechanically it is. The part that goes wrong is everything around it: pages that come out the wrong size, photos that fill half a sheet with white space around them, and a five-page document that somehow weighs forty megabytes.

None of that is bad luck. Each one comes from a specific decision the converter made on your behalf, and each one is controllable once you know what the decision was.

What a PDF actually does with your image

A PDF is a page description. It defines a rectangle of a particular physical size (A4, Letter, or something custom) and then places content inside that rectangle at specific coordinates.

Your image is not converted into anything when it goes in. In almost all cases the original file is embedded whole, exactly as it was, and the PDF simply records where on the page to draw it and how large. A JPEG stays a JPEG inside the container.

This has two consequences worth holding onto. First, converting to PDF does not degrade your image, because nothing is re-encoded. Second, converting to PDF does not shrink it either, the file is at least as large as the images inside it, plus a small amount of structure.

Anyone who has emailed a "compressed" PDF of photos and watched it bounce off an attachment limit has met the second consequence.

Why DPI decides how big your photo appears

This is the single idea that explains most of the layout surprises.

An image file has pixel dimensions and nothing else. A photo that is 3000 by 2000 pixels has no inherent physical size, it is not six inches wide or ten inches wide until something decides how densely to pack those pixels onto a page.

That density is DPI, dots per inch. At 300 DPI, 3000 pixels occupy ten inches. At 150 DPI the same 3000 pixels occupy twenty inches. At 72 DPI they occupy nearly forty-two.

So when a converter places your photo on an A4 page, it is making a DPI decision, whether it tells you or not. Most tools sensibly ignore any DPI value stored in the file and instead scale the image to fit the page, which is why the result usually looks reasonable. But if a tool honours a stored 72 DPI value literally, your photo tries to be three feet wide and gets cropped or spills off the page.

The practical rule: for a photo that will be printed, aim for roughly 300 pixels per inch of final printed size. A photo printed six inches wide wants around 1800 pixels across. Below about 150 DPI, print quality starts to visibly soften. Our guide to DPI and resolution goes into this properly.

Page size, orientation and the white space problem

A PDF page has a fixed aspect ratio. A4 is roughly 1:1.41. Letter is roughly 1:1.29. Your photos are probably 3:2 from a camera, or 4:3 from a phone, or 1:1 if they came off a social platform.

Those ratios do not match, and something has to give. There are only three possible outcomes, and every converter picks one:

  • Fit the whole image inside the page. Nothing is cropped, and you get white bars on two sides. This is the safe default and what most tools do.
  • Fill the page completely. No white space, but the edges of your image are cut off.
  • Make the page match the image. No white space and no cropping, but the pages are not a standard paper size, which matters if anyone will print it.

If you are producing something to be read on a screen and never printed (a portfolio, a set of reference shots, a photo album to send to a relative), matching the page to the image is usually the nicest result. If it will be printed, stay with a standard size and accept the borders.

Orientation follows the same logic. A converter that puts every image on a portrait page will surround your landscape photos with thick bands of white. Setting orientation per image, or letting the tool choose automatically, fixes it.

A large office multifunction printer with several loaded paper drawers and a stack of paper on top
Every drawer in a machine like this holds one fixed sheet size. That is the constraint a PDF page inherits, and the reason a 4:3 photo cannot fill an A4 page without either borders or a crop. Photo: Baron Maddock (CC BY 4.0).

Why your PDF is enormous, and what to do about it

A PDF of twenty phone photos can easily run past a hundred megabytes, because it contains twenty phone photos. Modern phone cameras produce files of several megabytes each, and the PDF adds them up.

The fix is not a PDF setting. It is to make the images smaller before they go in.

Work backwards from how the document will be used:

  • Screen reading only, around 1500 to 2000 pixels on the long edge is plenty. It still looks sharp zoomed in on a laptop.
  • Printing at normal sizes, around 300 DPI at the printed size, so roughly 2500 pixels for an A4 page width.
  • Emailing, most services cap attachments in the region of 20 to 25 MB, so budget well under that.

Compressing the images in bulk first, then converting, routinely turns a 90 MB PDF into something under 10 MB with no visible difference on screen. Doing it the other way round does not work nearly as well, because a PDF compressor has to unpack, re-encode and repack images that were already compressed once.

Scanned documents are the worst offenders. A scanner set to 600 DPI colour will produce enormous files for what is essentially black text on white paper. For text documents, scanning in greyscale at 300 DPI cuts the size dramatically with no loss in readability.

Transparency, and why logos come out with a box around them

PNG files can have transparent areas. PDF pages, by default, are white paper. When a converter places a transparent PNG on a page, it has to decide what shows through, and that decision is where logos acquire an unexpected black rectangle.

Well-behaved converters preserve the transparency, so the white of the page shows through and the logo looks correct. Others flatten the image first, compositing it onto a background colour before embedding it. If they flatten onto white you will never notice. If they flatten onto black, or convert to JPEG on the way in (JPEG has no transparency at all), you get a solid block behind your graphic.

This catches people preparing letterheads, certificates and signature images, where the whole point is that the background is not there.

If it happens: composite the image onto white yourself before converting, so there is no transparency left to mishandle. It looks identical on a white page and removes the guesswork. Our guide to PNG transparency covers how to check whether a file actually has an alpha channel in the first place.

The same issue explains a subtler one. A photo with no transparency converts predictably every time; a screenshot taken on a system with rounded window corners often has transparent corners you never noticed, and those are what turn black.

One document or several?

It is worth deciding deliberately rather than defaulting to one big file.

A single document wins when the pages belong together and are read in order, a signed contract, a scanned booklet, a claim with supporting photographs. Order is preserved, nothing gets separated, and the recipient opens one thing.

Several smaller documents win when the recipient needs to file, forward or reject items individually. Sending an accountant one PDF per receipt is more annoying to produce and far easier for them to process than a single sixty-page bundle they have to split.

An open photographic album page from 1939 holding thirty-six small numbered contact prints alongside sleeves of negatives
A contact sheet solved the same problem in 1939: keep a roll of images together, in order, numbered, so nothing is separated from the rest. A PDF is the same idea with a file extension. Photo: Marcia AM Clark (Public domain).

Size is the other factor. Email limits usually sit somewhere around 20 to 25 MB, and a single oversized attachment fails completely, whereas three smaller ones all arrive. If a document is close to a limit, splitting it is more reliable than compressing it harder and hoping.

Getting the order right the first time

Page order is decided by the order the files are handed to the converter, and that is decided by your operating system's sort, which is where things go wrong.

Most file systems sort text, not numbers. That means img2.jpg sorts after img10.jpg, because it compares the characters one at a time and "1" comes before "2". A set of pages named 1 through 20 will come out in the order 1, 10, 11, 12 … 19, 2, 20, 3, 4.

The fix is to pad the numbers with leading zeros (img01.jpg through img20.jpg) so text sorting and numeric sorting agree. Rename before converting and the problem disappears permanently.

It is also worth checking the first page and the last page after conversion rather than only the first. Off-by-one ordering problems tend to hide in the middle.

When PDF is the right container, and when it is not

PDF earns its place when the set matters more than the individual files. Sending fifteen photos of storm damage to an insurer as one document is far better than fifteen attachments that can arrive out of order or go missing. The same is true of a signed form photographed page by page, a portfolio, or anything destined for print.

It is also the right answer when the recipient's software matters. Every operating system, every phone and every browser opens a PDF. Not everything opens a HEIC file from an iPhone, which is a common reason a perfectly good photo appears broken on someone else's machine.

PDF is the wrong answer when someone needs to work with the images themselves. A designer, a printer or a marketplace listing wants the original files, not pictures buried in a document. Extracting them again is possible (that is what converting a PDF back to images is for, and we have a guide on how to do it) but you may not get back exactly what went in.

It is also the wrong answer for anything that needs to be searched or edited as text. A photographed page inside a PDF is a picture of words, not words. Nobody can search it, copy from it or reflow it on a phone screen unless it has been through optical character recognition. If the content is text, extracting the text serves people better than wrapping the picture in a document.

A workflow that avoids all of this

Putting it together, the sequence that reliably produces a sensible document:

  • Rename the files with zero-padded numbers so they sort correctly.
  • Rotate anything that is not upright, so the correction is baked in rather than relying on metadata.
  • Resize and compress to suit the destination, screen, print or email.
  • Choose page behaviour deliberately: standard paper size for printing, image-matched pages for screen.
  • Convert to PDF, then open it and check the first page, a middle page and the last.

Five steps, and the fourth is the one almost everyone skips. It is also the one that decides whether the finished document looks considered or looks like a folder of photos in a wrapper.