How to combine images into a PDF that stays readable

Twenty photos of a rental contract. You convert them into one PDF, attach it, and the form rejects it — the combined file is larger than most of the individual photos.

That surprises people because they expect "converting to PDF" to mean "compressing". It does not. A PDF is a container. When you put twenty JPEGs inside it, the container mostly holds those same JPEGs, at close to their original size. Sometimes it is bigger, because the container adds structure and may re-encode a file it could have passed through.

Understanding that one fact changes how you approach the whole job.

A PDF is a container, not a compressor

Think of a PDF as a binder. The pages inside keep the weight they had. Put twenty 400 KB photos in and you get a PDF in the neighbourhood of 8 MB, plus a little overhead for the binder itself.

This matters for how you plan. If the destination allows 5 MB and your photos total 9 MB, the conversion is not going to save you. You need to reduce the images first, before or independently of building the PDF.

There is one nuance worth knowing, and it cuts against the intuition. The pipeline embeds each image without re-encoding it, so a JPEG goes in as the JPEG you supplied and keeps its size; a PNG goes in as a PNG. Nothing gets optimized on the way in. What can grow is the container itself — object streams and cross-reference tables add bytes, and PNG data in particular does not benefit from the stream compression the file format applies elsewhere.

So the outcome varies by input, and you should measure rather than assume. Run a conversion, look at the reported output size, and decide from there.

Prepare the images before you convert

Conversion is the last step, not the first. Five minutes of sorting saves a rejected submission.

Delete the duplicates. Phone cameras and screenshot tools produce copies constantly. Scan your folder once and remove them. Two identical pages in a contract submission looks careless.

Fix the orientation. A photo taken sideways stays sideways in the PDF. Rotate it in the tool or in your phone's editor before conversion. If a page still comes out rotated, PDF rotation can correct it afterward.

Crop only what is genuinely empty. Cropping the table edge off a form can remove a checkbox the recipient needs. Crop borders, nothing else.

Group related pages. Front and back of an ID card belong together. So do the pages of one document, in reading order. Once the PDF exists, fixing the order means rebuilding it.

A note on the order your file picker gives you

Here is a small thing that causes real confusion. When you select multiple files in a file dialog, the order the tool receives them depends on the dialog, the operating system, and how you clicked. It is not reliably alphabetical and it is definitely not whatever order looks right in the grid view.

Do not fight it. Rename copies with 01_, 02_, 03_ prefixes before you select them, then confirm the order in the workspace and again in the finished PDF. If the order is wrong, rebuild from the renamed copies rather than trusting a second selection attempt to behave differently.

Choose the page setup deliberately

The page settings determine whether the output looks like a scanned document or like a photo album with enormous margins.

Setting	What it controls	Practical effect
Original size	Each page takes the dimensions of its image	No added margins; page sizes can differ within one PDF
A4	Fixed 210 × 297 mm page	Consistent, printer-friendly; may add margins or scale the image
Letter	Fixed 8.5 × 11 in page	Same idea, for US-style paper
Orientation	Portrait or landscape	Decides which way a fixed page faces
Margins	Space around the image	Larger margins shrink the image to fit
Output DPI	Resolution at which the image is placed	Affects effective print resolution, not the pixel count

Each choice trades something away.

Original size keeps every pixel where it was and adds no borders. The catch is that a PDF with a phone photo, an A4 scan and a screenshot now has three different page sizes, and plenty of portals check for consistent page dimensions. Use it when the recipient does not care, or when you are assembling evidence where cropping would be unacceptable.

A4 or Letter gives every page the same footprint, which is what most official forms expect. The image is scaled to fit inside the margins. A tall photo on a portrait page fills it nicely; a wide photo on a portrait page gets either a thick band of white space above and below, or it gets scaled down until it is small.

Fit versus fill is the decision underneath that. Fit keeps the whole image visible and leaves margins — text stays complete but may be small. Fill covers the whole page and crops whatever overhangs — no margins, but you lose edges. For a document, choose fit. Losing the corner of a stamped page is worse than a little white space.

Margins and DPI are quieter settings but they matter. Wide margins plus fit scaling means a smaller image on the page, which means smaller text. Output DPI controls how the image is positioned on the page in physical terms. If a portal specifies "300 DPI", that is about the placement, and it does not increase the sharpness of a photo that was already low-resolution. For the relationship between pixel dimensions and DPI, see pixels versus DPI.

Why a 20-photo PDF can be huge anyway

Do the arithmetic. A modern phone takes 12-megapixel photos at roughly 3–5 MB each as JPEG. Twenty of them is 60–100 MB before any container overhead.

Very little of that is "extra". It is the actual image data you captured. Camera sensors record enormous amounts of detail, and unless the phone compresses aggressively, the file carries all of it. Meanwhile the form wants 200,000 bytes for the whole submission. That is not a mismatch you fix at the container level.

The numbers also explain why a screenshot behaves differently from a photo. A screenshot of a text document has large areas of identical white and a limited palette, so it compresses hard. A photo of the same document has sensor noise, uneven lighting, and gradients in every "white" area, so it compresses poorly. If you are photographing documents, more light and a steadier hand produce a file that compresses better later — the noise is what costs you bytes.

Compress the images first, or the PDF after?

Both work, and the right choice depends on where you are.

Compress the images first when you still have the originals and the total size is far over the limit. Twenty photos at 4 MB each need to come down before they go into a container; squeezing the assembled PDF afterward means the engine has to fight twenty embedded images at once. Bringing each photo to a sensible size first gives you a much better final result and more control over quality.

Compress the PDF after when the PDF already exists — it was emailed to you, it came from a scanner app, you cannot rebuild it from source images. In that case PDF compression optimizes the embedded images inside the document, with bounded candidates and a report on what it achieved.

If the PDF is still over the limit after compression and the destination does not need every page, page selection can drop pages you were not asked for. That is a content decision, not a technical one — make sure the pages are genuinely not required.

What changing the format does to size

Output format matters more than most people expect. A JPEG re-encode at moderate quality is usually far smaller than a PNG of the same photo, because PNG is lossless and stores every pixel value exactly. If a portal accepts JPEG and your images are PNG photos, converting first is often the single biggest saving available.

The reverse is also true: do not convert a small, efficient JPEG into a huge PNG by accident. Check the output bytes before you upload.

Verify the result before uploading

Open the PDF. Not the summary — the file.

Look at the first page and the last page, because ordering errors show up at the ends. Check any page whose shape differs from the rest. Zoom in on the smallest text on the densest page and confirm it is readable at normal viewing size, not just at 400% on a large monitor.

Then compare three numbers against the form: page count, total bytes, and accepted document type. If any of them misses, you know exactly which step to revisit.

Two limits to keep in mind. AttachReady rejects encrypted and password-protected PDFs, and PDFs containing active content such as embedded scripts or attachments, so a conversion that starts from a locked file cannot be repaired here — you need a clean export from the source application. And a PDF built from screenshots does not become searchable or editable text; there is no OCR in this pipeline and no PDF editing. What you get is a container of images that prints and uploads reliably, which is what a submission form actually wants.

Guest conversions upload the selected images to the processing service and return the PDF to your current browser page, so download it before you navigate away. Account uploads and artifacts expire after 24 hours. File privacy and retention covers the data paths in detail.