Same four-page PDF, same 216 DPI, same WebP. Exported as four separate pages that's 494 KB total; exported as one stitched long image it's 647 KB. The long image is 1788×10116, which is exactly four times 1788×2529 — not one pixel more. Same pixels, 31% more bytes. I stared at those two numbers for a while without getting anywhere, and only worked it out after listing the four per-page sizes: 121, 124, 128, 122. They aren't equal, and that's the whole answer.
I'm not a CS grad, I came into this from writing, so my method is to click every option in the panel and write down what comes out. The sample is a four-page A4 PDF at 490 KB. "All pages" gives four files at 1788×2529 each, 494 KB total, delivered as a ZIP with the page numbers zero-padded into the filenames. "One long image" gives a single 1788×10116 file at 647 KB, saved directly. "A single page" — I picked page 2 — gives 1788×2529 at 124 KB. That last number is the one I'd flag: 124 KB is byte-for-byte what page 2 weighed inside the full export. So single-page export isn't a separate code path, it's the same render with one page of it handed back. If you need to re-pull one page later you don't have to redo the whole document, and what comes back matches the original batch. I've been burned by the opposite before — re-exported one figure from a different tool, got a slightly different colour profile, and had to redo the whole set to make them match.
As for why one big image costs more: WebP allocates bitrate adaptively within an image, so when the four pages are separate each one gets its own parameters — the page with the most graphics costs the most, hence 128 versus 121. Stitch them and there's a single set of parameters covering a photo region and a wall of text simultaneously, and neither gets what it would have gotten alone. I was about to write "so a long image is always bigger," then stopped, because if every page of a document looks basically the same the per-page parameters would barely differ and the gap should shrink to nothing. I didn't build that sample, so I'm withdrawing the general claim — this holds for mixed documents where pages differ visibly.
I have less of a handle on the other measurement. On a much taller sample, identical output dimensions of 1456×16380, the all-pages path gave 1.10 MB and the long-image path gave 1.40 MB, 27% apart. Same size, same content, different path — but that document is a single page, so there's no "per-page adaptation" to lose, and my explanation above doesn't cover it. The long-image path is just more conservative somehow, and I can't see where from outside.
Practically I pick by what happens to the files afterwards. Feeding a CMS or wiki page by page, all pages, because the page numbers are already in the filenames and slicing a long image by hand is a waste of an afternoon. Dropping it in a chat or a forum post where someone will scroll straight through, long image, because 31% more bytes to save everyone a download-and-open step is a fine trade. Grabbing one figure, single page. On the zero-padding: I once used a tool that emitted image1.png through image10.png and string sort put 10 between 1 and 2, and I spent well over an hour at 2am debugging the wrong layer before I found it. I check for padding before I check anything else now.
One case that overrides all of the above is a genuinely enormous page. On my 800×9000pt sample, 216 DPI and 300 DPI produced the exact same file, 1456×16380 both times. It hit a size ceiling and the setting stopped doing anything, so check the actual output pixels before you trust the dropdown.
Unrelated, but it threw me for a minute so it's going in: hitting save doesn't drop the file into your downloads folder, it opens a picker and asks where to put it and what to call it. My first thought was that it had hung, and I reloaded and redid the whole export before working out that it's deliberate — you're meant to look at the result panel first and then decide where it goes. If you're used to click-and-it-downloads you'll pause the same way I did, but the extra step is reasonable, especially for a ZIP I'd otherwise have to dig out of downloads.
Panel I used: https://imging.ai/pdf-to-image/ . Your PDF will give different numbers than mine, and measuring your own takes about as long as reading this did.
