HTML to PDF CSS not working? Check resources and print styles
Troubleshoot missing HTML styles, images, fonts and awkward page breaks. Includes a self-contained CSS test, a verified synthetic example and a final PDF checklist.
If your HTML looks styled in a browser but plain or incomplete in its PDF, check what the converter can actually load before changing the layout. With AlphaPDF’s uploaded-file workflow, scripts are removed and remote stylesheets, images and fonts are not fetched. Put the required content and CSS inside the HTML file, then check print rules and page breaks.
This checklist is for an uploaded .html or .htm file. For a public website address, use the separate webpage-to-PDF capture guide.
Match the symptom to the first check
| What changed in the PDF? | Check first | What to try |
|---|---|---|
| Almost all styling vanished | CSS loaded through an external link | Put essential rules in a style element inside the uploaded file. |
| Logo or pictures disappeared | Images referenced by URL or a separate local file | Use embedded image data where supported; keep the test small. |
| Text or a chart is missing | Content created by JavaScript | Export the completed static HTML instead of relying on scripts. |
| Words wrap differently | Unavailable font, fixed widths or paper size | Use a fallback font stack and check the selected orientation. |
| A card or table splits awkwardly | Available page height and break rules | Reduce oversized blocks and test print-specific break controls. |
1. Make the uploaded file self-contained
A browser preview on your computer can use files beside the HTML, cached resources and internet downloads. That does not mean an uploaded HTML file contains them. Inspect stylesheet links, image sources and font declarations. A reference such as styles/report.css still points to a separate file.
The live AlphaPDF HTML to PDF tool says it does not fetch remote resources and does not accept a ZIP of a website. Put essential CSS inside a style element and supply static text directly in the document. For images, the tool recommends embedded data URLs. Do not expect a JavaScript chart library or a sign-in session to run inside this workflow.
2. Check print CSS separately from screen CSS
A PDF is a paginated output, so the screen view alone is an incomplete test. MDN’s printing guide explains how @media print selects print styles and how normal CSS precedence still applies. Look for rules that accidentally hide a report section or leave screen-only navigation visible.
Start with a small diagnostic file like this. It is a suggested test, not a promise that every renderer implements every CSS feature:
<!doctype html>
<meta charset="utf-8">
<title>Layout check</title>
<style>
body { font-family: Arial, sans-serif; }
@page { size: A4 portrait; margin: 15mm; }
@media print {
.screen-only { display: none; }
.section { break-inside: avoid; }
}
</style>
<p class="screen-only">Screen-only marker</p>
<section class="section">
<h1>Layout check</h1>
<p>This text should remain visible.</p>
</section>
Compare the normal browser view, its print preview and the downloaded PDF. If only the converter differs, reduce the file to the smallest failing rule. A browser preview helps isolate the problem; it does not establish another renderer’s support.
3. Give the content room on the page
The W3C paged-media draft defines page size, orientation and margins through the page model. In practice, converter support varies. AlphaPDF’s live tool offers paper size and orientation and says in-file print rules are respected where its renderer supports them.
Use the same intended paper settings throughout your comparison. If a wide table clips, first test landscape orientation or narrower columns. A fixed width designed for a large screen may not fit the printable area. Avoid shrinking everything until labels become unreadable.
The W3C fragmentation specification describes controls such as break-before and break-inside. An avoidance rule cannot make a block taller than a page fit intact. Shorten the block, allow a sensible split or start the section on a new page, then inspect the output again.
4. Compare a known input and output
AlphaPDF’s tool page provides a public synthetic invoice as an HTML example input and a PDF example result. We checked that both downloads match the hashes in the site’s generation evidence. The HTML contains its own style block; the PDF has one page and extractable text for all five invoice line items and the total.
That is evidence for this existing example, not a guarantee for your file’s fonts, charts or page breaks. We inspected the public example rather than submitting a new paid conversion.
For your own test, use a small fictional report with one heading, a short table and a closing note. Check that all three appear, that the last column stays inside the page and that the closing note is not lost. Add your real layout features one at a time. If the plain version works but the full version fails, this makes the next change easier to identify.
5. Check the downloaded PDF before sharing
- Confirm every expected section and the final line are present.
- Inspect long labels, symbols and non-Latin text for font substitutions or missing characters.
- Review every page boundary for clipped rows, isolated headings and unwanted blank pages.
- Test important links in the final file; see the PDF hyperlink troubleshooting guide if they fail.
- Save the verified output and retain the source HTML so you can correct the layout later.
Try the uploaded HTML workflow
Open HTML to PDF to review the current inputs, settings and example. It requires an account with paid access; the live page currently says plan purchasing is not available there. Check access before planning a conversion. Use a self-contained file and judge success by the downloaded PDF, including its last page.
Comments
Comments are reviewed before appearing here. Your email is never displayed.
No approved comments yet.
Join the conversation