How image-to-PDF conversion actually works
Turning a set of images into a PDF looks like zipping files together, but a PDF is closer to a printing instruction than to an archive. Understanding the few steps involved explains most of the quality and file-size surprises people run into.
A PDF is a page description, not an image container
Every PDF is a list of pages, and each page carries a content stream: a small program that says "place this image here, at this size, rotated this way". The images themselves are stored as separate objects that the page refers to. That indirection is why the same picture can appear on twenty pages without being stored twenty times, and why a PDF page can hold text, vector lines and photographs side by side.
When a converter builds a PDF from pictures, it creates one page per image, defines the page box, and writes a content stream that draws the image to fill that box. Nothing is re-drawn or re-flowed later: the geometry is fixed at build time, which is what makes PDFs look identical everywhere.
Step one: decode and normalise
The converter first decodes each file into raw pixels. This is where most of the work happens, and it is the only genuinely CPU-heavy part of the process. A modern format such as WebP or AVIF decodes more slowly than an old JPEG of the same size, because the compression is cleverer.
Next comes colour. Screens use RGB, and PDF pages are usually written in RGB or CMYK. Images with transparency or a palette (PNG, GIF) have to be flattened onto a background, because a printed page has no notion of "see-through". If you have ever converted a transparent logo and got a black box, that is a flattening step that assumed the wrong background colour.
Step two: page geometry and DPI
PDF measures pages in points, where 72 points make an inch. An image has pixels and, sometimes, a stored resolution. The converter has to choose a mapping between the two, and that single choice decides whether your pages come out A4, letter-sized or something odd.
Two common strategies:
- Fixed page size: every page becomes A4 or letter, and the image is scaled to fit. Pages are consistent, but mixed-size originals gain white margins.
- Image-defined size: the page is exactly as large as the image at an assumed resolution, often 72 or 96 DPI. Nothing is cropped or padded, but page sizes vary and printing needs scaling.
Neither is wrong. For reading on a screen, image-defined sizing usually looks better. For printing or binding, fixed sizes are safer. Page orientation follows from the same decision: a wider-than-tall image on a portrait page will either be shrunk or rotated, depending on the tool.
Step three: compression, and the one mistake to avoid
A PDF can carry image data in several encodings. JPEG data can usually be passed through untouched, which is both fast and lossless in the sense that nothing is re-compressed. PNG-style lossless data can be carried with Flate compression. WebP and AVIF have no native PDF equivalent, so they must be decoded and re-encoded, normally as JPEG.
That re-encoding is where quality quietly disappears. Every lossy generation adds artefacts: soft edges, blocky gradients, halos around text. One conversion is usually invisible; converting a photo that was already saved three times is not. If your source images are JPEG, prefer a tool that embeds them as-is rather than one that decodes and re-compresses everything at a fixed quality.
Why file size is what it is
A PDF built from images is roughly the sum of its image data plus a small overhead per page. Text-heavy scans compress well; photographs do not. A rough rule: a page scanned at 150 DPI in greyscale lands around 100–200 KB, the same page at 300 DPI in colour can be over a megabyte. Fifty such pages make a file you would not want to email.
If the result is too big, the honest fixes are fewer pixels (downscale), fewer colours (greyscale for text pages), or a slightly lower JPEG quality. "Compress PDF" buttons do exactly this behind the scenes, so doing it deliberately gives you better control.
What you do not get
The finished file contains pictures of words, not words. There is no selectable text, no search, and a screen reader has nothing to read. If you need those things, run optical character recognition afterwards; that adds an invisible text layer on top of each page image, leaving the visible page untouched. The article on image-based versus text-based PDFs goes into what that gains and costs.
None of this is exotic, but the order matters: decode, normalise colour, decide geometry, then compress. Most disappointing conversions come from a tool making one of those choices silently, in a way that suited a different document from yours.