HTML to PDF Missing Styles: Why CSS Fails and How to Fix It
Converting an HTML page to PDF only to find it looks like a plain 1990s website — no colors, no layout, everything stacked vertically in default fonts — is a deeply frustrating result when you expected a polished document matching your web design. The CSS that makes your page look professional is simply not being applied in the PDF output. HTML-to-PDF conversion relies on a headless browser or HTML rendering engine to draw the page content into a fixed-size canvas. Each step in this process can fail to apply styles: external stylesheets may not load because they require network access that the conversion tool does not have, JavaScript-generated styles may not execute, and certain CSS properties have no meaningful PDF equivalent and are silently dropped. This guide covers every major cause of missing styles in HTML-to-PDF conversion and provides concrete steps to fix each one — from external stylesheet loading to print media queries to font rendering.
External Stylesheets Not Loading During Conversion
The most common cause of missing styles is that the conversion tool cannot access the external CSS files referenced in your HTML. When you write `<link rel='stylesheet' href='/styles/main.css'>`, the conversion tool needs to fetch that CSS file from your server. If the URL is relative, the tool may not know your base URL. If the URL is absolute, the tool may not have network access to reach your domain. Local file conversion is especially prone to this: if you upload an HTML file to an online tool, the relative paths in your HTML point to files on your local machine that the remote server cannot access. The conversion runs without those CSS files and produces unstyled output. The fix is to inline your CSS directly in the HTML file using `<style>` tags, or to ensure all CSS URLs are publicly accessible absolute URLs that the conversion server can fetch. For local files, use a build step that inlines all styles before conversion. Tools like inline-source, juice, or a bundler with CSS inlining capabilities can automate this.
- 1Open your HTML file and check whether stylesheets are referenced as relative paths, absolute paths, or inline <style> tags.
- 2For relative paths, either convert them to absolute URLs pointing to your live server, or inline the CSS content.
- 3Copy the contents of your CSS file and paste them inside a <style> tag in the <head> section of your HTML.
- 4Re-upload the modified HTML with inlined styles and verify that the PDF now shows correct styling.
JavaScript-Generated Styles Not Applying
Modern web applications frequently generate styles dynamically: CSS-in-JS libraries (styled-components, emotion), CSS custom properties set via JavaScript, styles added by UI frameworks (React, Vue, Angular), and class names added after DOM manipulation all depend on JavaScript execution. HTML-to-PDF conversion tools vary enormously in their JavaScript support. Tools based on headless Chrome (like Puppeteer) execute JavaScript fully, giving the page time to render before capturing it as PDF. Tools based on LibreOffice, WeasyPrint, or custom HTML parsers have limited or no JavaScript execution, meaning dynamic styles never get applied. LazyPDF's HTML to PDF conversion uses LibreOffice, which has limited JavaScript support. For pages that heavily rely on JavaScript for styling, the most reliable approach is to pre-render the page to a static HTML snapshot — either using your framework's static export feature (Next.js, Gatsby static generation) or by using a headless browser to capture the fully-rendered HTML, then converting that static snapshot to PDF.
- 1Identify whether your HTML relies on JavaScript for styling by disabling JavaScript in your browser (Dev Tools → Settings → Disable JavaScript) and reloading the page.
- 2If the page looks similar to your PDF output with JS disabled, JavaScript-generated styles are the culprit.
- 3For server-rendered pages, add the CSS as static stylesheets or inline styles instead of dynamically.
- 4Use a browser's 'Print to PDF' feature to capture fully-rendered pages including JavaScript-applied styles.
Web Fonts Not Loading in PDF Output
Web fonts loaded via @font-face declarations or Google Fonts CDN links require network requests during conversion. If the conversion tool cannot access the font CDN, it substitutes a fallback system font. The layout typically shifts because the fallback font has different character widths, causing text to reflow and break your carefully designed layout. Google Fonts URLs (`https://fonts.googleapis.com/css2?family=...`) must be accessible from the conversion server. Most online conversion tools can reach Google's CDN. However, custom font hosting on your own domain requires your server to be publicly accessible and CORS-configured to allow cross-origin font loading. For maximum reliability, download the font files and embed them as base64 data URIs directly in your CSS. This makes the fonts self-contained within the HTML file and removes any network dependency: `@font-face { font-family: 'MyFont'; src: url('data:font/woff2;base64,AAAA...') format('woff2'); }`. Font file base64 encoding can be done with any online base64 encoder or with Node.js's Buffer class.
- 1Replace Google Fonts link tags with direct @font-face declarations that reference public CDN URLs.
- 2For custom fonts, download the font file, base64 encode it, and embed it as a data URI in your CSS.
- 3Test font loading by viewing your HTML in a different browser or network environment before conversion.
- 4As a fallback, specify robust fallback fonts in your font-family stack that look acceptable if the primary font fails.
CSS Properties Without PDF Equivalents
PDF is a fixed-layout format without the responsive, interactive capabilities of HTML. CSS properties that depend on interactivity, screen rendering, or browser-specific features have no PDF equivalent and are silently dropped during conversion. Properties that commonly fail in HTML-to-PDF conversion include: `position: fixed` (PDF has no viewport to fix to), `overflow: scroll` (no scrolling in PDF), CSS animations and transitions (PDF is static), `display: grid` and flexbox (support varies by conversion engine), `backdrop-filter` (compositing effect not supported), and `:hover` pseudo-classes (no pointer in PDF). For print-targeted HTML, use the `@media print` CSS media query to define print-specific styles that replace incompatible properties. For example, replace `position: fixed` headers with `position: static`, and remove animation declarations. The @media print approach lets you maintain a web stylesheet for browser display while providing a simplified, PDF-compatible version for conversion.
- 1Add an @media print block to your CSS that overrides problematic properties for print/PDF output.
- 2Replace position:fixed elements with position:static or position:relative in the print stylesheet.
- 3Remove all animation, transition, and transform properties from the print stylesheet.
- 4Add page-break controls using page-break-before, page-break-after, and page-break-inside properties to control where PDF page boundaries fall.
Page Size and Margins in HTML-to-PDF
HTML pages are designed for an infinite vertical scroll. When converting to PDF, the conversion tool must break this continuous content into fixed-size pages. The default page size may not match what you need, and the automatic page breaking may split elements (tables, code blocks, images) in inconvenient places. CSS provides the `@page` rule for controlling PDF page dimensions, margins, and orientation. A `@page { size: A4; margin: 25mm; }` declaration tells the conversion engine exactly what page size and margins to use. Without this declaration, the conversion tool uses its own defaults, which may produce different output than you expect. Page break control is equally important. `page-break-inside: avoid` on table elements and code blocks prevents them from being split across pages. `page-break-before: always` on major sections forces each section to start on a new page. These CSS properties are essential for any HTML-to-PDF workflow that produces multi-page documents.
- 1Add @page { size: A4 portrait; margin: 20mm; } (or your target page size) to your print stylesheet.
- 2Apply page-break-inside: avoid to tables, figures, and code blocks to prevent awkward splits.
- 3Apply page-break-before: always to major document sections if each should start on a new page.
- 4Verify page dimensions and margins by checking the output PDF's page properties in Adobe Reader.
Frequently Asked Questions
Why does my page look perfect in browser print preview but broken in the PDF tool?
Browser print preview uses the same engine that renders your page (Chrome, Firefox, Safari) and fully executes all JavaScript and loads all resources. Online conversion tools use a different engine — often LibreOffice or a headless browser instance that may not have access to all your resources, may handle JavaScript differently, or may implement CSS properties with different behavior. The most reliable HTML-to-PDF conversion uses Chrome's headless mode, which is identical to Chrome's print preview. Use your browser's 'Print to PDF' function for the most faithful result.
Why are my images missing from the PDF output?
Images referenced as relative file paths (`<img src='images/logo.png'>`) cannot be loaded by online conversion tools — they point to files on your local computer that the remote server cannot access. Images must be either publicly accessible absolute URLs, or embedded directly in the HTML as base64 data URIs (`<img src='data:image/png;base64,...'>`). For online tools, inline your images as data URIs before upload. For conversion from a live URL, ensure your image server allows cross-origin requests.
How do I convert a live webpage (not a local file) to PDF?
For converting live webpages, the conversion tool fetches the page from its URL rather than you uploading an HTML file. This has the advantage that all resources (CSS, fonts, images) are loaded normally over the internet. LazyPDF's HTML to PDF tool accepts URLs. Simply enter the full URL of the page you want to convert. For pages behind authentication or paywalls, you must provide the HTML directly (with inlined resources) rather than the URL, since the conversion server cannot authenticate as you.