Screenshots are the most undervalued images on the internet. Documentation, tutorials, release notes, support replies, landing pages: an enormous amount of what people actually need to see is a picture of a screen, and most of those pictures are worse than they need to be for reasons that take seconds to fix.
I care about this more than is probably reasonable, so here is everything I have worked out.
Capture at the right size in the first place
The most common problem is not the framing, it is that the screenshot was taken at the wrong scale and can never recover.
Capture on a high density screen if you can, or set your browser zoom to 200 per cent before capturing, so you have twice the pixels the layout needs. A screenshot taken at exactly the display size will look soft on any modern phone, and nothing you do afterwards fixes missing pixels.
Resize the browser window before capturing rather than cropping afterwards. Cropping a wide window down to a narrow strip gives you a strip; resizing the window first gives you a layout that actually makes sense at that width.
And capture the region, not the whole screen. Nobody needs your bookmarks bar, your desktop, or the notification that arrived at the worst moment.
What to include, and the part everybody gets wrong
The instinct is to show everything so the reader can orient themselves. The result is a picture where the important part is two per cent of the pixels.
Show the smallest region that still makes sense on its own. Usually that is the panel or dialog being discussed plus enough surrounding interface to say where it lives. If the reader needs the whole application to understand where they are, that is one wide screenshot at the start of the article, not every screenshot in it.
Then point at the thing. A rectangle, an arrow, a numbered pin. It takes ten seconds and removes an entire paragraph of “in the upper right area of the third panel”.
Two rules for annotation: keep the color consistent throughout a document, and pick one that does not appear in the interface you are annotating. Red on a red-accented app is invisible. And never annotate on the pixels themselves. Put marks on their own layer so the screenshot can be replaced when the interface changes without redoing the arrows.
Why a raw screenshot looks wrong on a page
Here is the bit I find genuinely interesting. A raw screenshot has hard edges that run straight into your page background, and no depth at all. It reads as a foreign object, an artefact rather than an illustration.
Four small things fix it, and they are the reason “beautified” screenshots look professional.
- Padding. Space around the capture, on a background of its own. This alone does most of the work, because it separates the screenshot from the page.
- Rounded corners. A small radius, matching whatever else on your page has corners.
- A soft shadow. Subtle. It says “this is a window above the page” rather than “this is a hole in the page”.
- A backdrop. A gradient or a soft color field. If it is derived from the colors already in your document, the screenshot belongs to the page instead of visiting it.
Optional but often right: browser, window or phone chrome around the capture, which instantly says what kind of thing you are looking at. A screenshot of a mobile view inside a phone frame needs no caption explaining that it is the mobile view.
Do not overdo the frame. A perspective tilt looks impressive in a hero image and makes documentation harder to read, because now the reader is parsing a rotated interface. Straight on for anything instructional.
The things that get you in trouble
Real data. Screenshots leak. Customer names, email addresses, invoice numbers, tokens in a URL, an open tab you forgot about. Blur or block them out, and do it with a solid shape rather than a blur if it actually matters, because blurred text of a known format can sometimes be reconstructed.
Better: keep a demo account with plausible fake data and take screenshots there. It is faster than redacting and the results look better, because the fake data can be chosen to be short and tidy.
Personal clutter. Your bookmarks say a lot about you. So does the battery at four per cent, the clock at 3am and the eleven browser tabs.
Screenshots that go stale. Interfaces change, and a tutorial full of an old version is worse than no pictures at all, because it makes readers doubt everything else. Capture at a consistent window size and keep the source files, so that regenerating a set is a repeat rather than a project.
Consistency, cheaply
If a document has more than about five screenshots, decide the treatment once: same padding, same radius, same shadow, same backdrop, same annotation color, same capture width. Then apply it to all of them.
Record it as an action and run the set through in one pass, or build the frame once as a template and drop each capture in. Either way, the point is that the fifteenth screenshot gets the same treatment as the first, which is not something anyone achieves by hand at the end of a long day.
One last thing
Write alt text for screenshots. I know. But a screenshot is a picture that is entirely information, so an empty alt attribute throws away the whole point.
Do not describe the layout. Describe what the reader is supposed to see: not “screenshot of the settings panel”, but “the export panel with quality set to 80 and format set to WebP”. That sentence is useful to somebody using a screen reader, useful to somebody whose images failed to load, and useful to future you when the picture needs replacing and you cannot remember what it showed.
