Images to PDF

Convert JPG, PNG or WebP images to PDF in seconds. Reorder pages, adjust quality. Free and instant.

✓ Free✓ No sign-up✓ Works in browser

Drop images here or click to browse

JPG, PNG, WebP supported — multiple files OK

Adobe Acrobat

The world standard for PDFs

Partner

Edit, sign, compress, merge, protect PDFs. 500M+ users. 7-day free trial.

Start Free Trial

How to Use This Tool

Upload Your Images

Upload JPG, PNG, or WebP images. Upload multiple images at once to combine them into a single PDF.

Reorder Images

Drag and drop images into the order you want them to appear in the PDF. Each image becomes one page.

Create and Download PDF

Click Create PDF. Download your multi-page PDF containing all uploaded images.

Related Tools

Frequently Asked Questions

How many images can I combine into one PDF?

There is no hard limit on the number of images. Each image becomes one page in the PDF.

What image formats are supported?

JPEG, PNG, and WebP are supported. For other formats, use our Image Converter to convert to JPG first.

Will the image quality be preserved in the PDF?

Yes. Images are embedded at their original resolution. The output PDF image quality matches the input.

Can I create a PDF from phone photos?

Yes. This is a common use case — photographing paper documents with your phone and converting them to a PDF for digital filing.

About Images to PDF

You photographed six pages of a handwritten contract with your phone camera and the other party's procurement system only accepts a PDF — not a zip of JPGs. Or a claims adjuster asks for all supporting photos as a single combined PDF so they can page through the evidence in one document rather than opening 40 attachments from a Dropbox folder. This converter loads your JPG, PNG, or WEBP files via FileReader, decodes them through the browser's native image decoder, and embeds each as a page in a new PDDocument via pdf-lib's embedJpg and embedPng helpers. You can drag to reorder, choose page size (A4, US Letter, or fit-to-image), set DPI (300 for print, 150 for screen, 72 for web), and add a margin in millimeters. Runs entirely in the browser, which matters when the images are photos of sensitive documents (signed contracts, ID cards, medical forms) that you would not want to upload to an unknown SaaS. The output is a standard PDF/A-compatible file that any reader, email client, or document portal will accept.

When to use this tool

Submitting phone photos as a claims package

A homeowner photographs water damage in eight rooms after a pipe burst, totaling 14 iPhone shots. Combine into one PDF with a 10mm margin, submit to the insurance adjuster's portal which only accepts PDF attachments, confirm total size under the 25MB cap.

Converting scanned receipts from an app export

An Expensify user exports 40 receipt photos from the app, needs a single PDF for the quarterly expense report. Convert with 150 DPI to balance legibility against file size, sorted by transaction date, attach to the Concur report as one 8MB file.

Creating a portfolio PDF from image renders

A 3D artist has 12 high-resolution renders (6000x4000 each) for a client proposal. Convert at 300 DPI for print-quality review, fit-to-image page sizing, total output around 45MB — client can print at full quality for their design review meeting.

Combining ID documents for a KYC submission

A compliance officer at a fintech onboards a new business customer who photographed passport, utility bill, and business license on their phone. Combine the three images into one PDF for the Plaid or Stripe Identity verification queue which expects a single document per verification step.

Assembling a visual bug report for a QA handoff

A product manager screenshots 20 bug reproduction steps from a staging environment. Convert to a single PDF with A4 pages at 150 DPI (screenshots are inherently 72-96 DPI so upscaling gains nothing), paste into the JIRA ticket so engineers can scroll the whole flow without downloading 20 separate PNGs.

How it works

1
Each image is decoded natively by the browser
FileReader loads each selected file as an ArrayBuffer, we pass it to the browser's built-in Image decoder (via createImageBitmap for performance, falling back to an HTMLImageElement for older browsers). The decoded pixel data is used to determine native dimensions, which informs the PDF page size calculation when fit-to-image mode is selected.
2
Images embed directly without re-encoding
pdf-lib has embedJpg and embedPng helpers that accept the raw image bytes and place them as PDF XObject image resources without re-encoding. For JPG inputs this means zero quality loss — the bytes land in the PDF exactly as they came out of the camera or scanner. PNG inputs preserve transparency via the /SMask soft-mask mechanism. WEBP inputs are re-encoded to JPG because pdf-lib does not support WEBP natively and the PDF spec has no WEBP primitive.
3
Page layout honors DPI and margin settings
When you pick 300 DPI with A4 page size, the image is scaled to fit within the A4 content area minus your margin. The math: A4 is 210x297mm = 8.27x11.69in = 2480x3507px at 300 DPI. If your image is 3000x4000px it scales down proportionally to fit; if it is 1000x1500px it scales up but does not add pixels — the rendering is resolution-independent because the image is embedded as a bitmap and the viewer rescales at display time.

Honest limitations

