---
title: "How to Take Screenshots for Documentation"
canonical: https://supportpages.io/guides/take-screenshots-for-documentation
updated: 2026-08-13
---

A written capture standard - window width, zoom, account, theme, crop - and a first set of screenshots that follow it. The standard matters more than any individual image, because the thing readers notice is inconsistency, not imperfection.

## Before you start

Set up a dedicated demo account with realistic data in it. Not your own account, and not an empty one. Your account has real customer names in it; an empty one shows empty states that look broken and teach nothing.

Populate it with plausible fictional data you would be happy to publish - sensible names, realistic volumes, nothing that looks like a placeholder. "Acme Corp" and "Project 1" both signal that nobody cared.

## Steps

1. **Fix the browser width and never change it.**
   Pick one and record it. 1440px is a reasonable default: wide enough to show real layouts, narrow enough that text stays legible when the image is scaled down in an article.

2. **Set zoom to 100% and leave it.**
   Zooming to fit more in produces images whose text is smaller than the surrounding article text, which readers experience as blurry even when it is sharp.

3. **Choose one theme and commit.**
   If your product has light and dark modes, pick the one most users see. Mixing them across a help centre is the single most visible inconsistency available.

4. **Hide everything that is not your product.**
   Browser bookmarks, extensions, notification badges, the clock. A stray extension icon dates a screenshot as precisely as an old button label does.

5. **Capture the region, not the window.**
   Crop to the part of the interface the step is about, plus enough surrounding context for the reader to locate it. A full-window screenshot for a step about one button makes the reader hunt.

6. **Keep the crop boundaries consistent.**
   If you crop to the content area in one image, do it in all of them. Ragged crop boundaries across a set read as carelessness even when each individual crop is sensible.

7. **Annotate sparingly and consistently.**
   One accent colour, one arrow style, one box style. If you number steps inside an image, number them the same way every time.

8. **Write the standard down.**
   Width, zoom, theme, account, crop rule, annotation colour. Put it somewhere the next person will find it. This is the step that makes the other seven survive you.

![Five stacked rows labelled width, zoom, theme, account and crop, each showing a single fixed value.](/images/guides/figures/take-screenshots-for-documentation.webp)

*The whole standard. Five values, written down once.*

## Common mistakes

**Screenshotting your own account.** Real customer names and real email addresses end up published, and you will not notice until someone tells you.

**Capturing at retina resolution and not accounting for it.** A 2x screenshot displayed at 1x looks great and doubles your file sizes. Decide which you are doing and be consistent.

**Annotating in the screenshot tool's default red.** Every product's documentation uses that red. Use your brand accent and the images look like yours.

**Including the cursor by accident.** A stray pointer in the corner of one image and not the others is the kind of small inconsistency readers register without identifying.

**Capturing before the data loads.** Skeleton loaders and spinners make it into more published documentation than anyone would like. Wait for the real state.

## When this stops scaling

A written standard solves consistency for as long as one person is doing the capturing. It starts to fail on two fronts.

The first is multiple authors. A standard that lives in a document is followed approximately - one person crops tighter, another uses a different demo account, a third prefers dark mode - and the drift is gradual enough that nobody flags it until the help centre visibly has two styles in it.

The second is change. Every screenshot you take is a copy of the interface on the day you took it, and the standard says nothing about keeping them current. A team with excellent conventions and no maintenance mechanism still ends up with a help centre full of accurate-looking images of an interface that no longer exists.

Past about thirty images maintained by more than one person, the effort of enforcing a standard exceeds the effort of not needing one. Rendering images from the product's own stylesheet rather than capturing them removes both problems at once - every image is generated from the same source, so consistency is structural rather than a discipline. [SupportPages](https://supportpages.io) does this from your repository. If you are about to write a capture standard for a team, it is worth knowing the alternative exists before you commit to enforcing one.