Adapting To The InkTips And Tricks For Print Style Sheets
Print continues to be treated somewhat cursorily by most Web designers, who tend to be obsessed with pixels rather than printers. In the real world, a significant portion of people rely on pages printed from websites for reference: there’s still something about having a physical sheet of paper in one’s hands, even in this age of digital saturation.
Web developers can take several steps to bridge the gap between the worlds of printers and LCD screens:
- Treat print as an equal partner in adaptive and responsive design.
- Print background images and colors, where appropriate.
- Add visible URLs or scannable links for easy reference from the printed page.
- Use CSS filters to improve the result of printed graphics.
Design For Print, Not Screen
First, let’s cover the basics. Modern print style sheets are typically placed within a media query:
@media print {
}
Recreating the entire CSS for your website is not necessary because the default styles will, on the whole, be inherited by the print query; only the differences need to be defined. Most browsers will automatically reverse colors when printing in order to save toner, but this won’t have the same degree of quality as a handcrafted solution. For best results, make color changes explicit. At the very least, a basic print media query should consist of the following:
@media print {
body {
color: #000;
background: #fff;
}
}
While display: none has rightly been derided in responsive design, it is entirely appropriate for print style sheets: in most cases, our goal is not to recreate a screenshot of an entire page, but to provide a concise, well-designed print version of it. As a second step, eliminate page elements that are simply irrelevant in print, including navigation bars and background images.
/* Default styles */
h1 {
color: #fff;
background: url(banner.jpg);
}
@media print {
h1 {
color: #000;
background: none;
}
nav, aside {
display: none;
}
}
Writing a print style sheet is one of the few times when you’ll ever use centimeters or inches in CSS. Largely irrelevant to screens, real-world measuring systems become very useful in print. To ensure that you are using the printed page effectively, write CSS to display your content edge to edge, negating any margins or padding that may be present, and balance this with an @page rule:
@media print {
h1 {
color: #000;
background: none;
}
nav, aside {
display: none;
}
body, article {
width: 100%;
margin: 0;
padding: 0;
}
@page {
margin: 2cm;
}
}
For content to which users can be expected to add handwritten notes on the page, such as educational material, you might consider increasing the print margin.
We also need to ensure that content is not broken across pages when printed. One obvious step is to prevent headings from being printed at the bottom of the page:
h2, h3 {
page-break-after: avoid;
}
Another rule will prevent images from bleeding over the edge of the printed page:
img {
max-width: 100% !important;
}
A third will ensure that articles always start on a fresh page:
article {
page-break-before: always;
}
Finally, we can prevent large elements, such as unordered lists and images, from being split across multiple pages.
ul, img {
page-break-inside: avoid;
}
While these declarations are not exhaustive, they’re a good start.
Force Background Images And Colors
On some websites, such as portfolios, background images and colors are an important visual component. If the user is printing from a WebKit browser (Google’s Chrome or Apple’s Safari), we can force the printer to render the colors as seen on screen (i.e. force any background images and colors to appear on the printed page). Generally speaking, we would do this for color printers, which we can test for in a separate media query:
@media print and (color) {
* {
-webkit-print-color-adjust: exact;
print-color-adjust: exact;
}
}
Sadly, there is (as yet) no immediate equivalent in Firefox, Opera or Internet Explorer.
Expand External Links For Print
We can’t (yet) directly interface with a printed page to explore links, so link URLs should be visible on the printed version of the Web page. To keep the page relatively clean, I prefer to expand only outbound links in articles, and suppress internal ones. If you’ve used relative URLs on your website for local links, you can easily do this through an attribute selector and :after pseudo=classes, thus preventing internal links and links around images from being printed:
@media print {
article a {
font-weight: bolder;
text-decoration: none;
}
article a[href^=http]:after {
content:" <" attr(href) "> ";
}
}
Take the following HTML code and content:
<p>You’ve explored this <a href="/blog">website</a>; now it’s time to <a href="http://www.webplatform.org/">read other Web development documentation</a>.</p>
Here is the printed result:
One issue is that anchor links and links around images will also be expanded on the printed page. We can fix the anchor links fairly readily with a countermanding CSS rule:
article a[href^="#"]:after {
content: "";
}
Links around images are rather more difficult, because CSS does not currently allow for the selection of an element based on its children. Ideally, links around images would have a class that we could target via CSS. Longer term, CSS4 features a parent selector that will do the job:
$a:after > img {
content: "";
}
CSS4 will also make expanding external links easier:
a:not(:local-link):after {
content:" <" attr(href) "> ";
}
All of these approaches assume that users will continue to type in URLs by hand. A better solution is to make the digital version of the page easier to access by providing a matching QR code.
Print QR Codes For Easy URL References
Often regarded as an advertising eyesore, QR codes have their place in certain circumstances. One obvious example is providing an easily-scanned sigil on a printed Web page that enables the user to return to the live version without having to type the URL.

