Converting JPG to PDF: A Practical Guide That Answers What Nobody Explains

Convert JPG, PNG, and WebP images to PDF in your browser. Learn how images become PDF pages, when to use one image per page vs. many, and how to avoid the common EXIF rotation trap.

7 min read

Why anyone converts JPG to PDF

The reason people convert images to PDF has surprisingly little to do with the image format itself. It's about what happens next: emailing a receipt, submitting a scanned ID, archiving photos of a whiteboard, sending a signed form as a single attachment instead of six separate JPEGs. PDF is the boring wrapper that makes images feel like a document.

This guide walks through what actually happens when a JPG becomes a PDF, the format-specific traps (EXIF rotation, transparency, HEIC), and when converting to PDF is a bad idea.

What happens under the hood

When you convert a JPG to a PDF, the tool does something specific: it creates a new PDF document, adds a page sized to your image, and embeds the image bytes inside the page. pdf-lib handles JPEGs natively, the JPEG data is copied into the PDF without being decoded and re-encoded, which means zero quality loss and a small size increase (usually 2-5% for the PDF wrapper overhead).

PNGs work differently. PDF has native support for JPEG but not for PNG's specific compression. When you convert a PNG to PDF, the tool decodes the PNG, then either:

  1. Re-encodes as JPEG (default for most tools), which loses PNG's lossless quality and transparency, or
  2. Encodes as PDF's own lossless format (FlateDecode), which preserves quality and transparency but produces larger files.

Our conversion tool preserves PNGs losslessly, so a 500 KB PNG becomes a PDF around 550 KB rather than a JPEG-compressed 100 KB. If file size matters more than perfect PNG fidelity, running the result through a compression tool afterwards gives you the JPEG version.

WebP is a modern format that some tools do not support at all. Ours decodes WebP and re-encodes as either JPEG or PDF-native depending on whether the WebP has transparency.

Common workflows

Single image β†’ single-page PDF

The simplest case. A photo of an ID, a screenshot of a receipt, a scan of a signed page. Drop the image, get a one-page PDF. Everything Just Works, unless the image was taken with a smartphone, in which case see the EXIF section below.

Multiple images β†’ one multi-page PDF

For scanning a multi-page document with a phone: take photos of each page, drop them all in, get one PDF with each image on its own page. The tool preserves image order based on filename, so name your files page-01.jpg, page-02.jpg, etc. if the natural order matters.

For photo archives: drop 50 photos, get a 50-page PDF album. Beware, image PDFs can be large. Fifty 8-megapixel photos becomes a 40-60 MB PDF, which is fine for archival but too big to email.

Multiple images β†’ one-page PDF (rare)

Some tools support placing multiple images on the same PDF page in a grid layout. Ours does not because the design decisions get complicated fast, margins, aspect ratios, orientation mismatches. If you need this, convert to multi-page first and then use a merge tool with a "2-up" or "4-up" layout.

The EXIF rotation trap

This is where most people run into trouble.

Digital cameras and phones store the image right-side-up on disk but encode the actual orientation (which way is up) in EXIF metadata. The image viewer reads the EXIF orientation and rotates the display accordingly. When you look at a phone photo, the viewer shows it correctly, so it looks like the file itself is right-side-up. It is not.

When a PDF tool embeds the JPEG bytes directly (without re-encoding), it does not read EXIF metadata. The image ends up in the PDF at its "raw" orientation, which for portrait phone photos means rotated 90Β° from what you expected.

Symptoms:

  • Portrait photos appear sideways in the output PDF
  • Landscape photos might appear upside down
  • Some photos are correct, others are not (depends on which way the phone was held)

Fixes:

  • Preview your images before converting. If they look correct in a viewer that respects EXIF, they may still be wrong on disk. Open the image in an editor that shows the raw file (macOS Preview does this if you rotate manually).
  • Re-save each image after correcting orientation. Most photo apps have a "correct orientation" export option that writes the pixels in their displayed orientation and clears the EXIF flag.
  • Use a tool that respects EXIF. Our conversion tool reads EXIF orientation and rotates the embedded image accordingly. Not all browser tools do this.

Testing your tool: take a photo in portrait orientation, convert it to PDF, open the PDF. If the image is right-side-up, your tool respects EXIF. If it is sideways, EXIF handling is broken.

PNG transparency and PDF backgrounds

PDF pages have an implicit white background. When you embed a PNG with transparent regions, those regions appear white in the PDF - because there is nothing else to show through them. Usually this is fine. Occasionally it is not.

If your PNG is a signature or a logo intended to overlay onto other content, converting it standalone to a PDF loses the transparency information. The PDF looks the same as if the PNG had a white background. For overlaying, embed the PNG on top of another PDF using a signature or watermark tool, which preserves the alpha channel.

HEIC and other newer formats

iOS defaults to HEIC (High Efficiency Image Container), which about half of PDF tools do not support. Our tool decodes HEIC using the browser's native Image API, which works in Safari but sometimes fails in Chrome or Firefox because they lack HEIC codec support.

Workarounds:

  • On iOS: Settings β†’ Camera β†’ Formats β†’ "Most Compatible" makes the phone use JPEG instead. Every app understands JPEG.
  • On macOS: Preview can batch-convert HEIC to JPEG (File β†’ Export or a drag-drop to an image editor).
  • On Windows: install the HEIF Image Extensions from Microsoft Store, then Photos app can convert.

When you should not convert to PDF

A few scenarios where JPG-to-PDF is the wrong tool:

  • The document is a scan of text that you need to search. Converting to PDF gives you an image-based PDF. Text search will not work. Convert to PDF then run OCR to add a text layer, or find a scanning app with built-in OCR.
  • You are sending a single photo to someone who will view it on a phone. JPEG opens in the phone's photo gallery instantly. PDF requires them to open a PDF viewer. Extra friction for no benefit.
  • The receiving system explicitly wants images, not PDFs. Some photo-processing services reject PDFs.

Frequently asked questions

Does converting JPG to PDF lose quality?

Not for JPEGs, the JPEG data is embedded in the PDF as-is, no re-encoding. The result is byte-for-byte the same image inside a PDF wrapper. PNGs may lose quality if the tool re-encodes them as JPEG; check whether your tool preserves PNGs losslessly.

Can I convert HEIC (iPhone) photos to PDF?

Depends on your browser. Safari can decode HEIC natively. Chrome and Firefox on desktop cannot in most cases. If your tool errors on HEIC input, convert the HEIC to JPEG first using the Photos app or a converter, then convert to PDF.

Why is my portrait phone photo sideways in the output PDF?

EXIF orientation metadata was not read. Your tool embedded the raw image bytes without applying the rotation flag stored in the JPEG header. Rotate the image in a photo editor, save, then re-convert.

What page size should I pick?

If the tool offers page size options: pick "Fit to image" for the best appearance. Fixed page sizes (A4, Letter) require scaling and letterboxing that usually looks awkward. If the recipient is printing the PDF, then a fixed page size matches their paper, but that is a specific case.

Can I combine JPGs, PNGs, and WebPs into one PDF?

Yes, in a single conversion pass. The tool handles each image according to its format (JPEG embedded directly, PNG and WebP re-encoded as needed) and adds each as a separate page. The output is a single mixed-format PDF.

Are my images uploaded during conversion?

No. Browser-based conversion loads the image files into memory, constructs the PDF locally using pdf-lib, and offers the result as a download. Nothing crosses the network except the initial page load.