Testing Print Stylesheets by Comparing Screen Capture to PDF Export

Any page with a real @media print stylesheet — an invoice, a report, a legal document, a resume builder's output — is effectively two different layouts sharing one URL: the screen version, and whatever the print rules produce. It's easy for the two to drift apart over time, especially when the print stylesheet is written once and rarely touched again while the screen layout keeps evolving around it.

Capturing Both States

The screen state is a plain capture:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example.com/invoices/12345",
    "format": "png",
    "width": 1440,
    "fullSize": true,
    "hideCookie": true
  }'

The print-rendered state uses the same request with format set to pdf — the renderer applies the page's own @media print rules the way a browser's print dialog would, the same feature covered in Turning Web Pages and Dashboards into Shareable PDF Snapshots:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example.com/invoices/12345",
    "format": "pdf",
    "width": 1440,
    "fullSize": true,
    "hideCookie": true
  }'

What to Actually Check

The two outputs are different formats (an image versus a document), so a direct pixel v3/compare between them isn't the right tool — that endpoint is built for comparing two states in the same format. The practical check here is a manual or checklist-based review of the PDF output specifically:

• Navigation, buttons, and interactive elements that should be hidden in print (via display: none inside @media print) but sometimes leak through after an unrelated CSS change.
• Page breaks landing in reasonable places, rather than splitting a table row or a key figure across two pages.
• Content that's only meant for print — a signature line, a "printed on" timestamp — actually appearing, since it's easy to write a print-only rule that silently stops matching after a markup change.
• Colors and backgrounds that rely on print-color-adjust or similar rules rendering as intended rather than defaulting to a browser's print-friendly override.

Building This Into a Regression Check

For a page where the print output genuinely matters — an invoicing system, a report generator — capturing the PDF version as part of the same release check that already covers the screen version is a small addition: run both requests, and file the PDF alongside the screenshot in whatever release-review artifact your team already produces. Catching a broken print stylesheet before a customer downloads a mangled invoice PDF is a much better place to find that bug than a support ticket.

Why This Gets Skipped So Often

Print stylesheets are usually written once, tested once in a browser's print preview, and then left alone while the rest of the page keeps changing. Nobody re-checks the print output on every subsequent change, because print preview isn't part of a normal browser-testing habit the way scrolling through the screen layout is. A cheap, occasional PDF capture as part of an existing release check closes that gap without asking anyone to remember to open print preview manually.

For pages where the printed or PDF-exported version is actually used by someone — most invoicing, reporting, and document-generation features — Snapshot Site makes checking that output as easy as checking the screen version, since it's the same request with one parameter changed.