Screenshots in docs are an asset until the release ships

A paragraph of documentation rots slowly. A screenshot rots the moment the design team changes a button colour, and it rots visibly — a reader who sees a UI that does not match their screen stops trusting the whole page, including the parts that are still correct.

This is why experienced technical writers are stingy with screenshots. Use one when the reader genuinely needs to recognise something on screen; use text and code blocks for everything else, because text is greppable, translatable, accessible, and diffable, and a PNG is none of those.

But when you do need one, you have signed up for re-shooting it on some future release. The whole game is making that re-shoot take two minutes instead of twenty.

The reason a re-shoot is expensive is usually not the capture — it is reconstructing the conditions. What browser width was that? Light or dark mode? Which demo account? Was the sidebar collapsed?

Write those down in the docs repo before you take the first screenshot: a fixed window size, one theme, one seeded demo account with believable non-real data, no personal browser chrome, no notification badges. Every writer on the team then produces images that sit next to each other without looking like they came from four different products.

The other decision is redaction policy. Docs screenshots are public. If your demo data has anything resembling a real email address, an API key, or an internal hostname, blur it in the capture rather than trusting that nobody will zoom in. The annotation editor’s blur is rendered into the exported file, not layered over it.

Documentation images live in version control alongside the Markdown that references them. The default macOS behaviour — everything to the Desktop with a timestamp name — means every screenshot needs a manual move and rename before it is usable, and that friction is why docs screenshots end up inconsistent.

Configuration references, YAML files, settings pages, and long API responses are the screenshots most likely to be wrong, because they do not fit on screen and get cropped to the interesting third. The reader then cannot tell what else is in the file, which is often the actual question.

Scrolling capture stitches a long page into one tall image — web pages, documentation, code files, long Notion pages, and most standard macOS scroll views. For a config reference, one tall image of the whole file beats three crops with "..." between them.

Where the content is text rather than UI, though, do not screenshot it at all. Paste it as a code block. A screenshot of YAML is the single most common documentation mistake, and it makes the config uncopyable for every reader.

When a release changes the UI, you need to find every affected image fast. The searchable gallery keeps every capture you have taken, filterable by project and filename, so the set from the last pass is one search away and you can shoot the new versions against the old ones for comparison.

On-device OCR helps here in an unobvious way: extracting the text out of an old screenshot tells you what labels were on screen when you took it, which is exactly what you need to check whether a UI copy change has invalidated the image.

It does not detect stale screenshots. Nothing tells you that a PNG in your repo no longer matches the product — that remains a human review step at release time, and it is the hardest part of the job.

It does not automate capture. There is no scripted or headless mode, no CI integration, no Playwright-style "regenerate all docs screenshots on every build". If your screenshot set is large enough that manual re-shooting is unsustainable, an automated browser screenshot pipeline is the right answer and SnapShelf is not it.

And it has no CMS integration. Snagit has deeper long-form documentation templates and step-capture workflows if that is the shape of your work; SnapShelf is faster and native, but it is a capture tool, not a documentation system.