Convert Photos to PDF — Merge Images into One PDF Online

Scans of receipts, passport pages, photos of documents, shots of a lecture whiteboard — you often need to gather several pictures into one neat PDF: easier to store, print and send. The "Photos to PDF" tool in pdfredX combines images into a single file right in the browser: you add the shots, set the order and download a multi-page PDF. Nothing is uploaded to a server.

Step 01. Upload the photos

Open pdfredx.com and drag the photos into the drop area — or pick them through your file browser. JPG, PNG and WebP are supported (and HEIC, if your browser can open it — more on that in a separate article). Each shot is read locally and appears as a card in the gallery. Not a single byte goes to a remote machine.

Step 02. Set the order

The page order of the future PDF is the order of the cards. Drag them with a mouse or a finger to arrange the photos as you need; remove extras with the 🗑 button. That's how a set of shots becomes both a "photo album" and a multi-page document from scans — in the right sequence.

Step 03. Download the PDF

Press "Create PDF". The app walks the gallery and combines all the photos into one file: for each page the orientation (portrait or landscape) is chosen automatically from the shot's proportions, on an A4 sheet, and the image is fit with proportions preserved and centered. The finished PDF from your photos downloads straight from the browser. Free, no registration, no server queue.

How it works under the hood

Each photo is read through FileReader into a dataURL and pushed into the shared items[] array — the same one used for PDF pages. The order in the array = the order of the cards in the gallery; Drag & Drop simply reorders the elements.

On output jsPDF walks items[]: for each page it calls addImage and picks the A4 orientation by proportions. A PNG is inserted as a PNG (with transparency on a white background), other formats as JPEG. The file is built entirely in the tab's memory and handed over for download.

Known limitations

File size depends on the sources. Photos are embedded at their original resolution — 12 MP phone shots will produce a hefty PDF. If the result is too heavy for email, run it through the Compress PDF tool.

Page format is auto-A4. The app picks the orientation by proportions and fits the photo into an A4 sheet without margins. Manual control of arbitrary margins and formats is not yet available.

The result is raster. A PDF from photos is images; there is no selectable text in it (except where you separately recognize an area via OCR).

Need to combine ready-made PDF files rather than pictures? That is the Merge PDF tool.

Try it right now — pdfredx.com, no registration, your files stay with you.

Gathering pictures into one PDF is a one-minute task, but an ordinary online converter asks you to upload all your photos to its server. And those are often shots of documents: passport, driver's license, receipts, medical certificates. For a simple merge into a PDF, a batch of personal photos travels to someone else's machine. Let's look at how to do "photos to PDF" locally — and separately about the HEIC format from iPhones, which adds confusion.

Where the photos go on server-side converters

When you upload shots to a typical online converter, each file travels in full to a remote machine. From there it follows the service's policy, which few people ever read:

• files are stored in a contractor's temporary storage (AWS, GCP, Azure);
• they are processed on someone else's server;
• they are kept from a few hours to several days "for reliability";
• they are logged together with metadata — IP, time, file names and sizes.

With merging photos the risk is higher than with a single file: you send a whole batch of shots at once. If those are photos of documents, the entire set ends up on someone else's machine in one go.

Local assembly: the shots never leave the tab

pdfredX combines pictures into a PDF without uploading them anywhere.

Files are read locally. Each photo opens in the tab through FileReader. There is no network request carrying your shots.

Assembly happens in the tab's memory. Order, rearrangements, the final jsPDF composition — operations on data that is already loaded. Nothing is sent anywhere.

The finished file is built on the client and lands in "Downloads," rather than flying to a server and back.

It works offline. Load the photos, turn off the internet and build the PDF — everything keeps working.

Separately about HEIC (iPhone photos)

iPhones shoot in the HEIC/HEIF format by default — it's compact but finicky on the web. Honestly, how it works here:

• pdfredX accepts .heic/.heif files alongside JPG/PNG.
• But the HEIC decoding itself is left to the browser. Safari (Mac, iPhone) opens HEIC natively — there everything assembles right away. Chrome and Firefox on many systems don't decode HEIC — the shot may not display.
• We don't bundle a separate HEIC converter into the app (that's extra heavy code). So the most reliable path on non-Apple devices: in the iPhone camera settings choose "Most Compatible" (shoot in JPEG), or convert HEIC → JPG in advance, and then build the PDF.

