DocRaptor vs. WeasyPrint: Which Handles CSS Better?

Short answer: there is no well-supported universal winner for CSS support. DocRaptor is a hosted HTML-to-PDF API that uses Prince, a renderer built around print and paged-media output. WeasyPrint is a free, open-source Python renderer you can run yourself. Both publish feature documentation, and both require checking the exact CSS and PDF features your templates depend on.

For complex paged documents, DocRaptor’s materials present Prince as especially capable; that is a vendor comparison, not an independent matched-version test. WeasyPrint’s documentation describes its support and specific limitations. The reliable way to choose is to render representative documents in each system and compare the PDFs your project actually needs.

This guide compares their CSS and PDF workflows, gives runnable starting examples, and provides a repeatable evaluation checklist. If your goal is a screenshot of a webpage rather than a paginated PDF, see the ScreenshotNeo alternative near the end.

1. What “handles CSS better” means

CSS support is not a single score. A renderer may support a property but behave differently when it interacts with pagination, fonts, intrinsic sizing, or another layout feature. A browser preview is not proof that a PDF renderer will produce the same output.

Make a feature list from your real templates. Include selectors, layout rules, print styles, fonts, external assets, page breaks, generated content, and any JavaScript-created content. Then check the current documentation for the exact versions you plan to deploy.

Question	Why it matters
Does the renderer support the CSS properties and selectors in the template?	Support can be partial, version-specific, or limited in particular combinations.
Does it paginate the document correctly?	Page size, margins, breaks, headers, footers, and long tables affect the final PDF.
Does the document need JavaScript?	Client-side rendering and DOM changes are a separate concern from CSS support.
Can the renderer access fonts, stylesheets, and images?	Resource fetching, paths, network access, and deployment configuration can change output.
Do the PDFs need forms, links, tags, or specific reader behavior?	Output features and how PDF readers handle them can be as important as visual layout.

2. CSS and print features compared

DocRaptor and Prince

DocRaptor is a hosted conversion API and says it uses Prince. Prince’s documentation organizes CSS support by properties, selectors, media queries, functions, at-rules, and specifications. A standards label alone does not guarantee that every feature or interaction in your template works as expected. See the Prince CSS support reference and the Prince user guide.

DocRaptor documents embedded, inline, and external stylesheets, as well as print page styling. Its @page guide covers page dimensions and margins and discusses page-specific layout behavior. Consult the DocRaptor CSS stylesheet guide and page styling guide for the current details.

WeasyPrint

WeasyPrint is a Python-based open-source document renderer. Its stable API reference, surfaced as version 70.0 in the research for this article, describes CSS 2.1 as “pretty well supported” while listing exceptions. These include table visibility: collapse, certain minimum and maximum dimensions, differences in font matching, right-to-left or bidirectional text, and system colors or fonts. Check the WeasyPrint stable API reference for the version you use; the list can change between releases.

The same reference characterizes flexbox as working for simple use cases and not deeply tested. Grid is described as usable for simple cases, with unsupported or untested cases including subgrids, some auto-fill/auto-fit behavior, and some fragmentation behavior. These are caveats to validate against your layouts, not evidence that every flexbox or grid layout fails.

Practical reading of the comparison

DocRaptor’s comparison page presents Prince as particularly capable for complex paged media. Treat that as DocRaptor’s vendor-authored comparison, not an independent benchmark. WeasyPrint also supports print CSS, but its published limitations deserve a property-by-property review. There is no basis here to claim that either system always produces more accurate PDFs or supports all CSS better.

3. JavaScript is a separate decision

If a chart, framework, or script inserts content into the page, test that workflow separately from CSS. DocRaptor documents JavaScript execution modes and rendering configuration in its API documentation. Its comparison says WeasyPrint does not execute JavaScript.

For a JavaScript-dependent document, determine whether the content exists in the HTML sent to the renderer or is created later in a browser. Configure the DocRaptor rendering behavior and timing for the actual page, or change the generation workflow so the final content is present before passing it to WeasyPrint. Confirm the chart or DOM output appears in the PDF; a successful API response alone does not establish that the expected content rendered.

4. Run a representative comparison

Pin the versions and configuration. Record the WeasyPrint release, DocRaptor settings, input HTML, stylesheets, fonts, and resource locations. Re-run comparisons when versions or templates change.
Choose representative documents. Include a long report, tables and page breaks, the most important grid or flex layouts, custom fonts and external images, and any forms or generated content you require.
Render both outputs. Use the examples below as starting points, adapting credentials, input, and options to your environment.
Inspect the PDFs. Compare pagination, line wrapping, page breaks, fonts, images, links, forms, and any accessibility or output requirements. Open them in the PDF readers and deployment environment that matter to your project.
Decide from required features. Record which requirements pass, fail, or need a workaround. Do not turn a small sample into a blanket claim about all CSS.

5. Runnable starting examples

These minimal examples render an HTML file to PDF. They are starting points rather than a complete security or production deployment configuration. Consult each product’s current documentation for authentication, options, resource access, and deployment-specific requirements.

WeasyPrint with Python

from weasyprint import HTML

HTML(filename="report.html").write_pdf("report.pdf")

