This weekend, while visiting my sister-in-law and her husband, I learned that people still print web pages. The occasion was choosing pizza. My first thought was that sending everyone a link would have been easier.
They printed the menu and passed it around the people at their house so everyone could decide what to order. It seemed unnecessary to me. We all have phones. The menu was already on the internet. Why introduce a printer into dinner?
But the printed menu did exactly what they needed. It gave the group something to share while making a decision together. My preferred way of doing that task wasn’t the only reasonable one.
I spend a lot of time thinking about how interfaces behave across screen sizes. Apparently, one of those sizes is a sheet of paper.
The task continues after the screen
Print CSS can feel like a relic. It belongs in the same mental drawer as the visitor counter and the instruction to view a site at 800 × 600. Yet the browser still has a print command, and people still use it.
A menu is a useful example because the requirements are clear. People need the item names, descriptions, prices, and ordering information. They need to understand which price belongs to which item. The sticky navigation and animated promotion have less to contribute once the page is on the table.
The same question applies to a recipe someone wants beside the stove, an itinerary shared with a travel companion, or an article saved as a PDF to read later: what information needs to survive when the interface goes away?
That’s a content design question before it’s a CSS question. A page that looks attractive on paper but loses the information someone needs still fails the task.
Small details can earn trust
I don’t have a conversion statistic for a good print stylesheet. I wouldn’t claim that a neatly printed menu makes someone trust a restaurant’s kitchen. But I do think there’s a small signal of care when a website continues to work in a situation its designers could easily have overlooked.
Clipped prices, missing instructions, or pale text on a white page make the reader do extra work. A clear document lets them carry on. That kind of dependability is part of how I judge a product, even when I never consciously notice the design decision behind it.
Print doesn’t need the same investment as the main ordering flow. It deserves enough attention that choosing it doesn’t feel like finding an unfinished part of the product.
Start with the content people need
Before writing a media query, open print preview on a representative page. Read it as if you no longer had access to the website. Look for missing content, unnecessary controls, and information whose meaning depends on color or interaction.
For a menu, I would keep the restaurant name, phone number, categories, items, prices, and dietary information. I’d remove navigation, search controls, and buttons that can’t do anything on paper. A useful image can stay; a decorative background usually doesn’t need to.
Be specific about what you hide. A broad rule that removes every header could also remove the article title or the restaurant’s contact details. Keeping the main content in semantic HTML gives you a better starting point, but the printed result still needs review.
Give paper its own layout
The browser applies rules inside @media print when printing, including saving a page as a PDF. You can adapt the same document without maintaining a second copy of the content.
Here’s a starting point for a page with a .print-content wrapper around its title and body. The other classes identify the surrounding site controls:
@media print {
body {
margin: 0;
background: white;
color: black;
font-size: 11pt;
line-height: 1.5;
}
.site-navigation,
.site-footer,
.share-controls {
display: none;
}
.print-content {
display: block;
inline-size: min(70ch, 100%);
margin-inline: auto;
}
.print-content :is(h1, h2, h3, p) {
inline-size: auto;
max-inline-size: none;
}
}I chose 70ch to keep the body copy from stretching across the whole sheet. Long lines can make it harder to keep your place and find the start of the next line. W3C’s explanation of Visual Presentation describes this difficulty for people with reading or vision disabilities and recommends lines no longer than 80 characters. A comfortable reading width is part of making the printed page useful.
The exact 70ch is my starting point for this design. The ch unit measures the advance width of the font’s 0 glyph, so it doesn’t guarantee 70 characters per line in a proportional font. Check the actual text in your chosen typeface and adjust the width as needed.
The wrapper establishes one reading width for the title and body. Setting 70ch separately on each heading would produce different physical widths because the unit depends on that element’s font. Existing screen grids, fixed heights, and text-width rules may need their own overrides. This is a starting point to adapt to your markup and cascade.
Sheet margins belong to @page. Unlike padding on a long content wrapper, page margins reserve space around each sheet:
@page {
margin: 30mm 24mm;
}
@media print {
h1, h2, h3 {
break-after: avoid;
}
.menu-item {
break-inside: avoid;
}
.print-content section + section {
margin-block-start: 8mm;
border-block-start: 0;
}
}The two margin values give every sheet 30mm of space at the top and bottom and 24mm at the sides. Padding on the body or an article wrapper doesn’t reliably repeat at page breaks, so @page is the right place to reserve that space. Those margins and spacing values are design choices. Adjust them to the content and check the result on the paper sizes your readers use.
Use break-inside selectively for small groups that belong together, such as a menu item and its price. Applying it to every section of a long article can leave large gaps. Content taller than a sheet has to split somewhere, so treat break rules as guidance rather than a promise of perfect pagination.
On this site, I’ve used spacing to separate printed sections, removing the horizontal rules used on screen. The typography still carries the hierarchy, and the page has room to breathe.
Keep meaning when interaction disappears
A link labeled “ordering information” is useful on screen. On paper, the reader needs the phone number or address it leads to. Short, important addresses can appear beside their links. An article with many long URLs may work better with numbered references at the end.
That’s the approach this site uses. In print, external links in the article gain numbered markers, and a “Link references” section at the end lists their full addresses. Both the markers and the reference list are hidden on screen, where the links already work. This keeps long URLs out of the prose while giving someone reading the printed copy a way to find the sources. Open print preview on this article to see it in practice.
Interactive content needs similar attention. If someone prints a calculator result, preserve the inputs and the finished value. If essential information lives inside a disclosure, make sure it appears in the printed document. Where JavaScript prepares that state, the browser’s beforeprint and afterprint events can help you prepare it and restore the screen afterward.
Make the document readable with backgrounds turned off. Labels and structure should carry meaning even when color doesn’t. print-color-adjust can request that colors be preserved, but the reader’s print settings take priority. Designing around a required background color is fragile.
Where print belongs in a design system
Once several products need print support, repeating the same fixes in every application starts to look familiar. A design system can give teams shared typography, sensible spacing, and components that remain understandable on paper. It also introduces another set of behaviors to design, document, and maintain.
What shared support gives you
- Consistent foundations. Teams can start with an agreed reading width, type scale, and approach to page margins. A printed receipt and an article can feel related while using layouts appropriate to their content.
- Reusable component behavior. A table can preserve readable labels, a status can include meaningful text, and a disclosure can document how its content is made available for print. Each consuming team has fewer decisions to rediscover.
- A place to maintain the work. Print examples in the component documentation make the behavior visible. Fixing a clipped label in a shared component can benefit every product using it, provided the fix is checked in those products too.
Those benefits are most compelling when printing is part of a repeated task: reviewing reports, sharing records, or taking instructions away from the application. The investment has a clear purpose when teams can name the documents people need.
What makes it difficult
Components don’t know the whole document. A table can define how its rows behave, but it can’t know whether the page also needs an account name, a reporting period, or an explanation of the data. A component preview can look excellent while the assembled document has awkward breaks or missing context. Page templates and product teams still have work to do.
Interactive state needs an owner. Should a printed accordion include every panel? Should a paginated table print the current page or all matching records? The system can offer patterns, but the product must decide what the reader expects and ensure the required content is available. Hiding the controls doesn’t answer those questions.
Testing and maintenance grow. Supporting print means checking representative documents across the browsers and paper sizes the team promises to support. Longer translations, real customer data, and a typography change can alter pagination. A screen-focused component update can introduce a print regression, so print checks need a place in the release process and someone responsible for them.
Shared defaults can become too rigid. My 70ch reading width suits prose. A detailed financial table may need a wider page or landscape orientation. Applying the same layout everywhere can make useful documents harder to read. Exceptions need a documented path, and adding print props to every component can burden teams that rarely need them.
How I would scope it
I’d start with shared print foundations and documented behavior for the components people actually print. The system team would own those defaults and examples. Product teams would own content selection, current application state, and review of complete documents. Frequently used combinations could become supported document templates as the need becomes clear.
For an occasional article or menu, a focused stylesheet may be enough. For products where printed reports are a regular deliverable, reusable templates and broader testing have more value. Either way, documenting the scope matters: teams should know whether they’re getting readable defaults or a maintained report layout. That keeps a useful layer of polish from becoming an accidental promise to support every possible document.
Check the actual pages
Emulating print styles in developer tools is useful for working on CSS. Print preview or a saved PDF shows the page breaks that need a separate check.
For a first pass, I would check:
- Completeness: titles, prices, instructions, images, and any selected values are present.
- Reading order: the document makes sense as a single flow without the screen layout.
- Page breaks: headings stay near their content, small related items stay together, and long sections can split.
- Paper fit: Letter and A4 output have usable margins, with no clipped tables, code, or text.
- Print settings: the page remains legible without background graphics and with browser headers and footers enabled.
- Return to the site: dismissing the print dialog restores any disclosures or other interface state changed for printing.
It’s worth checking a short page and a long one. The first sheet can look excellent while the fifth has a problem nobody saw.
Make room for the way people use things
I still would have sent the pizza menu to everyone’s phones. That preference tells me something about how I use the web, and very little about how everyone else should use it.
The visit prompted me to revisit the print styles on this site. Giving the content sensible margins, readable typography, and a coherent order felt like finishing a part of the design I’d left unattended.
People will use a product in ways that don’t appear in the mockup. Sometimes a little CSS is enough to make that work well. Sometimes it helps a room full of people order pizza.