Screenshots in Pentest Reports: Captions, Redaction and Size

Screenshots in a pentest report should each prove one point: cropped, redacted by removing the data, captioned with what they prove, numbered and kept small.

A screenshot earns its place in a pentest report when it proves one point the text cannot: cropped to that point, with secrets removed from the image rather than blurred, a caption saying what it proves, a figure number the text refers to, and a file size the document can carry. Most screenshot problems arise after capture: a crop that loses the hostname, a black box that lifts off, forty full-screen images that make the report too heavy to send, and a caption that says "Figure 12: Screenshot".

What a screenshot must show to count as evidence

A screenshot is evidence only if a reader who was not there can tell which system it shows, as which user, and what in it proves the finding. Keep three things in frame.

  • Where. The address bar, hostname or window title that places it on an in-scope system. A crop that cuts the URL asks the reader to take your word for which environment it was.
  • Who. The signed-in account, where the interface shows it, because an authorisation finding turns on which user saw the data.
  • The proof. The record that should not be visible, the payload that executed, the setting that is wrong, large enough to read.

Keep everything else out: other browser tabs, a bookmarks bar naming other clients, chat notifications, your desktop, and anything that tells the client more about your firm than about their system. A screenshot supports the captured request and response rather than replacing them, which evidence that survives peer review covers in full.

Crop to the proof, before it goes in

Crop each image to the smallest area that proves its point while still showing where it was taken. If one capture proves two things, make it two figures with a caption each. A full-screen capture shrunk to the width of a page turns interface text into something nobody can read in print, so capture less and show it larger.

Crop in an image editor, not in the document. Cropping a picture in Word hides the cropped area rather than deleting it: the whole original stays in the file unless the cropped areas are deleted when pictures are compressed. Anyone with the file can drag the crop back out, or unzip the document and find the full screen.

Redact by removing the data

Redaction has one test: the data is no longer in the file. Two common methods fail it. Blurred or pixelated text can be reversed, especially short strings in a known font, which describes many tokens and passwords. A black rectangle drawn over an image in Word or a PDF editor is a separate shape that can be moved or deleted, and the image underneath is untouched for anyone who extracts it.

Replace the pixels in the image itself with a solid fill, save the result as a new file and paste that. Handling evidence and client credentials safely covers flattening and where evidence is kept; what is specific to the report is checking the finished document.

  • Zoom in on every redaction at several hundred per cent in the final PDF. A fill that misses a few pixels leaves the tops and tails of characters, which can be enough to read a short value.
  • Look for the same secret elsewhere in the frame. A token covered in a cookie header may still show in the address bar, a tooltip or a response further down.
  • Give request and response text the same care. Pasted as text, they carry cookies, authorisation headers, API keys, passwords in form bodies and personal data. Replace each value with a placeholder such as [REDACTED] and keep the structure, so the reader still sees which header carried what. A value hidden by formatting, or left in a tracked change or comment, is still in the file.

Captions that say what the picture proves

A caption is a sentence of evidence, not a label. "Figure 7: Admin panel" tells the reader nothing they cannot see. "Figure 7: The administration panel at /admin, reached without signing in, listing every user account" says what to look at and why it matters, and it can be quoted in a ticket on its own.

Put captions under the image, in one style throughout, and introduce each figure in the text before it. Where the important part of a busy screen is small, mark it in the image itself with a box or an arrow in a colour that survives greyscale printing. A shape laid over the picture in the document can drift when the text reflows.

Number figures and refer to them by number

Number every figure and refer to it by number: "as Figure 7 shows", never "the screenshot below". Layout pushes images onto the next page, a reviewer moves a paragraph, and "below" becomes wrong, while a number stays right wherever the image lands.

Generate the numbers rather than typing them. In Word, captions inserted as caption fields, with cross-references in the text, renumber when the fields are updated; numbers typed by hand go wrong the first time somebody adds a finding in the middle. Choose one scheme, one sequence through the report or one within each finding, and keep it from report to report. If clients see findings before the report is final, decide how a figure number they have already quoted in a ticket stays the same when a new finding arrives ahead of it.

File size and resolution

