I exported the same web page to PDF three times and got three files that barely look related. One is 2 pages with 6.74pt table text. One is a single page with 9.75pt text. The third looks almost like the second, except you cannot select a single character in it and it weighs 6.4 times as much. I changed nothing about the page. I only changed which route I took.
Three words first, because the numbers are meaningless without them. Pagination is the step where a web page — a strip of cloth you can scroll forever — gets cut into a stack of fixed-size sheets. Points (pt) are the unit on those sheets: A4 is 595×842pt, Letter is 612×792pt. Pixels (px) are the unit on your screen, which is what the page's font sizes are written in. The two do not line up, so something has to convert between them, and that conversion is where the surprises live. Selectable text means text you can drag-highlight, find with Ctrl+F, and copy out of the PDF. Not every PDF has it.
What I measured
The sample is mine and entirely made up: a fictional cross-border warehouse report, 46 rows, invented SKUs, warehouses and amounts. No real company, no real data. The three routes were browser printing, the follow-the-real-page-size export in ImgIng (https://imging.ai/ ), and a screenshot-style export I stitched together myself with a script. I read page count, page size, median body font size and extractable character count out of every file instead of eyeballing them.
Route one: the default sheet is probably not the one you assume
I was sure browser printing defaulted to A4. On this machine it does not — it hands you Letter, 612×792pt. Once the sheet is fixed, a 1180px-wide report has to fit into an 816px-wide text area, so the whole thing gets scaled down: 13px table text lands at 6.74pt, across 2 pages. The text is not small because the screen is small. It is small because the sheet came first and the content had to fit into it.
Route two: no sheet, the page keeps its own size
The second route drops the sheet entirely. Whatever size the page renders at becomes the size of the PDF page. The same report comes out as 1 page, 1080×1536pt, table text at 9.75pt, text selectable and searchable, links still clickable.
One thing I want to nail down before anyone misreads it: 9.75 being larger than 6.74 does not mean one route draws characters better. Rendered at the same dpi, I could not measure any difference in glyph clarity between the two. The difference is whether the content had to be shrunk to fit a sheet. That is a page-size policy, not rendering quality.
Route three: looks identical, costs everything
Screenshot-style export is what a lot of online converters actually do — screenshot the whole page, drop the image into a PDF. My stitched-together version of that gave me 0 selectable characters and 995,232 bytes, against 2,996 characters and 156,370 bytes from route two. The 6.4x size is the boring part. The real cost is on the receiving end: nobody can search it, quote it, or feed it into anything else.
Two things neither route survives
I thought I had a conclusion at that point. Two findings cut it in half.
The first is scroll containers. Admin tables are routinely written with a fixed height and their own inner scrollbar. They drag fine on screen, but on export only the slice that was visible inside the container makes it out. My 46-row report came out with 8 rows on both routes. Thirty-eight rows simply did not exist in the PDF, and neither export warned me. Both routes lose exactly the same rows, so this is nobody's advantage. I have not found a way around it at the tool level — I just pull the table out of its container before exporting and let it grow to full height.
The second is more interesting. I added a print-only stylesheet to the same long table: A4 sheet, repeat the header on every page, avoid splitting a row across a page break. After that, both routes produced identical results — 7 A4 pages, header repeated 7 times, matching item by item. Pagination is mostly decided by the page's own CSS, and the tool just carries it out. Only when the page has no print styling at all does the tool get a choice: cut to a sheet, or follow the real page size.
One more thing worth stating plainly, because people assume anything in a browser tab is purely local. Per ImgIng's own description: importing, reading a folder, mapping resources, live preview, and the lossless minification applied after the PDF comes back all happen locally in the browser, with zero upload during that stretch. Only after you click convert does it send a self-contained HTML snapshot — scripts stripped out, every resource inlined — in a single POST to its own same-origin endpoint, where server-side Chromium / Skia returns the real PDF. That is the one document capability of theirs that goes through a server. I watched the network panel: not one non-GET request before the click, exactly one POST after it. If the page is sensitive, decide on that step before anything else.
So my current rule is short. If the page already has print styles, both routes agree and you can take whichever is closer to hand. If it has none and the table is wide, following the real page size keeps the font readable. And before either, check that the table is not locked inside a scroll container. To verify, search the exported PDF for a word that only appears in one of the last rows. If it is not there, rows are missing.
Top comments (0)