I had a 14-page internal report to export from a webpage into a tidy PDF for archiving and sending. Ran it through HTML-to-PDF; the before/after is clean, but there's a boundary I have to state up front, because it's not what most people assume.
The numbers first. The report was ~4.82 MB, the output PDF ~1.56 MB, generation time ~5.3 seconds down to 2.6. This is one internal sample and results vary by page structure — image-heavy vs text-heavy, simple vs complex layout, all swing the size and timing a lot; don't take this as a universal figure. All it shows is: for this kind of image-and-text report, HTML-to-PDF can trim the size while keeping the layout.
But the thing to be clear about is where it actually runs, because this is the most misunderstood part. People default to "anything in the browser is local"; HTML-to-PDF isn't. The flow: import, table-of-contents reading, resource mapping and full preview happen locally in the browser — you tune and verify the final frame locally; only when you click "convert" is a script-stripped self-contained snapshot submitted to the server, which does the actual PDF generation, with temp files deleted when the request ends. So it is not "zero-upload" — the convert step goes server-side. I single this out because in the same product "PDF compression" and "PDF-to-HTML" are fully local, only "HTML-to-PDF" has a server step; conflating them gets you burned — like running absolutely-must-not-leave-the-network content through it.
Why does the convert step have to go server-side, not be fully local? My read: the hard part isn't the layout, it's pinning down which frame of the page to save — the page may still be loading fonts, images, running scripts, and local preview lets you stabilise that frame; on convert, a script-stripped self-contained snapshot is submitted and generated once by the browser-grade engine, avoiding wildly different exports from everyone's different environment. Local tunes it right, the server generates it consistently.
One more thing to set straight: the output PDF's layout and generation are done by browser-grade layout and PDF-generation (Chromium / Skia), not an in-house layout engine. The tool does the rest — local preview, deciding "which frame" to save, page-size strategy, and lossless post-generation optimisation. Crediting this step as "in-house layout" is inaccurate; the real value is "reliably feeding the correct frame to the generation engine and cleaning up after".
So what it fits and doesn't is clear. Fits: image-and-text reports, web content to archive as tidy PDF, non-confidential — tune the layout locally, get a clean PDF from the server, size trimmed as a bonus. Doesn't fit: absolutely-must-not-leave-the-network content — that server submit on convert is unavoidable, so don't take this path for it, use a fully-local route instead. Good numbers are one thing; knowing where it runs and what to feed it matters more than the compression ratio. Tool is ImgIng (imging.ai).
Top comments (0)