Install WeasyPrint using the instructions for your operating system and the version you intend to deploy. The WeasyPrint first steps guide covers installation and deployment. For an HTML string, use HTML(string=html).write_pdf("report.pdf"). Set a base_url when relative asset paths in the string need a known base location; review the API reference for supported arguments and behavior.

DocRaptor with cURL

curl https://docraptor.com/docs -X POST \
  -u YOUR_API_KEY: \
  -H 'Content-Type: application/json' \
  -d '{"doc": {"document_content": "<html><body><h1>Report</h1></body></html>", "name": "report.pdf", "document_type": "pdf"}}' \
  -o report.pdf

Use the exact request fields and authentication guidance in the current DocRaptor API reference. For a real template, supply its HTML and configure any needed CSS, resource access, JavaScript behavior, or page styling using documented API options. Keep API credentials out of source control and client-side code.

What to configure and verify

Stylesheets: confirm inline, embedded, and external CSS is available to the renderer; check relative URLs and access to remote resources.
Page rules: explicitly evaluate @page size and margins, page breaks, and page-specific layout.
Fonts and images: verify they load in the actual runtime. Missing resources may change line wrapping and pagination.
JavaScript: establish whether the renderer executes it and whether the final DOM is ready before PDF generation.
Output requirements: check forms, links, annotations, tagging, and target reader behavior if they matter to your application.
Input trust: if users supply HTML or URLs, review the renderer’s security and deployment guidance before allowing resource access. WeasyPrint documents deployment precautions and security considerations in its common use cases and deployment guidance.

6. Operational, reliability, and cost considerations

The key operational difference is hosted service versus software you run. DocRaptor handles the conversion through a hosted API; WeasyPrint gives your team control over where and how rendering runs. Evaluate privacy and hosting constraints, deployment dependencies, resource fetching, scaling, support needs, and who owns upgrades and incident handling.

WeasyPrint is free and open source, but that does not make the full workflow cost-free: account for engineering time, runtime resources, deployment, maintenance, and support. DocRaptor is commercial; verify its current pricing, limits, and terms directly before procurement. The research used for this article does not establish current prices or a matched-version performance benchmark, so no speed, fidelity, or total-cost winner can be stated.

For reliability, keep a small set of representative documents as regression inputs. Compare generated PDFs after renderer, CSS, font, or template changes. Log the renderer version and relevant configuration so a changed page break can be investigated. For a hosted API, handle request failures and timeouts according to its current API guidance; for a self-hosted renderer, monitor the process and resource consumption in your deployment.

7. Common problems and fixes

Symptom	Likely cause	What to check
Layout differs from the browser preview	The PDF renderer and browser do not have identical rendering behavior, or a feature has limited support.	Check the exact CSS feature in the renderer’s current documentation and reduce the case to a representative template.
Grid or flex content overflows or paginates unexpectedly	The particular layout or its interaction with fragmentation is unsupported, untested, or behaves differently in print.	Test a simpler layout and inspect the documented WeasyPrint limitations or Prince support for the feature.
Fonts, images, or styles are missing	Relative paths, resource access, or runtime environment differ from the browser.	Check URLs, base paths, network and file access, and font availability where rendering runs.
A chart or dynamically inserted section is absent	Required JavaScript did not execute or content was not ready when rendering began.	Check DocRaptor’s JavaScript options and timing, or provide pre-rendered HTML when using WeasyPrint.
Page count or wrapping changes between releases	Renderer version, fonts, assets, or CSS changed.	Pin and record versions and resources; compare against saved representative PDFs.
PDF form behavior differs by reader	Form support or reader behavior varies.	Test required field types and interactions in the PDF readers your users use; see WeasyPrint’s use-case documentation.
Untrusted HTML creates deployment concerns	HTML rendering may involve access to local or remote resources and other security-sensitive behavior.	Review WeasyPrint’s deployment guidance and restrict inputs and resource access for your threat model.

8. ScreenshotNeo alternative for webpage captures

DocRaptor and WeasyPrint target paginated PDF documents. If your task is to capture a webpage as an image or PDF rather than compare document-rendering engines, try ScreenshotNeo, a website screenshot API and MCP server. Its API returns a screenshot or PDF from one GET request; the ScreenshotNeo API documentation describes the request options.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

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)

Node.js

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 removes known cookie and consent banners, newsletter popups, and chat widgets before capture, and each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed; response headers report the page verdict and billing status. It also provides an MCP server for AI agents, with tools for taking screenshots, getting page information, and capturing PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Choose it for webpage capture workflows, not as a claim that it replaces a specialized HTML-to-PDF document renderer.

9. FAQ

Does WeasyPrint support CSS Grid?

Its stable reference describes simple grid use cases while listing limitations and untested cases. Check the current reference for your deployed version and test the specific grid patterns in your PDF.

Does WeasyPrint execute JavaScript?

The research-backed comparison says it does not. If scripts create required content, render that content before passing HTML to WeasyPrint or evaluate a workflow with documented JavaScript execution.

Does DocRaptor support print CSS?

DocRaptor documents CSS stylesheets and @page styling. Verify the page rules and output behavior your template needs in its current documentation.

Which one should I choose?

Choose based on your required CSS and PDF features, hosting model, JavaScript needs, and operational constraints. Render a representative suite in both before committing when the decision is consequential.