The complaint we hear most about image-to-PDF converters is not about the PDF part. It is about the upload failing before the conversion even starts, usually because the photos came straight off an iPhone.
iPhones save photos as HEIC by default, not JPEG. It is a genuinely better format, smaller files at the same quality, but a lot of converters were built assuming JPEG and PNG and simply do not recognise the file. You get "unsupported format" on a photo that opens fine in your phone's own gallery.
## What actually happens to each format
Our [Image to PDF tool](/images-to-pdf) runs entirely in your browser, so it is worth explaining what that pipeline does with each kind of file, because the handling is genuinely different.
**HEIC and HEIF** get decoded with the heic2any library before anything else happens. This step alone is why most free tools fail on iPhone photos: HEIC is a fairly new container format and decoding it in JavaScript, in the browser, without a server, is not trivial. Once decoded it becomes a normal JPEG internally and goes through the same path as everything else.
**RAW camera files** (CR2 from Canon, NEF from Nikon, ARW from Sony, DNG, and half a dozen others) are the least standardised format we handle. Each manufacturer's RAW is really its own file format wearing a similar name. These get converted to high-quality JPEG before being placed on the page. If your camera shoots RAW+JPEG together, you technically don't need this step, but a lot of photographers only keep the RAW.
**Vector formats like SVG** get rasterised at a size matched to your chosen page dimensions, not a fixed resolution, so a logo placed at Fill mode on an A4 page comes out sharp rather than pixelated.
**Everything else** (JPEG, PNG, WebP, TIFF, GIF, BMP, AVIF, PSD) goes through the Canvas API directly, which is the browser's own image-drawing engine. This is the part that never touches a server: the canvas draws the image, jsPDF reads the pixels off the canvas and writes them into the PDF, and none of that leaves your machine.
## The three fit modes, and when each one is wrong
The options are Fit, Fill and Original, and picking the wrong one is the second most common complaint.
**Fit** scales the image down to stay entirely inside the page margins, keeping its proportions. Nothing gets cropped. Use this for anything where the edges of the photo matter, ID photos, documents you photographed, screenshots.
**Fill** scales the image up until it covers the whole page, which means anything outside the page's aspect ratio gets cropped off the edges. Good for a photo book where you want no white border and don't mind losing a sliver off the sides.
**Original** places the image at its actual pixel size, which on a high-resolution photo usually means it is bigger than the page and gets clipped, or on a small screenshot it looks tiny in the corner. This one is for when you already know your image dimensions match your page and just don't want any scaling touching it.
## Reordering before you convert
Once your images are uploaded, the tool shows a grid you can drag to reorder before generating the PDF. This matters more than it sounds: fixing page order after the fact usually means starting over, so getting it right before you click convert saves the second attempt.
## Why none of this touches a server
Everything above, the HEIC decode, the RAW conversion, the canvas drawing, runs in your browser tab. Nothing is uploaded anywhere, which means there is no file size limit imposed by an upload timeout and no wait for a round trip. It also means your photos, which might be scanned IDs or private documents, never leave your device.
If you need to do this from a script rather than a browser, the [Images to PDF endpoint](/docs#from-images) does the same job over HTTP, though the format list there is narrower: JPEG and PNG, since a server has no reason to carry the HEIC and RAW decoding weight for every request.