Why Does My HTML to PDF Look Wrong? Causes and Fixes
HTML-to-PDF conversion looks wrong in five predictable ways: missing styles, broken images, incorrect page breaks, wrong page size, or missing fonts. Each cause has a straightforward fix. WikiPlus HTML to PDF at wikiplus.co is a browser-based tool that converts HTML to PDF locally — nothing is uploaded to a server. Most rendering issues stem from external resource dependencies that can be resolved by making your HTML self-contained.
Cause 1: External CSS Not Loading
The most common cause of wrong-looking HTML-to-PDF output is external CSS files not loading. When you upload an HTML file that references external stylesheets (link rel=stylesheet href='styles.css'), the conversion tool cannot access those files from your local disk. The browser's security model prevents sandboxed contexts from reading arbitrary local files. Result: unstyled text, wrong fonts, collapsed layouts. Fix: inline all CSS. Open your .css file, copy its entire content, and paste it inside a style tag in the HTML head section. For CSS frameworks like Bootstrap or Tailwind, copy only the classes you actually use (not the entire 200 KB framework file) to keep the HTML manageable.
Cause 2: Broken Images and Missing Backgrounds
Images referenced by relative file paths (img src='logo.png') cannot be loaded from local disk in the conversion context. Result: broken image icons or empty spaces. Background images set via CSS background-image: url('bg.jpg') have the same problem. Fix: convert all images to base64 data URIs. The data URI format embeds the image binary directly in the HTML as a base64-encoded string: img src='data:image/png;base64,iVBOR...' The same applies to CSS background-image: url('data:image/jpeg;base64,...'). For small logos and icons (under 50 KB), this is the recommended approach. For large photographic images over 200 KB, consider compressing them first using WikiPlus Image Compressor to reduce the resulting HTML file size.
Cause 3: Wrong Page Breaks Splitting Content Awkwardly
HTML content breaks across PDF pages according to the browser's automatic pagination algorithm. This often splits tables mid-row, breaks paragraphs at visually awkward points, or leaves headings at the bottom of a page with the body on the next. Fix: add CSS page break rules. page-break-before: always on section headings forces a new page before each major section. page-break-inside: avoid on div, table, and figure elements prevents those elements from being split across pages. For invoice line-item tables, add page-break-inside: avoid to the tbody or to individual tr elements. For multi-section reports, add page-break-after: always to each section to force clean page boundaries.
Cause 4: Wrong Page Size and Unexpected Margins
Without an explicit @page CSS rule, the conversion uses the browser's default page size (typically US Letter at 8.5x11 inches) and default margins (around 12mm). If your design targets A4, the content will be incorrectly sized. Fix: add @page { size: A4; margin: 15mm; } to your CSS (or @page { size: letter; margin: 20mm; } for US Letter). Common page sizes: A4 is 210mm x 297mm, US Letter is 215.9mm x 279.4mm, A5 is 148mm x 210mm. Also add html, body { margin: 0; padding: 0; width: 100%; } to reset browser default margins. These two rules together ensure your PDF pages are exactly the dimensions you intend.
Frequently Asked Questions
- My HTML uses Google Fonts — why do they not appear in the PDF?
- Google Fonts are loaded from external URLs (fonts.googleapis.com) which may be blocked in the conversion context due to CORS policies. Fix: download the font files from Google Fonts directly, convert them to base64, and embed them using @font-face declarations with base64-encoded src values in your CSS. Alternatively, use a font stack that falls back to system fonts: font-family: 'Roboto', Arial, sans-serif — the PDF will render with Arial as a fallback, which is clean and professional.
- Why is my HTML layout correct in the browser but completely different in the PDF?
- The print rendering context applies print-specific CSS rules and respects @page dimensions, which may differ from your screen viewport. If your layout uses viewport units (vw, vh), fixed widths assuming a 1200px screen, or JavaScript-driven layout, these will render differently in print context. Fix: add a @media print block that overrides viewport-dependent styles with print-appropriate alternatives. Use mm or pt units for print layouts rather than px or viewport units.
- The PDF is generated but the file size is unexpectedly large — why?
- Large PDF output typically indicates uncompressed embedded images. If you inlined high-resolution images as base64 PNGs or uncompressed TIFFs, the PDF will be large. Fix: compress images before embedding — use WikiPlus Image Compressor to reduce image file size by 40 to 80%, then re-encode as base64. JPEG encoding at 85% quality is a good trade-off between visual quality and file size for photographic images. For logos and diagrams, PNG with color reduction applied is more efficient. After optimizing images, run the resulting PDF through WikiPlus PDF Optimizer for additional size reduction.