I combined three photos into a PDF and the PDF came out smaller than the photos
I made three test PNGs on a blank canvas tab, on purpose different shapes: 1600x1000, 1000x1400, 1200x1200. 171,783 bytes combined. I dropped them into Image to PDF expecting the output file to land somewhere around that same number, maybe a little more for PDF overhead. It came back at 54,602 bytes. Less than a third. I re-ran it twice because I assumed I'd uploaded the wrong files.
I didn't. Here's what actually happened and why the page never asked me to pick a paper size.
No fit-to-page option, and that's the point
Most "combine images to PDF" tools I've used give you an A4-or-Letter choice and squeeze your photo into it, padding or cropping as needed. This one doesn't ask. Each image becomes its own page, and the page takes the image's exact proportions. Drop a landscape photo, a portrait photo and a square photo in the same batch, and you get a PDF with three differently-shaped pages sitting back to back.
[[IMG:1]]
▲ Three images in, "PDF created (3 pages)" out. No paper-size dropdown anywhere on the page, because there isn't one.
My first reaction was that this felt like a missing feature. After opening the result, I changed my mind: nothing got cropped, nothing got letterboxed with white bars, and nothing got stretched to fit a rectangle it didn't belong in. If you're archiving photos rather than printing documents, "the page is just the photo" is arguably the more correct default, not a lesser one.
Where the extra bytes actually went
I didn't expect compression to be part of the story at all; I assumed image-to-PDF tools mostly just wrap the original bytes in a PDF container and call it done. That's not what happened here. The library re-encodes the images while placing them on the PDF pages, and apparently that re-encoding pass is more aggressive than whatever my canvas export did when it wrote the original PNGs. 171.7KB of flat-color test PNGs in, 53.3KB of PDF out, with the three pages still visually matching what I uploaded.
I want to be honest about one caveat here before anyone screenshots this as a universal claim: my test images were solid-color blocks with large text, basically the easiest possible case for a compressor. A phone photo full of noise and gradients will compress less dramatically, maybe not at all. I haven't run that version of the test yet (it's on the list), so treat "always gets smaller" as unverified and "got smaller for flat graphics" as the thing I actually measured.
Checking the zero-upload claim the boring way
Since this is the recurring bit in every post on this blog: I had a request listener running before the first file touched the input, through the convert click, through the download. Total requests carrying my images: zero. The page serves with a Content-Security-Policy: connect-src 'none' header, same mechanism as the rest of the toolset, confirmable with:
curl -sI https://toolsthatdontupload.com/tools/image-to-pdf/ | grep -i content-security-policy
The conversion itself runs on pdf-lib, an MIT-licensed library, loaded once from this site and never phoning anywhere afterward.
One real limitation, not a vague one
If your photos are iPhone HEIC files, this tool will just sit there; it only reads JPG/PNG/WebP. The fix isn't a setting, it's running them through HEIC to JPG first, which the tool's own help text points to directly instead of failing silently. I'd rather a tool tell me what it can't do than pretend.
Try it with your own mismatched photo batch: Image to PDF. If you want to combine existing PDFs instead of photos, that's Merge PDF, a different tool on the same no-upload principle. The full list of what's here is at /tools/.