A counterintuitive one: take a PDF, convert it to a webpage (HTML), then convert that webpage back to PDF — and the final PDF is often bigger than the original source. The reflex is "the conversion bloated it", but unpacking it, this is a structural fact of fixed-layout conversion, not a mistake.
First, 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; and 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".
That's where it comes from. 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. 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.
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.
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)