Convert a PDF to HTML and back to PDF - why is it bigger

What PDF-to-HTML does

To make the webpage both look identical to the original PDF and let you select and copy text, it keeps two sets of things:

• A visible graphics layer - text, paths and images rebuilt as vector outlines (SVG) by PDF coordinates, which is what your eye sees
• A transparent selectable-text layer - sitting on top, invisible, but selectable by mouse and hit by search

What you see is the vector strokes; what you select is that transparent text. The two aligned and stacked give you "looks like an image, yet selectable and searchable".

In the source PDF, a run of text usually has one representation (glyphs rendered by font). Fixed-layout HTML, to serve both "faithful" and "selectable", splits it into two - vector outline + transparent text layer.

Why the round-trip PDF is bigger

When you convert that HTML back to PDF, the converter faces two sets that both must be preserved, so the re-packaged PDF carries both. One set became two; bigger than a single-set source is what the structure dictates, not a conversion error.

To be precise: the layout and generation of the PDF on the way back is done by the browser-grade layout and PDF-generation capability (Chromium / Skia), not some tool's in-house layout engine - the tool decides what information, in what structure, to feed it, plus post-generation optimisation. So the answer to "why bigger" isn't in the generation engine, it's that what was fed in was two sets to begin with.

ImgIng's choice

Could you just drop one layer to win the size back? ImgIng's choice is not to. It states it plainly: fixed-layout HTML keeps both the visible SVG outline and the transparent selectable-text layer, Chromium re-packages both on the way back, and it won't drop a layer, rasterise the vectors, or swap fonts just to match the source's byte count.

The reasoning is concrete - drop the transparent text layer and the PDF can't be selected or searched; flatten vectors to an image and it blurs on zoom and still isn't selectable. Each layer carries one ability you wanted (fidelity + selectability); sacrificing either for a nicer number trades a feature for bytes.

Bottom line

So read the "bigger" correctly: it's the structural cost of keeping both "looks like the original" and "text is selectable and searchable", not waste. If you genuinely only want a viewable fixed layout and don't care about selecting text, don't take the "keep the selectable layer" path in the first place; but as long as you want "faithful and selectable", a round-trip growing in size is inevitable. Understand the two layers, and you stop suspecting the tool - the extra bytes are exactly the "selectable and searchable" you asked for. Tool is ImgIng (imging.ai).

Top comments (0)