A Screenshot Redaction Review Before Publishing a Software Tutorial

Tutorial screenshots are easy to take and easy to get wrong. Even when you use a dummy account, a capture can reveal things you did not plan to share: an address bar, a notification, a browser extension, a token in a settings page, a file path with a real name in it. This article proposes a review you can run on every frame before publishing. It is an original suggestion and every example is hypothetical.

Start with the capture, not the edit

The cheapest redaction is the one you do not need. Before capturing, consider:

• Use a clean browser profile with no extensions or bookmarks bar.
• Turn off notifications for the session.
• Use a dedicated dummy account whose name and address are obviously fake.
• Capture only the region you need, not the full screen.

Still review afterwards, because habits slip.

The clearance sheet

Create one row per frame. Number the frames in the order they will appear. For each, check every column:

Mark each cell clear, redacted or not applicable. Never leave a cell blank.

What to look for in each column:

• Address bar: session identifiers, invitation links, internal host names.
• Account details: dummy names that are still reused elsewhere, or a real name slipped in.
• Secrets: API keys, one-time codes, password fields shown in plain text, recovery codes, anything pasted into a field.
• Notifications and tabs: titles of other tabs, message previews, calendar pop-ups.
• Paths and file names: the user folder name in a path, project names.
• Metadata: embedded information in the image file or in a screen recording's file properties.

How to redact

Solid blocks that fully cover the area work better than blur, because blur may be partly reversible and the original pixels may remain in layered files. Flatten the image, export a new file, and keep the original separate and private. Never publish the original or the layered working file.

If a frame needs redaction in more than a couple of areas, consider retaking it with cleaner data instead.

Branching choices

If a secret appeared in any frame, treat that secret as exposed in your own records, even if you redacted the image, and consider replacing it. If the dummy account name matches a real person or business, retake. If a frame is only decorative, consider deleting it.

For video tutorials, step through frames rather than watching at normal speed, since a notification can flash for a moment.

Hypothetical worked example

Imagine frame 07 shows a settings page with a masked token field and an address bar showing a draft preview link. The masked field is fine. The link is not. The reviewer records address bar as redacted with a solid block, and also notes that the draft link exists, so it gets disabled in the system. Frame 12 shows a download folder path with a real first name. The team retakes it with a generic account folder.

Stop conditions

Do not publish if any cell is blank, if the clean original has ended up in the public folder, if a secret appears in any frame and no one has decided what to do about it, or if only the person who took the screenshots has reviewed them.

Acceptance checks

• A second person reviews each frame without having captured it.
• The exported files are opened fresh, zoomed in, and inspected for faint or leftover text.
• Metadata has been checked on the exported files.
• The sheet is kept with the tutorial, and any later edit sends the affected frame back through it.

Sources