A full-screen capture from a 4K monitor is usually 3,840 pixels wide, and high-resolution laptop screens are not far behind. Forty of those at full resolution can take a report to tens of megabytes: slow to open, slow to turn into a PDF and over some mail systems' attachment limits, though size is the least of the reasons for delivering pentest reports without emailing PDFs. The page cannot show that detail anyway.

Resize each image to the width it will take on the page before it goes in, rather than trusting each tool's compression settings. The text area of an A4 page with 2.5 cm margins is 16 cm wide, which at a generous 300 pixels per inch for print is about 1,900 pixels; an image at half the page width needs half that. Most cropped captures are already smaller and should go in at their own size, never enlarged.

Text needs a lossless format. Save screenshots as PNG: JPEG compression blurs the edges of characters and leaves halos around them, exactly where small interface text and terminal output stop being readable. Keep JPEG for photographs, such as a device in a physical test, and check the PDF export does not recompress screenshots as JPEG on the way out.

When screenshots belong in an appendix

The body of a finding needs the one or two figures that prove it. Everything else that supports it belongs in an appendix: the same misconfiguration on thirty hosts, every page of an exposed directory listing, a long run of enumeration results. In the finding, list the affected hosts in a table, show one representative screenshot and refer to the appendix by figure number for the rest. The finding stays readable and the evidence stays available. What a penetration test report should contain sets out what else the appendices carry.

Alt text and a line that carries the point

Reports get printed in greyscale, read on phones, opened with screen readers and pasted into ticketing systems that drop the images. Give every figure a sentence in the text that states what it shows, so the finding survives without the picture: "The response to user B's request contains user A's full order history (Figure 7)." Add alt text too, in Word's alt text field, describing what the image shows rather than repeating the caption. A PDF exported from Word with its accessibility tags kept carries the alt text with it.

In our free reporting tool and in the Portal, screenshots pasted into a finding's evidence land as images where you paste them, beside requests and tool output, and every figure is numbered and captioned. Explain evidence, from the AI, writes a line above each screenshot, request, block of code or output saying what it shows, and a caption under each screenshot, as a draft for a tester to keep, rework or discard. An Excel export of findings can add a figures tab indexing every figure with a link back to its finding. In the Portal, until a finding is shown to the client, its screenshots carry a Fig mark rather than a figure number, so writing or adding a finding never moves the numbers the client already reads. See our free reporting tool or what clients see.

Common Questions

What should a screenshot caption say in a pentest report?
What the image proves, not what it is. Name the system and the account, and state the observation: "Figure 7: The administration panel at /admin, reached without signing in, listing every user account" rather than "Figure 7: Admin panel". Put captions under the image in one style, number them, and refer to each figure by number in the text, so the point survives if the image is lost.
How do I reduce the file size of a pentest report full of screenshots?
Crop each capture to the area that proves the point, in an image editor rather than in Word, where the cropped area stays in the file. Resize to the width the image will take on the page: about 1,900 pixels covers the full text width of A4 at print resolution. Save screenshots as PNG, and move repetitive evidence, such as one issue on thirty hosts, to an appendix.
Should screenshots go in the body of a pentest report or an appendix?
In the body, only the one or two figures that prove each finding. Supporting volume goes in an appendix: the same misconfiguration on many hosts, long directory listings or runs of enumeration output. In the finding, list the affected hosts in a table, show one representative screenshot and refer to the appendix by figure number, so the finding stays readable and the evidence stays available.
How do I check screenshots in a pentest report are properly redacted?
Check the finished PDF rather than the draft. Zoom to several hundred per cent on every redaction, look for the same value elsewhere in the frame, such as the address bar or a response further down, and extract the images to confirm the data is gone rather than covered. Then search the request and response text for cookies, authorisation headers, keys and passwords that should have been replaced.

Keep Reading

Setup guide

See the product set up, end to end

The whole setup in 10:01, with chapters you can jump to: registering, your own domain, your own database in any of three places, your own mail server, branding, the first sign-in, updating the database on Supabase Cloud, and moving the database if you change your mind.

  • 0:00 · Registering, signing in, and the free trial
  • 0:44 · Your name and your firm’s name
  • 0:50 · Custom domain
  • +6 more