HTML to PDF Conversion: Why Are CSS Shadows Missing?
CSS shadows can disappear in HTML-to-PDF conversion because renderer support, print styles, and blur rendering vary. Here’s how to find the cause and fix it.
CSS shadows can be missing from an HTML-to-PDF conversion because the PDF renderer may not support box-shadow, print styles may remove or override it, or the renderer may approximate blur differently from a browser. Identify the renderer and its exact version first; then check its CSS support and the element’s computed styles in print mode.
“HTML to PDF” describes a workflow, not a single rendering engine. A valid shadow in a browser does not guarantee the same result in every PDF converter or PDF reader.
1. Identify the renderer and version
Find which library, browser, or hosted service generated the PDF, and record its version and configuration. Check the documentation for that specific release for box-shadow support and any blur limitations.
WeasyPrint shows why the version matters: its version 58 documentation lists box-shadow as unsupported, while its current documentation lists it as supported. Current support still has a caveat: blur is approximated using gradients, which can look poor in some PDF readers or in extreme cases. Check the [WeasyPrint 58 documentation](https://doc.courtbouillon.org/weasyprint/v58.0/api_reference.html#css-backgrounds-and-borders-module-level-3) and [current WeasyPrint documentation](https://doc.courtbouillon.org/weasyprint/stable/api_reference.html#css-backgrounds-and-borders-module-level-3) for the release you use.
If the converter does not implement the property in your installed version, changing the shadow color or blur radius may not help. Upgrade to a version that supports it, choose a renderer whose documented support meets your needs, or use a simpler visual treatment for the PDF.
2. Check print-specific CSS
A browser screen view and a PDF may use different styles. Rules inside @media print can remove a shadow, override it, or change the element’s background or layout.
- Open the page in Chrome DevTools and enable print media emulation.
- Select the element and inspect its computed
box-shadowvalue while print media is active. - Search stylesheets for
@media print,box-shadow: none, and more specific rules that override the intended declaration. - Check that the stylesheet containing the shadow is loaded in the PDF workflow.
Chrome documents how print media affects page appearance and how to emulate it in DevTools in its [print CSS guide](https://developer.chrome.com/docs/devtools/rendering/emulate-css/). If the computed print value is none or the declaration is missing, fix the print stylesheet or the stylesheet loading path. If the computed value is correct, investigate renderer support and PDF rendering next.
3. Tell a missing shadow from a different-looking blur
A shadow that is entirely absent points to a different problem from one that appears faint, clipped, too wide, or otherwise unlike the browser preview. Some renderers approximate blur, and PDF viewers can display that approximation differently.
Use a simple, moderate shadow as a diagnostic example:
.card {
background: #fff;
border-radius: 8px;
box-shadow: 0 2px 8px rgba(0, 0, 0, 0.18);
}
Generate the PDF with the same converter and settings that produced the problem. If the simple example renders but the original does not, compare the original shadow’s blur, spread, color, rounded corners, and surrounding clipping or overflow. If it looks different only in one viewer, open the same PDF in another reader to distinguish viewer appearance from conversion output. These are diagnostic steps; results depend on your renderer, document, and PDF reader.
4. Check the PDF workflow and capture readiness
For Chrome Headless, --print-to-pdf generates a PDF, --timeout limits how long Chrome waits before capture, and --no-pdf-header-footer omits the generated print header and footer. The header and footer option is not documented as a control for CSS shadow support. See the [Chrome Headless reference](https://developer.chrome.com/docs/chromium/headless).
chrome --headless --print-to-pdf=output.pdf --timeout=5000 https://example.com
Use a timeout suited to your page and workflow; the example value is not a universal readiness guarantee. If styles or content load dynamically, check whether they are ready before capture. Also inspect the browser version and any print-specific behavior: paged-media support varies among user agents. Chrome and Firefox support @page, and Chrome 131 added generated content in page margins, as described in [Chrome’s paged media article](https://developer.chrome.com/blog/print-margins).
5. A practical troubleshooting sequence
- Record the environment. Note the PDF library or browser, exact version, launch options, and whether a hosted service is involved.
- Verify documented support. Search the documentation for that version for
box-shadowand blur caveats. - Inspect print styles. Emulate print media and check the element’s computed shadow and relevant overrides.
- Classify the symptom. Decide whether the shadow is absent, too faint, clipped, or simply different in a particular PDF viewer.
- Reduce the case. Make a page with one element and a moderate shadow, then generate it through the same pipeline.
- Change one variable at a time. If needed, compare a supported renderer version, a simpler shadow, or another PDF reader so you can locate where the difference arises.
This sequence is a recommended diagnostic method, not a report of a test performed on your page or converter.
Common errors and fixes
| Symptom | Likely cause | What to do |
|---|---|---|
| Shadow is completely absent | The renderer version does not support box-shadow, or print CSS removes it. |
Check version-specific support and computed print styles before changing the declaration. |
| Shadow appears in the browser but not the PDF | The PDF workflow uses a different renderer or print media rules. | Identify the PDF renderer and inspect the page with print media emulated. |
| Shadow is present but faint or unlike the preview | Blur approximation or PDF reader rendering differs. | Try a moderate blur and compare the same PDF in another reader. |
| Only some pages or components lack shadows | Those elements may have different styles, clipping, or stylesheet timing. | Compare computed styles and layout for a failing element against one that renders correctly. |
| Dynamic page styling is missing from the PDF | The capture may happen before required styles or content are ready. | Inspect readiness and capture timing in the chosen workflow; do not assume a longer timeout fixes CSS support. |
| PDF header or footer appears unexpectedly | Browser-generated print headers and footers are enabled. | For Chrome Headless, consult the documentation for --no-pdf-header-footer; this does not enable CSS shadows. |
Performance, reliability, and cost considerations
PDF conversion work depends on the selected renderer and its configuration. Dynamic pages may need time for styles and content to load, while larger pages and complex effects can add rendering work. Set capture waits based on the page’s readiness requirements and use a minimal reproduction to avoid repeatedly converting a large document while diagnosing one shadow.
For a self-hosted workflow, account for the compute and maintenance involved in running the renderer and keeping its version aligned with the CSS features you rely on. A hosted conversion service shifts that operational work according to its own offering and pricing; check the provider’s documentation for the exact renderer, options, and charges. No universal speed, reliability, or cost figure applies across HTML-to-PDF tools.
Or skip the browser setup
For a clean screenshot of a web page, [ScreenshotNeo](https://screenshotneo.com) provides a website screenshot API and MCP server. One GET request returns an image or PDF, and its [API documentation](https://screenshotneo.com/docs/) covers the request options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
ScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing status. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Create a free account for 1,000 screenshots a month, with no card required.
FAQ
Does every HTML-to-PDF converter support CSS shadows?
No. Support depends on the renderer and its version. Check the documentation for the release actually generating your PDF.
Can a PDF reader make a supported shadow look missing?
It can display a blur differently. Compare the same PDF in another reader to separate viewer appearance from conversion behavior.
Should I replace the converter if the shadow is missing?
First confirm support for your version and inspect print-mode styles. If the renderer lacks the feature and the PDF needs it, consider a supported version or a renderer that documents the behavior you need.


