I round-tripped an 800x600 photo through PDF and got back 600x450
I made a deliberately boring test image: a blue rectangle, a yellow circle, some white text, exactly 800 by 600 pixels, nothing a compressor could get clever with. I turned it into a PDF, then turned that PDF straight back into a JPG, expecting to get 800x600 back, since nothing about "convert to PDF and immediately convert back" should touch dimensions. I got 600x450. Three quarters of the pixels I started with, in both directions.
I ran it twice to make sure I hadn't picked the wrong setting. Same result both times. Here's exactly where the 25% went.
Step one: image to PDF, page size "same as image"
On JPG to PDF (the full version of the tool, dagotools.com, linked from this hub's own Image to PDF page), there's a page-size choice: A4, Letter, or "Same as image." I picked "Same as image" on purpose, assuming that option name meant what it said. The PDF came out at 8.8KB, one page, and opened looking correct, same proportions, nothing cropped.
▲ The 800x600 test image that went in. Flat colors so there's nothing for a compressor to "cheat" with.
Step two: PDF back to JPG, and the catch in "72 DPI"
Then I dropped that same PDF into PDF to JPG and picked the first resolution option on the list, 72 DPI, figuring "good balance for most uses" (the tool's own label) meant a safe default. I read the output file's JPEG header directly, not the tool's preview thumbnail, with a small byte-parser I wrote for this:
function getJpegSize(buf) {
let offset = 2;
while (offset < buf.length) {
const marker = buf[offset + 1];
if (marker >= 0xC0 && marker <= 0xC3) {
return { height: buf.readUInt16BE(offset + 5), width: buf.readUInt16BE(offset + 7) };
}
offset += 2 + buf.readUInt16BE(offset + 2);
}
}
600 by 450. Not 800 by 600. The "page size same as image" step had already converted my 800x600 pixels into a PDF page measured in points, at 72 points per inch, which happens to be the same number as the DPI I picked going back out. 800px at a 96-pixel-per-inch assumption becomes a page that's roughly 8.33 x 6.25 inches. Re-rasterize that page at 72 DPI (not 96) and you get back 600 x 450. The pixel count never survives a round trip unless the DPI on the way out matches the DPI the page size was built against on the way in, and nothing on either tool's screen tells you what that number was.
Checking it wasn't a fluke
I reran both steps from scratch, fresh test image, fresh PDF, same 72 DPI choice. 600x450 again, byte-identical dimensions both times. I also had a network request listener running through the entire thing, upload to download, on both tools. Zero requests, both conversions, both runs. Image to PDF and PDF to Image here on the hub run the same way, everything in the tab, nothing sent anywhere, which you can check yourself with the Network tab open the whole time.
What this actually means if you're doing this for real
If you're turning a photo into a PDF and back just to resize or re-save it, you're not getting a lossless round trip by default, you're getting whatever DPI math the two tools happen to agree on, which is rarely the number you'd guess. If pixel-for-pixel dimensions actually matter to you (scanned ID photos, printable templates, anything where someone downstream checks exact pixel size), pick a DPI on the way out that matches what you assumed going in, 96 if that's what you started with, and verify the result the boring way: read the file header, not the preview. I'd already written that habit into an earlier post about the same image-to-PDF pipeline losing most of its original byte size; this time it's pixel dimensions instead of file size, same lesson about not trusting the number you expect.
Try the round trip yourself: JPG to PDF and PDF to JPG on dagotools.com, or the hub's own Image to PDF and PDF to Image. The full tool list is at /tools/.