Tutorial · images · Published 2026-08-16 · 4 min read
Screenshots for documentation and marketing
Best practice for documentation and marketing screenshots, from capture resolution and DPI to sharpness, accessibility and optimisation.
A documentation or marketing screenshot has two destructive failure modes: it is too blurry to convey the UI it shows, or it is an enormous PNG that slows the page it lives on. Both come from the same habit, capturing whatever the screen gives you and publishing it unchanged. The fix is to capture for the width it will be displayed at, account for the device pixel ratio, and then treat the file like any other image in your pipeline.
Capture at the right resolution
Text is the part of a screenshot that most often turns to mush, and text sharpness depends on the capture resolution, not your screen size. Rules that work:
- Decide the rendered width first, for example 800 pixels wide on a desktop template.
- Multiply by the device pixel ratio of the audience's dense screens, usually 2, and capture at 1600 pixels wide or more.
- Resize down to the render width in image editing rather than shrinking in HTML with
widthand a tiny file. - Enlarge the UI or zoom the browser before capturing if the interface renders small text.
The same principle applies to a retina display. A screen that reports a DPR of 2 and a CSS width of 1440 will give you roughly 2880 physical pixels. Capturing the browser viewport and exporting at the CSS width discards half the detail, which is why the result looks soft. Size the file for the highest-DPR display your design targets, then serve variants for lower densities.
Interpret DPI correctly
The DPI stamp in a PNG is metadata, not geometry. A 300 DPI PNG is not sharper than a 72 DPI PNG if both have the same pixel dimensions; the browser renders by pixels, not the DPI label. The number only matters when exporting for print:
| Target | What to set |
|---|---|
| Web display | Sharpen by pixel resolution, ignore DPI |
| Export for the physical size in inches at 300 DPI | |
| Marketing doc PDF | Match the source layout resolution |
So do not chase a high DPI number for the web. Provide enough pixels for the rendered width on dense screens, and the image is sharp.
Optimise the file
A screenshot is full of flat colour and repeated anti-aliased edges, which make it compress well despite being photographic:
- Convert to a modern format. A flat UI screenshot often beats PNG weight with WebP or AVIF while staying visually identical.
- Trim the excess: crop dead space, page margins and empty toolbars before export.
- Test quality at 80 to 85 percent for lossy formats; text tolerates little, so compare zoomed.
- Keep a source master (ideally lossless) so you can regenerate when the UI changes.
Publish for accessibility and correctness
- Give every screenshot a meaningful
altthat states what the image shows, not a generic label, and describe the state visible (see image SEO for the same principle). - Annotate in the surrounding text, or add arrows and labels in a vector overlay, rather than relying on a reader to decode an unmarked image.
- Keep every screenshot width aligned with the responsive slots you already ship, so the srcset pick serves the right size.
Panoramas of a whole page benefit from a static capture at each breakpoint. The SVG vs PNG article covers when a live vector illustration is a better choice than a screenshot of one.
When a sharp capture is not enough
If a screenshot always looks soft even at high resolution, the interface itself renders low-DPI text, or a browser zoom has rasterised fonts. Capture from an isolated browser window at the target zoom, verify in a private window at the rendered size, and only then accept the file. If the subject moves, a short recorded clip can be a better documentation tool than a frozen frame.