The Case for Printable Websites

By Brennen Puth | Published: 2026-10-24

👋 About the Author

I am currently seeking new professional opportunities! I will soon be completing my undergraduate studies, earning a BS in both Computer Science and Cyber Operations.

My technical toolkit includes:

Primary Expertise: Web Application Development & Java.
Additional Languages: Rust, C++, Python, and several others.

If you are interested in my previous work, please check out my [projects list] or reach out to me directly so I can provide my resume. I welcome any and all professional leads!

The Philosophy of Paper

While digital reading on a laptop is convenient, I find that ~~digital annotations~~ marking up a physical, printed document allows for much deeper engagement. There is a specific psychological shift that happens when you pair a printed page with a whiteboard; it creates an atmosphere where the work feels genuinely significant.

Consequently, I wanted to ensure that the people reading my content could enjoy it in this tactile medium.

The "Default" Experience

Most of us assume that hitting CTRL-P is enough. However, when I tested this on my own site, the results were underwhelming:

The typography was far too large (roughly 2 levels too big).
The header looked cluttered and unprofessional.
Hyperlinks, which look great in color, appeared as a muddy gray in grayscale.

Implementing Print-Friendly Design

Fortunately, the web community previously placed a high value on printability. By utilizing specific CSS selectors, we can target the print medium specifically.

Technical Implementation

Below is the logic I used to refine the output:

@media print {
  .onlyPrint { display: inline; } 
  p, ol { font-size: 12pt; } 
  h3, h4 { font-size: 13pt; } 
  h2 { font-size: 14pt; } 
  h1 { font-size: 16pt; } 
  .giallo-l { font-size: 11pt; } 
  a { color: black !important; } 
}

The logic follows a simple scaling formula where the printed size $S_p$ is significantly smaller than the screen size $S_s$ : $\text{Scale Factor} \approx \frac{S_p}{S_s} < 1$

Feature Breakdown

Class/Element	Purpose	Effect
`.onlyPrint`	Addition	Adds elements (like author attribution) only to the paper version.
`.noPrint`	Subtraction	Removes unsightly elements (like the site header) from the print job.
`a` tags	Color Shift	Forces links to `black` to ensure readability in B&W.
`h1` $\rightarrow$ `p`	Resizing	Adjusts variable-scale text to fixed point sizes.

The Optimization Workflow

The Remaining Hurdles

Despite these improvements, the process isn't perfect. I still struggle with codeblocks. They tend to resist breaking across page boundaries, appearing as monolithic chunks that disrupt the flow.

Current To-Do List:

Fix header visibility
Adjust font hierarchy
Correct link contrast
Solve codeblock page-break issues $\leftarrow$ Open for suggestions!

Why Bother?

I'll admit: spending a whole morning hiding and showing elements for a print view is a tedious task. Many developers wouldn't prioritize this. However, if your site is primarily text-based, giving users the freedom to consume that text in their preferred format is a gesture of goodwill.

"The road to good software is paved with kindnesses from software engineers to their users."

Even if it only brings a fleeting smile to one person, it is worth the effort.

Visual Comparison:

Update (2026-10-26): A friend mentioned that this post gained traction on lobste.rs and the front page of Hacker News. While I've been alerted to some flaws in my CSS, I'm glad the article encourages others to consider the printed medium.