How it renders / options.media
Render a PDF using screen CSS instead of print CSS
Chooses which CSS media type the document is rendered under: print by default, or screen when you want the page to look like the page.
What it is for
A page can have a print stylesheet that hides navigation, drops colour and changes the layout. Rendering under print media honours all of that, which is right for a document. Rendering under screen media ignores it, which is right when you are capturing what a page looks like rather than producing a document from it.
The request
Sent to options.media. Everything else on this page is what happens around it.
{
"url": "https://example.com/dashboard",
"options": {
"media": "screen",
"print_background": true
}
}The actual limits
Read from the implementation rather than remembered, so these are the numbers the API enforces rather than the ones a roadmap intends.
- Two values: print, which is the default, and screen. Anything else falls back to print.
- Under print media, @media print blocks apply and @media screen blocks do not. Under screen media the reverse.
- This is a separate axis from print_background, and the two are frequently confused. Media decides which rules apply; print_background decides whether backgrounds are painted at all.
What failure looks like
Rendering a site under print media and getting a document with the navigation, the cookie banner and the footer stripped out, because the site's own print stylesheet hides them. That is correct behaviour and it is rarely what someone capturing a dashboard wanted.
When this is the wrong tool
When you are producing a business document from your own markup. Print is the right media for that, and a document that only looks right under screen media has a print stylesheet doing something it should not.
Frequently asked
Is print or screen media available on the free plan?
Yes. There is no plan gate on this one: it behaves the same on the free plan as on every paid plan, and the only limit that applies is the monthly document allowance.
Where do these numbers come from?
The running implementation. Every figure on this page, from payload ceilings to per-plan limits, is what the API enforces today rather than what a specification says it should. If one of them is wrong, the API is the thing to believe.
Related capabilities
Options that come up in the same request, and one from each of the other groups.
Print background colours and images in a PDF
Controls whether background colours and images survive into the PDF. On by default here, which is the opposite of a browser's own default.
Add a header, footer and page numbers to a PDF
Small HTML fragments repeated on every page, with substitution tokens for the page number, the total, the date, the title and the URL.
Use a PDF rendering preset
Three named bundles of options for the three shapes most documents fall into, with anything you pass explicitly overriding them.
Render an HTML string to PDF over an API
Send a complete HTML document in the request body and get the PDF bytes back in the response.
Set the PDF page size in an API request
Six named paper sizes, passed in the request options, with A4 as the default when nothing is given.
Render many PDFs in one API call
Up to several hundred documents in one request, each stored and returned as a link, with per-item success or failure rather than one all-or-nothing result.
Password protect a generated PDF
Encrypts the output so a reader is asked for a password before the document opens.
Check API usage and remaining document quota
How many documents have been used this billing period, what the limit is, and what the plans are, all readable from the API rather than from a dashboard.
Everything the API does
The full list, grouped by which part of the request it belongs to.
API reference
The complete parameter documentation, including the parts with nothing interesting to say about them.
100 free documents a month, and a playground that runs a real render without a key.