This is more honest than promising a "universal HEIC converter": on Apple everything works out of the box, on other systems it depends on browser support.

What we cannot guarantee — an honest disclaimer

Client-side processing protects files from being sent to external servers, but it is not a shield against every threat.

Malware or a keylogger on the device. If the machine is compromised, a program can read files off the disk bypassing the browser entirely.

Browser extensions with broad permissions. An extension with "read data on all sites" access can, in theory, see the tab's contents. For sensitive shots, work in a profile without third-party extensions or in a private window.

The saved file stays on your disk. If the device is not protected by encryption, files can be read by third parties with physical access.

We provide isolation at the level of the browser tab. The rest is on the user's side.

Combine photos into a PDF without uploading them to a server — pdfredx.com, free, no registration.

Combining several pictures into a PDF on a server is easy: accept the files, fit each into a page, return the document. In the browser, with no backend and no uploading of shots, the set of constraints is different — and along the way HEIC, orientation and file size come up. Let's break down how the photos tool in pdfredX is built: why images are stored as-is, how a single array holds the order, and where the boundaries of the approach run.

The architecture: a single items[] array for photos and pages

The key decision is that photos and PDF pages live in one items[] array. A loaded picture becomes the same kind of element as a rendered page and then goes through the shared pipeline (gallery, Drag & Drop, jsPDF export). That simplifies everything: mixing scan-PDFs and photos in one document works with no separate code.

items.push({
  id, name,
  origUrl: url, editUrl: url,   // the shot's dataURL — the original is not mutated
  fromPdf: false, w, h,          // dimensions for choosing the orientation
});

The implementation, piece by piece

Reading the file: no re-encoding

The picture is read as simply as possible — with the native FileReader into a dataURL, without an intermediate canvas:

const readFile = f => new Promise((ok, fail) => {
  const r = new FileReader();
  r.onload  = e => ok(e.target.result);   // the raw dataURL, as-is
  r.readAsDataURL(f);
});

An important consequence: the shot is kept at its original resolution and quality — the app does not recompress it on import. The plus is no quality loss; the minus is a large size for photos from modern cameras (more on that below).

HEIC: decoding is left to the browser

The filter accepts .heic/.heif, but there is no converter in the code: readAsDataURL hands over the data, and new Image() draws it. HEIC is decoded by the browser itself — Safari can, Chrome/Firefox often can't. This is a deliberate trade-off: bundling a HEIC decoder (a couple of megabytes of WASM) into the client for a rare case is expensive, and on Apple devices everything works anyway.

Assembly: jsPDF over the array

The final file is assembled by makePDF(): an A4 sheet, orientation by each shot's proportions, the image fit with proportions preserved (contain) and centered.

const orient = w > h ? 'landscape' : 'portrait'; // orientation by the photo's proportions
// ...contain + centering in A4...
const fmt = url.startsWith('data:image/png') ? 'PNG' : 'JPEG';
pdf.addImage(url, fmt, x, y, dw, dh, '', 'FAST');

imgDims is called for each photo separately — portrait and landscape shots in one batch get the right orientation. A PNG is inserted as a PNG (keeping transparency on a white background), everything else as JPEG.

Trade-offs and the limits of the approach

File size. Since the shots aren't recompressed on import, a PDF from phone photos can weigh tens of megabytes. A deliberate separation of concerns: assembly doesn't touch quality, and there's a separate compression tool to reduce size (canvas → JPEG with quality + downscale).

Page format is auto-A4. The orientation is chosen automatically, margins aren't configurable (contain without margins). Arbitrary formats/margins are on the roadmap.

Memory on large batches. Hundreds of photos at original resolution mean hundreds of decoded bitmaps in the tab's memory; on weak devices there can be stutters.

What's next

Optional compression on import — a "shrink photos to N px" toggle right in the "photos → PDF" flow, so you don't have to run the result through a separate tool.

Built-in HEIC conversion — lazily loading a WASM decoder only when the user brings a .heic, so as not to bloat the main bundle.

Want to test it — load a batch of photos on pdfredx.com, set the order and build the PDF. No registration, no file upload to a server.