· HEIC format (iPhone default since iOS 11) is not decoded by most browsers; convert HEIC to JPG on the phone first via the Photos app 'export as' option or using a service like CloudConvert.
· Very large image sets (100+ photos at full resolution) can exhaust browser memory because every image has to sit in heap during PDF assembly; batch in groups of 50 or pre-downsample first.
· EXIF rotation metadata is not automatically applied on all browsers — a photo taken in portrait by an iPhone may appear rotated in the output PDF because the rotation was stored as EXIF rather than in pixels; apply rotate-pdf after conversion if needed.

Pro tips

Pick DPI based on intended viewing, not source resolution

A 24-megapixel iPhone photo is ~6000x4500 pixels. Embedded at full resolution in an A4 page at 300 DPI (2480x3507 target), the image is downsampled to fit — but the PDF still carries the original 24MP bytes unless you pre-downsample. For screen-only documents (claims photos, bug reports, portfolio previews), resize source images to ~2000 pixels on the long edge before converting to PDF — it cuts the output file size 80 to 95 percent with zero visible quality loss on screens. For print-destined PDFs (photo books, design proofs), keep source resolution high and use 300 DPI page output.

Order photos before dragging into the converter

File dialogs sort alphabetically, which often breaks the chronological order you actually want (IMG_4921.jpg vs IMG_4922.jpg works, but photos named differently by different sources interleave randomly). Pre-rename your source files with a zero-padded numeric prefix (01_kitchen.jpg, 02_bathroom.jpg, 03_basement.jpg) before loading them, or use the built-in drag-reorder interface after loading. Insurance adjusters and legal opponents will hold a badly-ordered evidence PDF against you — chronological narrative matters for credibility.

Use JPG inputs for photos, PNG for screenshots

JPG uses lossy compression optimized for photographic content (gradients, natural textures) at very small file sizes. PNG uses lossless compression optimized for sharp edges and flat colors (screenshots, diagrams, text images). A 4MB screenshot saved as PNG is often 400KB as JPG but with visible artifacts around text. A 4MB photo saved as PNG is often 12MB with no quality benefit. Match the format to the content — screenshots should come in as PNG, camera photos as JPG — and the resulting PDF has the right size/quality trade per page type.

Frequently asked questions

What image formats does the converter accept?

JPG and PNG are natively supported and embed directly without re-encoding. WEBP is accepted but gets re-encoded to JPG internally because the PDF spec has no WEBP primitive. HEIC (iPhone's default since iOS 11) is not supported because browsers cannot decode HEIC without a polyfill; convert HEIC to JPG first using the iOS Photos app's 'export as JPG' option. GIF inputs take the first frame only since PDF has no animation. BMP and TIFF are not supported — convert to JPG or PNG first with any standard image tool.

What DPI should I choose for my PDF?

Depends on how the PDF will be viewed. Screen-only viewing (email, chat, web portals) works fine at 72 DPI, which keeps file sizes smallest and is indistinguishable from higher DPI on monitors at standard zoom. Printed documents need 150 DPI for draft quality and 300 DPI for production print (magazines, marketing collateral). For mixed use (PDF will be emailed but recipient might print), 150 DPI is the safe middle — prints look reasonable, file size stays under most email caps. Remember that DPI affects the virtual page size calculation, not the raw image quality which is determined by source resolution.

Will the order I drop files in be preserved?

Yes — the initial page order matches drop order (or alphabetical order if selected via file dialog). After the initial load, drag the thumbnails to reorder before hitting convert. Common gotcha: file dialogs sort alphabetically which can put IMG_4999 before IMG_5000 correctly but mix up photos from different sources (a phone photo named 2024-11-05.jpg and a scanner output named Scan0001.pdf would sort in unintuitive order). Pre-rename source files with a zero-padded numeric prefix to guarantee the order you want before loading.

Are my photos uploaded to process the conversion?

No. The conversion runs entirely in your browser tab. Each image file is loaded into a JavaScript ArrayBuffer via FileReader, decoded locally by the browser's built-in image decoder, and embedded into a PDF via pdf-lib.js which also runs locally. The output PDF is delivered as a Blob download. No fetch request carries image data, no server sees your files. This matters when the photos contain sensitive content (medical images, ID documents, signed contracts, minors' faces) that you cannot share with SaaS tools without creating a privacy or compliance problem.

Can I add OCR to make the text in my photos searchable?

Not in this tool. OCR (optical character recognition) requires running a text-recognition engine over each image to produce a text layer overlay. The main open-source engine, Tesseract, is large (~30MB WASM build for decent language support) and CPU-intensive — 5 to 15 seconds per page on a modern laptop. Adding OCR would inflate page-load time and is better handled as a separate post-conversion step. For scanned documents that need to be searchable, use a dedicated OCR tool (Adobe Acrobat, ABBYY FineReader, or the open-source ocrmypdf CLI) after generating the PDF here.

Image-to-PDF is often the first step in a longer pipeline. After creating the PDF from phone photos, pdf-compressor trims the output for email attachment caps when the source images were oversized. rotate-pdf fixes orientation on pages where EXIF metadata was not honored. For multi-batch conversions (a week of receipts that gets combined monthly), pdf-merger stitches weekly PDFs into a month-end archive. And when the final document needs to be sent to a client or portal with a password requirement, protect-pdf adds the user password as the last step before delivery.