Converting HTML to PDF feels like it should be exact. The browser already renders the page beautifully, so why would the PDF differ? The answer is that a PDF page is not a browser window. It has a fixed size, no scrolling, no mouse, and no JavaScript running in the background. HTML to PDF renders a pasted snippet as an A4 PDF in your browser, and most simple styling survives that journey well. The problems start with styling that depends on the browser being interactive, unusually wide, or unusually clever. Knowing the boundary in advance lets you design snippets that convert cleanly the first time, instead of discovering the differences after you have sent the document.
What usually survives
Start with the good news. The everyday styling that makes a document readable survives reliably: heading sizes and weights, paragraph spacing, bold and italic text, text colour, background colour on blocks, borders, table borders, and cell padding. Lists keep their bullets or numbers, and links keep their text, although a link on paper cannot be clicked in the same way. Simple one-column layouts survive best of all, because a single column maps naturally onto an A4 page: content flows down, headings break the flow sensibly, and margins stay even.
Images placed with a sensible width also survive, provided they are not wider than the page. An image set to the full content width will fill the page nicely. An image given a fixed pixel width larger than A4 will overflow or shrink awkwardly, so relative widths are safer. If an image matters, such as a logo on a letterhead, test it in the PDF at full size rather than trusting how it looks in a browser tab.
What often gets lost or changed
Complex layout is the first casualty. Multi-column grids, floating sidebars, and layouts that depend on the viewport being a particular width do not map cleanly onto a fixed page. A three-column design may stack into one column, squeeze into unreadably narrow columns, or push content off the page entirely. Positioned elements that overlap on screen can overlap differently on paper, hiding text that was perfectly readable in the browser.
Interactive styling is the second casualty. Hover colours, dropdown menus, tabs, accordions, and animations have no equivalent on a printed page. A tabbed section will not show all its tabs as separate pages; it will show whatever state the markup describes by default, and the hidden content may simply not appear. If information lives behind a click, it does not belong in a PDF snippet unless you also write it out in full.
Custom web fonts are the third uncertainty. A font loaded from elsewhere may not be available during conversion, in which case a fallback font takes its place. The fallback is usually readable, but spacing and line breaks can shift, which matters in a tightly designed certificate or invoice. For documents where exact spacing matters, a widely available font family is the safer choice.
Why scripts are stripped, and why that helps
Scripts are stripped from snippets before conversion, and that is a safety feature rather than a shortcoming. HTML pasted from elsewhere can contain code that does things you did not intend, from tracking to outright mischief. Stripping scripts means the conversion only renders markup and styling, never executes code. It also keeps the result predictable: the PDF shows the content as written, not a version that changed after a script ran.
The practical consequence is that anything dynamic must be resolved before pasting. A date should be written as a date, not generated by code. A total should be a finished number, not a sum computed on the page. A greeting that changes with the time of day should be written out for the recipient in question. This is a small discipline, and it has a side benefit: a snippet with all values written in plainly is easier to proofread than one whose values only appear when code runs.
Worked example: a fictional certificate that converts cleanly
Consider a fictional example. The Example Gardening Club, an invented group, wants a certificate for a fictional member, Alex Morgan, recognising attendance at a spring workshop. The first draft uses a two-column layout, a decorative web font, and a script that inserts the date. Converted to PDF, the columns stack oddly, the font falls back to a plainer one that shifts the centred heading, and the date is missing entirely because the script was stripped.
The club redesigns with conversion in mind. The layout becomes a single centred column. The font becomes a standard serif family. The date is written in full as "12 April 2026" in the markup, and the heading is centred with simple alignment rather than positioned elements. Converted again, the certificate looks almost identical to the browser preview, and it prints cleanly on A4. Nothing about the redesign made the certificate less attractive; it simply removed the features a fixed page cannot honour. That is the general rule: design for the page you are producing, not the screen you are previewing on.
A design checklist for clean conversion
Before converting, run through these checks. Is the layout a single column? Are all values written out in full, with no script needed? Are fonts standard families rather than exotic downloads? Are images sized relative to the page rather than fixed wider than A4? Are tables kept to few columns with padding? Is there any content hidden behind a tab, hover, or click that a reader would miss? If every answer is satisfactory, the conversion will usually be uneventful, which is exactly what you want from a document tool.
For background on how browsers and servers signal safety for web content, see the guide to HTTP security headers.
Honest limitations
Even with careful design, HTML to PDF conversion has limits. CSS and print support are not unlimited, and some advanced features will not survive no matter how carefully they are written. The output is rasterised, so it should be checked visually as a finished page rather than assumed to carry selectable, reflowable text. Page size is fixed at A4, so long content paginates across pages and may break a table or a heading in an awkward spot; long documents need a manual check of every page break. Scripts are always stripped, so no dynamic behaviour will appear. None of this makes the tool unreliable for its intended job, which is turning a well-designed snippet into a clean A4 page. It does mean the tool rewards simple, page-aware design and punishes designs borrowed unthinkingly from interactive websites.
FAQs
Why does my PDF look different from the browser preview?
Because a PDF page is fixed at A4, non-interactive, and rendered without scripts. Layouts that depend on screen width, hovering, or clicking often change, while simple one-column styling usually matches closely.
Do web fonts work in HTML to PDF conversion?
Not reliably. A font that must be downloaded may fall back to a standard font during conversion, shifting spacing. For exact layouts, use a widely available font family and check the PDF.
Why is my date or total missing from the PDF?
Most likely it was generated by a script, and scripts are stripped before conversion for safety. Write dates, totals, and other values directly into the HTML before pasting.
Can I convert a whole web page this way?
You can paste a large snippet, but the tool is designed for snippets such as receipts, letters, and certificates. A whole page with navigation and sidebars will convert awkwardly; trim it to the content that belongs on the page.
If a snippet includes images that need preparing first, Image Optimizer can resize and compress them, and PDF to JPG reverses the journey when you need a PDF page as an image.
human review pending client designation