I save a lot of course material as PDF — lecture pages, docs, reference tables — and read them on a tablet. One of those pages had a big table in it. On screen it looked fine. Printed, the table text was small enough that I had to hold the paper close to read it, and the last columns were squeezed together. I blamed the printer, went to the campus print shop, printed it again on a different machine. Same result.
The printer was never the problem. The "save as PDF" step was.
To measure what actually happens, I built a stand-in page: a 46-row detail table, eight or nine columns, all the data made up, table text at 13px — a very ordinary size for a web page. Two units run through all of this: px is a dot on your screen, pt is a dot on paper, an A4 sheet is about 595pt wide. Not interchangeable. I saved that one page twice. Once with the browser's own print-to-PDF. Once through the HTML-to-PDF tool at ImgIng (https://imging.ai/), whose default option is to follow the page's own size. Then I measured both files: page count, page size, the median text size in the body, and how many characters could be selected.
Where the work happens: importing, reading a folder, mapping resources, live preview, and the lossless minimisation 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 one self-contained HTML snapshot — scripts stripped, every resource inlined — in a single POST to the same-origin ImgIng endpoint, where server-side Chromium / Skia returns the real PDF.
The numbers: browser print gave 2 pages at 612x792pt with table text at 6.74pt. Following the page's real size gave 1 page at 1080x1536pt with text at 9.75pt. I marked every row and checked whether any row got split across pages — zero rows, both ways. So nothing was cut off. The text was shrunk.
The reason is mundane once you see it. A web page is a strip that can be as wide and as long as it wants. Paper cannot. When the strip is wider than the sheet, the browser does not chop off the right-hand side — it scales the whole page down until the width fits, and the text comes down with it. My table was 1180px wide on screen; a sheet gives you around 816px of printable width. That ratio is where the 69% comes from, and where 13px becomes 6.74pt. The wider the table, the worse it gets.
Following the page's real size does the opposite: no scaling, just a sheet cut to the size the page actually rendered at. The text survives at 9.75pt, and in exchange you get one 1080x1536pt page — longer pages get proportionally longer sheets. Great on a tablet, awkward on a printer, which will just scale it down for you anyway. I split it by purpose now: screen reading gets the real-size path, anything I'm actually printing goes through print — but only after fixing the next thing.
I had always assumed print meant A4. It does not. The default paper on my browser was Letter, 612x792pt, shorter and narrower than A4. If your print shop runs A4 and your file is Letter, the printer scales or pads it again, and the text ends up smaller still. Look at the paper dropdown in the print preview before you hit save. Cheapest fix on this list.
Now the one that actually loses content. Some pages put a table inside a fixed-height box you can scroll on its own — admin dashboards do this by default. You can scroll through all 46 rows on the page. When you save to PDF, only the rows visible in that box at the time make it into the file. I put the same table in such a box and saved it both ways: 8 rows each time. The other 38 are simply not in the file, and neither path warns you.
The only thing that works is going around it — expand the box before saving, or find a print-friendly version of the page. Why neither path can recover those rows I still haven't worked out; I only know it isn't one tool being bad at its job.
One last habit, ten seconds well spent. Open the saved PDF and drag your cursor across the body text. If the text highlights, it's real text: searchable, copyable, fine to quote in an appendix. If nothing highlights, that page is a picture with words painted on it. I built a comparison: the same page exported as a full-page screenshot dropped into a PDF had zero selectable characters and weighed 995,232 bytes, 6.4 times the 156,370 of the text version. On screen you can barely tell them apart.
Top comments (0)