Define which information must survive printing, apply scoped print rules to the actual layout, then check every page in native preview and the saved file at the paper sizes your readers use.
A web page can look excellent on a laptop and still produce a PDF with missing paragraphs, a table cut in half or a nearly empty first page. Screen layout and printed layout have different constraints. A narrow scrollable panel works on screen because the reader can scroll; a sheet of paper does not provide that same interaction.
Start by defining the information the reader needs to keep, then inspect how the actual page behaves in print preview. This guide covers printing an HTML page, including a browser’s Save as PDF option. It does not replace checking the accessibility or download behaviour of a separately produced PDF.
Make a content checklist before changing CSS
Choose one representative page with a long heading, several sections, an image with a caption, a table and an important external link. Write down what must survive: title, main text, column labels, explanatory notes, source details and the meaning of any status colours. Include the page’s publication or review date when it matters to interpreting the copy later.
For a fictional equipment-maintenance guide, a printed checklist must retain the warning that a procedure requires the power to be disconnected. Removing a coloured warning card to save ink would be a content failure even if the remaining layout looked tidy. Decide what is essential before deciding what is decorative.
Keep an unmodified preview as a baseline. Record the browser, paper size, orientation, scale and whether browser-generated headers and footers are enabled. A useful comparison changes one layout variable at a time rather than combining new CSS, a different browser and a different paper size.
Inspect the print cascade
MDN explains print stylesheets and print media queries. Print-specific declarations still participate in the CSS cascade. A rule can exist in your stylesheet and lose to a later or more specific rule.
Use the browser’s rendering tools to emulate print media while inspecting the element that disappears or clips. Confirm which declarations actually win. If the preview is blank, inspect the main content’s ancestors as well: a hidden wrapper can remove an otherwise correctly styled article.
Work in a local copy or staging environment. Add rules to the existing stylesheet mechanism rather than editing generated files that the next build will replace. Keep selectors tied to the page component you own; hiding every header or footer may also remove article headings or useful table content.
Remove the screen constraints causing the failure
Investigate fixed heights, maximum heights, hidden overflow, sticky toolbars and layouts whose widths assume a large screen. A long article inside a fixed-height panel is a different problem from a single oversized image. Reset the affected container rather than flattening every element on the site.
The following is a deliberately small example for an invented article component. Its class names must be adapted to the actual page. It illustrates a starting point, not a stylesheet that has been tested on your theme.
@media print {
.site-navigation,
.article-share-tools {
display: none;
}
.article-layout,
.article-body {
display: block;
width: auto;
max-width: none;
height: auto;
max-height: none;
overflow: visible;
}
.article-body img {
max-width: 100%;
height: auto;
}
}Reopen native preview after the change. A browser’s print-media emulation is useful for identifying rules, but the paginated preview is where you inspect the actual page boundaries. Check the last paragraph and final note; clipping often hides content near the end rather than creating an obvious error at the top.
Use page-break controls selectively
The break-inside reference describes controls such as avoid-page. They can help keep a small figure and caption together. Forced breaks and other fragmentation rules also affect the result.
Do not put an avoid rule on an entire long article or on every table regardless of length. A box taller than the printable page still cannot fit on one sheet. Broad avoidance can also create large gaps before content moves to the next page. Treat a page break as a reading decision, not a defect that must always be eliminated.
For the maintenance guide, keeping a small warning and its two-line explanation together is sensible. Keeping a twenty-row inspection table indivisible is usually a poor starting assumption. Allow long material to flow, then inspect whether the headings and continuation remain understandable.
Plan tables and long strings for paper
Make a separate pass through dense tables. Ask whether each column is necessary for the printed task. A table with twelve narrow columns may need a purposeful print view or an accompanying export rather than smaller and smaller text.
Check long addresses, identifiers and code samples at normal reading size. If a line is lost beyond the page edge, decide whether wrapping preserves its meaning. For a command or an exact identifier, an inserted visual break must not look like a character the reader should type. Give the reader another reliable route to the complete value when paper cannot represent it clearly.
Our guide to readable website data tables covers the screen interaction separately. A mobile scrolling table and a printed table need different checks; passing one does not establish the other.
Set page margins without depending on every advanced feature
The @page rule controls aspects of the page box, including margins and size. Implementation support varies by feature. Check the compatibility of any feature you intend to depend on.
A modest starting example is shown below. The values are an editorial layout choice for testing, not a universal margin requirement.
@page {
margin: 18mm;
}Test A4 and Letter if your audience may use both. Do not assume a layout that fits one necessarily fits the other. Also check what happens when the visitor changes orientation or leaves their browser’s page headers enabled. Avoid relying on one specific printer’s printable area to establish general correctness.
Retain context when removing navigation
A printed article is separated from its surrounding website. A bare “read more” label may therefore be useless. Decide which important link destinations should be printed as text, and make those destinations readable without exposing private or temporary URLs.
Prefer a deliberate short reference list for important sources over automatically printing every link’s full address. A universal link rule can create pages of long query strings, duplicate in-page anchors and disclose a signed download URL. Review the actual links before choosing the presentation.
Preserve meaningful distinctions when colours or background graphics are omitted. A status labelled only by a green box needs a textual meaning in the printed copy. Keep image captions and document provenance, while removing controls that offer no useful action on paper.
Avoid fragile changes triggered only by printing
The beforeprint event can run when printing or preview begins. MDN recommends preferring print CSS where possible. Reserve scripting for a genuine content-state requirement, then test cancellation and restoration as well as the successful path.
Do not treat an event as proof that the reader obtained a printout. For an interactive checklist, decide whether the printed copy should show the current selections, an empty reusable checklist or a separate summary. Label that choice clearly. Opening preview and cancelling it must not erase answers or leave the screen layout altered.
Information hidden in a collapsed section also deserves an explicit decision. Make sure the printed copy includes the promised content rather than assuming every hidden component will expand itself. Do not fetch restricted information merely because a print dialog opened.
Verify the saved file, not just the preview thumbnail
- Inspect every page in native print preview, including the first and last pages.
- Save the PDF and reopen it in a separate viewer. Check text, image captions, table labels and page boundaries.
- Search for a sentence from the final section to help detect missing content; still inspect the surrounding layout visually.
- Repeat with the second paper size and a second supported browser where that reflects your audience.
- Cancel printing and return to the page. Confirm that links, controls and any unsaved interaction still behave as intended.
A usable visual layout does not establish that the resulting PDF is properly tagged or accessible to assistive technology. If an accessible document is a requirement, review the generated file through an appropriate document-accessibility process. If you distribute it as a separate download, also verify the published PDF link and update workflow.
Finish with a short record of the page fixtures, browsers, paper settings and remaining limitations. The aim is a copy that preserves the reader’s task and context, with evidence of what you checked, rather than a print button that merely opens a dialog.
Sources and verification
Editorial review 2026-10-14. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: PrintingChecked Print media stylesheets, cascade rules and practical differences between screen and print presentation.
Limits: General CSS guidance, not evidence that a particular site's print output is correct. - MDN: break-insideChecked Fragmentation controls, avoid-page and interaction with forced breaks.
Limits: Avoiding a break does not make oversized content fit; actual pagination needs browser testing. - MDN: @pageChecked Page-box margins, size and feature-dependent implementation support.
Limits: Support differs by feature and browser; the guide does not promise identical printer output. - MDN: Window beforeprint eventChecked Event timing for printing or preview and preference for print CSS where possible.
Limits: A print event does not prove that a physical copy was printed successfully.