Web page printed with a self-referential QR code. Larger view.
To create the matching QR code, we’ll use Google’s Chart API, which has four required components:
- The kind of chart information we want Google to deliver (
qr, in our case); - The rendered size of the QR sigil, in pixels;
- The URL to encode;
- The form of character encoding to use.
We’d typically associate the URL with a heading element at the top of the page:
<header>
<h1>Lizabeth’s Salon</h1>
<h2>Providing Intellectual Stimulation Online Since 2001</h1>
</header>
To create the printed result, we’ll provide a margin on the right side of the h1 that is large enough for the heading, and then position a QR code in that area:
header h1 {
margin-right: 200px;
margin-bottom: 2rem;
line-height: 1.5;
}
Because the QR code will be unique to each page, this would be added as an embedded style sheet:
@media print {
header h1:after {
content: url(https://chart.googleapis.com/chart?cht=qr&chs=150x150&chl=http://yourdomain.com&choe=UTF-8);
position: absolute;
right: 0;
top: 0;
}
}
This approach has the downside of forcing the developer to enter a URL individually for each page into the API code. If your Web host is running PHP, you can provide the URL of the current page automatically:
@media print {
h1:after {
content: url(https://chart.googleapis.com/chart?cht=qr&chs=150x150
&chl=http://<?=$_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];?>
&choe=UTF-8);
position: absolute;
right: 0;
top: 0;
}
}
For WordPress:
@media print {
h1:after {
content: url(https://chart.googleapis.com/chart?cht=qr&chs=150x150
&chl=http://<?phpthe_permalink();?>&choe=UTF-8);
position: absolute;
right: 0;
top: 0;
}
}
Obviously, both of the solutions above will only work on PHP and WordPress pages.
Use CSS3 Filters To Improve Print Quality
Browsers often have issues with printing out banner images, especially if the banners are white against a dark background:
| Logo as a solid image | Printed result |
|---|---|
![]() |
![]() |
| Logo as an alpha-masked PNG | Printed result |
|
![]() |
In theory, you could use a CSS sprite to switch between different versions of the logo for print, but that would mean doubling the file size for potentially little benefit. Instead, I recommend using CSS filters (and their SVG equivalent, for Firefox) to invert the image just before it hits the printed page:
@media print {
header {
background: none;
color: #000;
}
header img {
filter: url(inverse.svg#negative);
-webkit-filter: invert(100%);
filter: invert(100%);
}
}
CSS3 filters do what you’d expect — invert the colors in header images, turning black to white and vice versa — but they only work in Chrome and Safari. To cover Firefox, we need a different approach — the equivalent filter written as a separate SVG file:
<svg xmlns="http://www.w3.org/2000/svg">
<filter id="negative">
<feColorMatrix values="-1 0 0 0 1
0 -1 0 0 1
0 0 -1 0 1
0 0 0 1 0" />
</filter>
</svg>
The workings of the feColorMatrix SVG filter are a little complex to cover here. Much more information can be found in the article “Applying Color Tints to Web Pages With SVG Filters and JavaScript on Dev.Opera.
The result of printing either form of logo (i.e. alpha-masked PNG or solid-black background) is now this:
Conclusion
Due in part to the fact that printer use is not tracked by website analytics software and, thus, lacks strong metrics (although achieving this is possible, too, which we may discuss in a future article), print tends to be broadly ignored by Web developers. This is somewhat understandable, because most of the time we only read and browse pages online. As a result, developers tend to develop websites for the screens and devices in front of them, rather than for the printer at the other end of the office.
On the other hand, even if people only occasionally need to print something from the Web, it would be ideal if the page design adapted to the printer, just as modern websites adapt to various screen sizes and devices. Print should be considered another aspect of adaptive design, usability and accessibility, and an equally important part of Web development.
By treating print as another aspect of adaptive design, we fulfill the needs of more website users — and at the same time, save ink, paper and other resources, all of which are important aspects of sustainable design.
More Resources
A List Apart has a long and laudable history of supporting print style sheets through its articles and tutorials. While some of the following resources are now fairly old, they remain relevant to anyone who wishes to explore print as an equal partner in Web design.
- CSS Design: Going to Print, Eric Meyer (10 May 2002)
- Improving Link Design for Print, Aaron Gustafson (19 September 2005)
- Building Books With CSS3, Nellie McKesson (12 June 2012)
- How To Set Up A Print Style Sheet, Christian Krammer (24 November 2011)
Source of image on front page: Bottlerocket Creative.
(al)










Ethan
March 8th, 2013 4:42 amI love your approach to anchors. That makes great sense. I wish that Google analytics tracked prints so that we would knot what that activity is like. Usually having some statistics even if their lower in number help to make sure this kind of attention to detail is taken.
Dylan Valade
March 8th, 2013 9:16 amYou can track custom events in Google Analytics. This is the code you could use for a print button on the page.
To get any Ctrl+P / Cmd+P clicks you could use Javascript to capture the key strokes and push those events to GA too. If someone clicks Print from the browser toolbar I think that would be out of trackable scope.
https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide#Actions
Jake
March 10th, 2013 5:48 amYou could always use a background image in the print stylesheet to pull in a server-side script that tracks the number of times each page is printed then redirects to an image.
Jake
March 8th, 2013 4:47 amThat’s the second article about print stylesheets I’ve read this week. Neither have provided stats on how many people actually actually print pages. You claim it’s a significant portion so how have you come to this conclusion?
Carlo Santos
March 9th, 2013 7:57 amI would also like to see stats on how many out there still print web pages. The only ones I know doing that are the “not-so-techy” and/or old clients. In my experience, they prefer sending fax over email or phone when asked for feedback regarding their websites. We used to receive fax of web pages with notes on which part to revise in my previous job. Those clients highlighted/encircled elements which they wanted to be changed. Some even wrote things like “MAKE IT POP!” with an arrow besides a button.
Anyway… all I want to say is it would be nice to see some stats to help us decide whether to put time on print stylesheets or not.
Dudley Storey
March 14th, 2013 12:14 pmHi Jake, and thanks for writing:
My statement on printed web page use is based on direct experience: approximately 10% of my students print pages from my blog as references, some even going so far as to assemble those pages into “books”. Of course, the use of print may be higher (or lower) in other contexts; I expect that hard data will be a little difficult to come by. Your question, and the many excellent suggestions here, have started me down a path of exploration to gain some reliable statistics, which I hope to present in several months.
Tez
March 8th, 2013 5:01 amThanks for the useful info on links.
There are a couple of issues which I think should be mentioned
- You do not have control over default browser print headers and footers
- You do not know the page size especially if you work in multiple countries so sizing in physical measures may well be inappropriate
- Business web based applications, which are likely to have a relative high rate of printout are often accessed through older versions of IE which has “quirky” css support
These issues have often lead me to a print to pdf / word document solution, especially in internal web applications, where providing the internal server and port in a print out such as an invoice / receipt looks pretty unprofessional.
Brad T
March 8th, 2013 8:41 amYour concern over paper size confuses me. If you size your style sheet based on, say, North American letter size (215.9mm) and leave a decent margin (2cm as noted in the article is really not enough in any case), then the slightly smaller A4 (210mm) would not be greatly affected. You may be slightly safer to base on A4, in which case the NA Letter page would just have margins that are 3mm wider.
The length of the paper wouldn’t matter much as the content is flowed anyway, and you can still have decent control over page breaks based on content, not paper size.
Print to PDF may be a good solution for invoices etc, but if you’re worried about a web application looking unprofessional, I’d for sure stay away from spitting out Word files to users. I for one don’t really care about web addresses printing on pages.
Ramon
March 8th, 2013 5:35 amMy biggest issue is that client pay for a website, not for a printed website. To get this thing right it requires alot of work and generates nothing. Companies could try to sell a printable page, but most clients already have trouble paying for responsive… I can’t imagine them paying extra for a good printable website….
Other than that, great article!
Stomme poes
March 8th, 2013 7:31 amWell, clients also usually don’t pay for *good* or valid code, or for accessible web pages, and several other things which also “create a lot of work and generate nothing” (if “generate nothing” means, does not bring in much extra money).
It’s up to the developer to decide the quality of code, and so I see the article above as suggestions for the developer who has already decided they want/need to do this.
Adrian Roselli
March 8th, 2013 7:18 amI disagree with your approach to force background colors and images. Because this uses more ink, it can be a burden on users who pay too much for ink or have jacked up print nozzles (as in many home inkjet users). Also, because printed colors can be darker than on screen, contrast problems can be enhanced which can lead to even harder-to-read content for low vision users.
Regardless, I think it’s great that there’s another article on print styles (I wrote the one for .net Magazine, along with many prior rants) and I’m hoping web developers finally start to take it seriously.
Stomme poes
March 8th, 2013 7:28 amActually, I don’t see why we’d use a not-supported-by-the-IE-most-offices-still-use for the background image issue… I am talking about the invert. Why not
(instead of a sprite).
This prevents the non-printers from downloading a larger (sprite) file which you mentioned. But it also works in the IE all of our business customers are still using because they haven’t yet forked out the cash to upgrade their 100+ machines to Windows 7 and other browsers don’t work with their 10-year-old Active-X-requiring Java apps. Yeah all the other suggestions here would also b0rk, IE is IE, but the background one was one that has potential to be a bit old-fashioned and work pretty reliably.
Assuming those who print are way in the minority, yes they have a new HTTP request but then comes in the whole “how much of your customer’s ink are you planning to waste regardless of how super duper awesome your image really is” issue anyway, which means every developer should be very careful about making printers print images in the first place. If there’s one place I would say, go ahead and force the printing of an image at least once, it would be the logo, if reasonable. It can replace/create the letterhead, usually seen as “official” in many circles anyway.
Brad T
March 8th, 2013 8:47 amGreat article.
As a print designer who moved into web later, print style sheets have been very important to me. It is a struggle to wrangle the dynamic and experiential nature of web pages onto a piece of paper, but it’s good practice to acknowledge that people are printing from the web and that experience needs to be taken into account.
We spend so much time ensuring that the on-screen experience is crafted to the finest detail, but many designers and developers too often leave the off-screen experience to the browsers (which, let’s face it, were not designed or intended to create quality print pieces).
Frederick
March 8th, 2013 9:38 amI love inverting the SVG for print, great idea.
Ted Drake
March 8th, 2013 9:48 amIt’s been a long time since I’ve tackled a print style sheet. I think I built a custom style sheet for a Yahoo property about 7 years ago. Most of the time people want to create a printer friendly page.
That being said, this is one of the best CSS articles I’ve read in a while. The QR code snippet is brilliant. I’m going to wholeheartedly steal that tip!
Thank you for making print style sheets interesting again.
Scott
March 8th, 2013 10:28 amI agree with and support the desire to make a print stylesheet for every website. However, nearly every client that I’ve dealt with, including internal ones, always want their website to print exactly the same as it displays on the screen.
That is frustrating as a designer/developer as we know it’s not really feasible cross browser, and we always advocate for a print stylesheet as a Micorsoft Word-esque alternative.
Only two clients in my 12+ years of web design/development have sided with that argument.
Steven
March 9th, 2013 12:39 amThanks for the update, it has been a while since I have looked at print css.
Quick question: Have you actually tested the @media print with content url? across browsers. I thought that was a very handy example, but upon actual testing in various browsers, found that I got anything from IMAGE alt displaying (likely due to not being cached in time) and not displaying at all. I think Firefox was the only browser that behaved as expected.
As such, your code only seems reliable without the @media print part:
Helen Fernety
March 10th, 2013 8:10 amW3C recommends for print media stylesheets using “pt” for the font-size unit of measure.
body {
color: #000;
background: #fff;
font-size: 12pt;
}
Pt (point) is what your printer speaks when it comes to font sizes. Some people use pc (pica) but when it comes to our testing “pt” have been the most constantly supported across printers.
FUN FACT – 1 point (1pt) equals 1/72 of an inch
MORE – http://www.w3.org/TR/CSS2/media.html
Peter
March 11th, 2013 1:10 amAlthough a good article, please note that the page-break-inside declaration only works in Opera (http://www.w3schools.com/cssref/pr_print_pagebi.asp) and that the page-break-* functionality has been buggy in Firefox since 2002: https://bugzilla.mozilla.org/show_bug.cgi?id=132035
Also removing the link target from further link types like tel: and mailto: improves readability when it otherwise would create redundant information:
a[href^="tel"]:after, a[href^="mailto"]:after {content: "";}Stuart
March 13th, 2013 11:54 pmI am interested in knowing why you chose to use
@media printrather than using a seperate stylesheet using<link rel="stylesheet" href="print.css" media="print">The advantages to using a seperate stylesheet are that you do not need to undo most/a lot of your previous CSS rules – you are starting from scratch. If you have a well-structured page, this (IMHO) makes things a lot easier.
Maybe I am missing some advantage here, though…
Dudley Storey
March 14th, 2013 12:03 pmHi Stuart, and thanks for your question: there’s a few reasons I tend to embed print media queries in the main CSS.
- either way, you will have to countermand your “natural” CSS rules (imagine for a moment that your separate linked print stylesheet was blank; that doesn’t mean that the printed version of the web page will be; the browser will still use the default screen styles for print). A media query always builds on the default styles, so in that sense, a separate stylesheet doesn’t offer any advantage.
- unless the CSS for the site is extremely complex, I find it easier to be able to reference all the styles from a single document. Dealing with the print styles separately increases the chances that I will neglect something, or forget to do print styles entirely. It’s easy to change a header in the main CSS, scroll down and modify that change for print.
- perhaps most importantly, keeping the print stylesheet as a separate document means that you are adding an extra HTTP request to the web document. While it’s true that modern browsers such as Chrome will evaluate a media query in a linked stylesheet to determine if it is applicable to the current presentation context, the file will still be downloaded, albeit later in the load sequence. When a print stylesheet may only be an extra 12 lines of code, I feel its more efficient to place it inside the main CSS file and avoid the extra request.
I hope this helps!
Stuart
March 14th, 2013 3:52 pmThanks for your answer, Dudley. My understanding (for which I am more than happy to be corrected! :)) is that, unless you specify
@media screenfor all of your screen CSS, then those same styles will be applied to the printed document. The only way to prevent that is to ‘undo’ those styles in the@media printsection of your css.If you use a print stylesheet, then the only thing you need to worry about (or ‘undo’/modify) is the default browser stylesheet.
Is this understanding incorrect?
You’re certainly right about the extra request, though – I was just having a quick look around and found this http://www.phpied.com/5-years-later-print-css-still-sucks/ from last year!
Many thanks for the great article (forgot to do that in my previous comment!) – very informative and a very nice read!
Jan
March 14th, 2013 2:42 pmI greately believe in print style sheets. We developer tend to neglect all the “regular people” out there, which *do* print everything they see on screen.
And sorry: If you do a responsive design and bill for that you should also afford the time to set up a decent print stylesheet! A while ago I read an article about how many (the most!) of the full-fledged responsive websites did not have a print stylesheet!
Gary B
March 15th, 2013 7:19 amNice article thanks,
I need to produce a print stylesheet for a clients website and the timing of this is good.
Also I frequently print out articles, especially tutorials as it is much easier to have the printed version next to the monitor while you do what is being taught , saves trying to flip between windows.
also I quite often read articles in bed and paper is best for that !
even the ipad screen is too small sometimes.
cheers
Todd C
March 19th, 2013 9:28 amCan I just say, this article has everything I need (including stuff that I didn’t know was possible [e.g. the QR code hotness]) to create awesome print CSS which, coincidentally, I was just discussing with my team re: an upcoming project, so thumbs up for timing
Sinan Ghareb
March 22nd, 2013 12:51 amI was enjoying the reading of this article and giving me some ideas for my new redesign of my portfolio site until I read who is the author… He is my teacher.
Thank you sir for all knowledge that you keep providing. You will always be one of the few great mentors in my life.
~Sinan
Merry Smith
March 22nd, 2013 1:37 amI usually don’t print pages to my physical printer, but I do print to pdf quite a bit, so I think print style is still and should be important. The only part I disagree with is forcing the background color and/or image. Too much wasted ink. If the client thinks it is absolutely necessary, how about a smaller version of the image for print?
I like external links expanding in print, since link text only does the reader no good.
Michael Rawlings
March 25th, 2013 8:29 amGreat article. I particularly liked the use of Google’s chart api to generate dynamic self-referencing QR codes. It’s a great use that I had not considered previously. I find that print has been largely ignored by the web developer community and it’s somewhat disheartening, especially with the current limitations of browsers. Since 1999 the W3C has been working on the paged media module which is still in the Working Draft state. The only portion of this that has been implemented in browsers are the page margins that you mentioned in the article. We still, in 2013, have no way of properly setting simple headers and footers for printed pages. I’m looking forward to this module as well as the generated content for it, especially cross-references (http://www.w3.org/TR/css3-gcpm/#cross-references). There have existed programs since the early 2000′s that have supported this module to convert html to pdf (eg. PrinceXML), something that should really happen from within the browser and not require separate software nor a conversion to pdf before printing as specified by html/css is possible.
Adrian Roselli
March 26th, 2013 11:10 amI think there is a resurgence in people paying attention to print styles. That is awesome. However I still hear plenty of resistance, with the argument often centered around lack of data saying that users print pages.
[self-promotion] I’ve just put together a tutorial that shows you how you can track printed pages on your own site with Google Analytics: http://blog.adrianroselli.com/2013/03/tracking-when-users-print-pages.html [/self-promotion]
Hopefully in the absence of aggregate data for the web as a whole, we can at least track our own sites and better support our own users.
daniel
April 4th, 2013 1:22 pmThank you! great article! comes handy! more tricks out there when it comes to print.css ?
^_^