HTML to PDF

Conversions fall into three families. A lossless change rewrites the container while keeping every bit of image data — PNG to a PDF wrapper, for instance. A lossy change re-encodes pixels and discards detail the eye is unlikely to notice, which is how JPEG and WebP achieve their size advantage. A structural change reinterprets the document model itself, as when a page description becomes editable paragraphs.

Only the third family can genuinely go wrong, because it involves inference rather than copying. Knowing which family your conversion belongs to sets a realistic expectation for the result before you start.

A PDF stores glyph positions, not paragraphs. Reconstructing a Word document means grouping thousands of positioned characters back into lines, lines into paragraphs, and aligned blocks into tables — an inference from geometry. Straightforward reports reconstruct almost perfectly; multi-column magazine layouts, floating text boxes and hand-drawn table borders are where guesses become visible.

The practical workflow is to convert, then spend two minutes fixing headings and table edges, which is still far quicker than retyping. Where a document must stay pixel-identical, keep the PDF and edit it directly instead.

PDF pages are resolution-independent vector descriptions, so exporting one as an image requires choosing a rendering resolution. 150 DPI suits screen reading, 300 DPI is the usual print standard, and going far beyond that mostly inflates the file. Going the other way, an image placed into a PDF keeps its pixel count; its printed size is simply that count divided by the DPI you assign.

Colour space is the second variable. Screens work in RGB while commercial presses expect CMYK, and the conversion between them cannot represent every colour in either direction. Vivid RGB blues and greens are the ones that most noticeably dull when a file is prepared for print.