How to Capture a Web Page: Screenshots, PDFs, and Code

“Save this page” sounds like one request. It is at least four, and picking the wrong one is why you end up re-doing the work: a screenshot that can’t be searched, a PDF that cut a chart in half, a copied component that arrives with none of its styling. This guide is the decision you actually have to make, and the trade-offs behind it.

Four things people mean by “capture”

When someone says they want to capture a web page, they mean one of these four, and they rarely say which:

• The visible area. What is on screen right now — Cmd+Shift+4 on macOS, Win+Shift+S on Windows. Fast, universal, and it stops at the bottom of your monitor.
• The full page. The entire scrollable document as one tall image, including everything below the fold. This is the one that needs a tool, because no operating system screenshot key knows the page continues past the window.
• A PDF. Either a paginated document produced by the browser’s print engine, or a single very tall page holding one screenshot. These sound similar and behave nothing alike.
• The code. The actual HTML and CSS behind an element, so you can run it, resize it, restyle it, or paste it into a project.

The first three produce pixels or paper. The fourth produces something that is still alive. That distinction drives everything below.

What each format actually keeps

Every capture format is lossy — the question is which loss you can afford. Here is the honest matrix. “PDF” below means a browser print-to-PDF, which is what most people get when they hit Cmd+P.

The third row bites hardest, because a state you never triggered cannot be recovered from the file afterwards. Dropdowns, tooltips and hover styles all close the moment you reach for the shortcut, and getting one of them into a screenshot at all takes a specific trick.

The viewport problem

Every screenshot tool has to solve one structural issue: your window is small and the document is not. The browser paints only what fits in the viewport, so a capture that works by photographing the screen can only ever return the part you happen to be looking at.

There are only two ways around this, and they fail differently.

Resize and snap

Tell the renderer the viewport is now the full height of the document, paint once, and take a single picture. This is what Chrome DevTools’ Capture full size screenshot does — one of five routes to a full-page screenshot in Chrome, and the fastest when it works. It is seamless until the page is tall enough to exceed the compositor’s maximum texture size, at which point it silently truncates or fails. It also confuses any layout written in viewport units, because 100vh is suddenly the whole document.

Scroll and stitch

Photograph the viewport, scroll down exactly one viewport, photograph again, repeat, then composite the tiles into one image. This is how browser extensions work, Grabby included. It has no practical height limit and it triggers lazy-loaded content on the way down. Its weakness is seams: if the arithmetic rounds the wrong way you get hairline gaps, and if the page has a fixed header you get it repeated in every tile.

Both failure modes are common enough to have their own article — why full-page screenshots come back with missing content walks through blank images, repeated headers and captures that stop halfway.

Reflowed or photographed?

This is the distinction that catches people out most often, because both routes end in a file with .pdf on the end.

• Print to PDF hands the page to the browser’s print engine. Any CSS in a @media print block applies, the layout re-runs at paper width, and the result is paginated. You get selectable, searchable text and a small file. You also get whatever the site’s designers decided a printed version should look like, which on many sites is “no navigation, no background colours, and a footer nobody has looked at since 2019”.
• Screenshot to PDF takes the stitched image and wraps it in a PDF whose single page is the size of the picture. Nothing re-runs. What you saw is what is in the file, exactly — but it is an image, so there is no text to select and the file is far larger.

The full PNG-versus-PDF comparison covers the size maths and the page-break traps in detail.

Choosing: what happens to it next?

Skip the question of what format you want. Ask what the person receiving it needs to do, and the format picks itself.

That last row is the one people get wrong most often, because a reference collection is the case where you cannot know in advance what you will need. If you are capturing things to look at again later, how you file them decides whether you ever reopen them.

Capture is step one

Almost nobody wants a raw capture. They want a capture with the irrelevant 80% cropped away, an arrow pointing at the thing they mean, and the customer’s email address covered up. Treating capture and edit as one motion rather than two applications saves more time than any individual tool choice.

Grabby is built around that loop. The full-page screenshot opens straight into an editor tab with crop, arrows, boxes, text, blur and stickers, an undo stack, and PNG or PDF export — and the image never leaves your machine, because the capture lives in that tab’s canvas rather than on a server. What to do in that editor is its own craft: annotating a screenshot so the feedback actually lands and redacting one safely before you share it are the two skills worth learning.

Where each method breaks

Every route below is genuinely useful. Knowing the edge each one falls off is what stops you blaming the page.

That last row is the one developers hit hardest. Copy → Outer HTML gives you a tree with no styling, and copying computed styles gives you hundreds of resolved properties that still miss :hover and @font-face entirely. There is a whole article on copying the HTML and CSS of an element properly, and a follow-on for turning that into a React component.

The short answer

If someone is going to look at it, take a full-page PNG. If someone is going to file it, print it to PDF. If someone is going to rebuild it, capture the code — a screenshot of a component is a specification written in the hardest possible language.

And whichever you pick, spend the extra fifteen seconds on the crop and the redaction. The difference between a capture that gets acted on and one that gets a “which bit do you mean?” reply is almost never the capture method.