Review each third-party screenshot as a separate publication asset. Record where it came from, what the book uses it to explain, what permissions or applicable terms have been checked, and whether it exposes information that should not be published. A screenshot’s usefulness or online availability does not by itself establish that the proposed use is cleared.
Identify the screenshot and its intended purpose
Give each proposed screenshot a stable identifier and record the exact file being considered. Note the application or page shown, the date captured, and the lesson it supports. This makes it possible to distinguish the selected asset from an older version or a visually similar image copied from another source.
Write down why the screenshot is needed. It may show the location of a control, illustrate a result, or help readers recognize a stage in a process. That purpose guides the editorial review and helps determine how much material is relevant. A decorative screenshot with no teaching role creates extra review work without necessarily improving the reader’s understanding.
Establish the source and the basis for the proposed use
Determine whether the image was captured for the project, supplied by a contributor, or obtained elsewhere. Preserve relevant correspondence, permissions, or official usage guidance that the project relies on. Keep the actual scope of that evidence visible, including any limitations that affect the planned publication. Do not treat an unrelated approval or a general attribution line as proof of permission for this use.
KDP’s content guidelines place responsibility for respecting applicable rights on authors and publishers. They do not provide a universal clearance rule for every screenshot. If the basis for using a particular asset remains uncertain, resolve that question through the appropriate rights holder or qualified review before marking it approved. Keep this decision separate from whether the screenshot accurately illustrates the software.
Inspect everything visible inside the capture
Review the screenshot beyond the control or result the lesson discusses. It may contain account names, messages, file paths, customer records, or other information that was incidental to the capture. Use a project-appropriate demonstration environment where possible and inspect the final asset for details that do not belong in a public book.
Also identify third-party content appearing inside the interface, such as images or documents opened during the demonstration. The application frame and the material displayed within it can raise different questions. A record describing only the software vendor may leave important content unexamined. Note the visible elements and resolve relevant issues before the screenshot becomes embedded across multiple draft files.
Keep edits connected to the original and the lesson
If the screenshot is cropped, annotated, or redacted, preserve the source capture and identify the edited version. Explain what changed and why. This allows a reviewer to evaluate whether the image still represents the workflow accurately and whether the publication file contains the intended final asset rather than an unreviewed earlier copy.
Do not assume that cropping or adding annotations automatically resolves a rights question. Those are editing decisions whose acceptability depends on the applicable circumstances and terms. Review the teaching effect separately: an annotation should identify the relevant element without implying that the software itself displays the added label. Make the distinction clear enough for readers to understand what they will actually see.
Match the screenshot to the instruction and software context
Compare the screenshot with the accompanying steps. Check names, visible states, and the result described. An image from a different version or account configuration may still be useful, but the book must explain relevant differences accurately. Do not invent a universal interface from one captured environment or let an old screenshot contradict newly revised instructions.
Keep the software context in the asset record so later updates can identify what needs another check. A rights review does not establish technical accuracy, and a successful workflow test does not establish rights clearance. Maintaining those decisions separately makes the release review more understandable and prevents one favorable check from being used as evidence for another question it did not address.
Approve the exact asset that enters the release
Before export, reconcile the screenshot register with the manuscript. Confirm that each retained image has a resolved review status, that its caption matches the accepted version, and that replaced captures are no longer used. Inspect the exported file because embedded assets can differ from the files currently visible in a working folder.
Save the approved screenshots, source records, relevant usage evidence, and review notes with the release package. If an image is later replaced, repeat the applicable checks for the replacement rather than transferring approval automatically. This process gives the author a practical way to manage screenshots as publication assets while keeping rights, privacy, accuracy, and editorial purpose visible as distinct responsibilities.
Frequently asked questions
Clear answers for this publishing decision.
Does taking the screenshot myself settle every rights question?
No. Review the proposed use and the material visible within the capture. Preserve the applicable evidence rather than assuming that operating the capture tool clears everything shown.
Does cropping or adding a credit automatically make a screenshot usable?
Do not assume so. Check the applicable basis for the use and any relevant limitations. Editing and attribution are not universal substitutes for resolving rights questions.
What should be reviewed when replacing an old screenshot?
Check the new asset’s source and usage basis, visible information, correspondence with the instructions, and final exported appearance. Approval of the previous file does not automatically cover the replacement.
What must I check, disclose, and verify myself when AI helped produce the book?
Review facts, rights, and source material yourself, record which parts were AI-assisted or AI-generated so you can answer Amazon’s disclosure question accurately, and treat every automated check as a starting point rather than a verdict.
See what the compliance checks cover