Guide
One sentence carries this whole page: every option except sending the full frame removes the chance of a mistake instead of covering one. A black box has to be drawn in the right place, at the right size, in the right mode, and then checked in the exported file. A capture that never contained the sensitive value has nothing to check. When both routes reach the recipient with the same useful content, the second one is not merely tidier - it is a different class of safety, because it cannot be got wrong later by a tool, a re-encode or a technique that did not exist when you sent it.
The reason this needs saying is that the image usually is not a decision. It is the residue of a keyboard shortcut. Something needed explaining, the fastest key on the keyboard produced a picture of the whole screen, and from that moment on the only question anyone asks is how to redact it. The question upstream of that one - what should carry this information at all - never gets asked out loud.
Four ways to send the same information
For almost any message that currently has a screenshot attached, there are four vehicles available. They differ in what they carry, what they leak, and how much of the recipient's trust they can command.
1. The full frame, redacted. You send the capture you already have with the sensitive regions covered. It carries the most: the layout, the timestamps, the surrounding rows, the window chrome, whatever was in the other half of the screen. That is exactly why it is the highest-effort option to make safe. Everything in the frame has to be looked at, because anything you did not look at is published. It is the only option with a covered region, so it is the only one that can fail quietly - a cover that was too small, applied in a mode that preserved structure, or never applied because a tiny drag was discarded.
2. A narrower capture. You go back to the screen and take a new picture containing only the part that matters. There is nothing to cover, because the sensitive material was never in the frame. This is the option people skip, and it is usually the best one available.
3. A transcription. You type out the values or the wording the recipient actually needs. It carries the payload and nothing else: no background, no chrome, no adjacent records, no pixels at all. It is also the easiest thing for the recipient to use, because they can search it, copy it and paste it into their own system. What it loses is the appearance of proof.
4. A statement. You describe what happened in a sentence or two without reproducing any verbatim content. This is right more often than it sounds, particularly when you are asking a question rather than submitting evidence, and it is the only option that leaks nothing at all.
Read down that list and two things change together. The amount of incidental content falls away, and so does the claim to be showing rather than telling. Choosing well means knowing which of those two you actually need.
The question that picks one: what is the image for?
Almost every attachment is doing one of three jobs, and each job points at a different vehicle.
Transmitting a value. An order number, an error code, a price, a delivery date, the exact wording of a sentence someone sent you. Here the image is pure overhead. It carries the value plus everything that happened to be on screen, and the recipient has to read a number off a picture rather than copy it. Type it. If the frame around the value adds nothing to the message, it is not context, it is exposure.
Evidencing that a system displayed something. The screen said the payment went through; the app showed the appointment at that time; the listing said that price before it changed. Here the picture is the point, because your typing is your account of it and the image is closer to the thing itself. Send the image, redact it properly, and be honest that how much weight a screenshot carries is up to the recipient, not to you.
Showing something inherently visual. A rendering bug, a layout that collapsed, damage to an object, a chart, a state you cannot describe in words. An image is genuinely required. But this is also the job where the frame can most often be narrowed, because the visual thing you need to show usually occupies a small part of what you captured.
There is a fourth case that deserves its own answer: the recipient asked for a screenshot. Ask them what they need to see. Requests for screenshots are frequently shorthand for give me the details, made by someone who assumed that would be easier for you. When the request is literal, honour it. When it turns out they wanted the reference number, you have just avoided sending an entire screen to a queue you cannot see into.
If you can still reproduce the view, re-capture instead of covering
This is the recommendation with the best ratio of benefit to effort in the whole of redaction practice, and it is the one nobody follows, because by the time you are thinking about privacy you already have a file open and covering things feels like progress.
What re-capturing looks like in practice:
- Open only the record you need instead of photographing the list it sits in. One row beats nine rows and a search box.
- Shrink the window so the relevant panel is most of the frame. A narrow window makes a narrow capture without any cropping decision.
- Capture one window or a selected region rather than the whole screen, if your system offers that - most do, though the shortcut differs, so check yours.
- Collapse the furniture. Sidebars, member lists, bookmark bars, open tab titles, status bars, and anything that renders the signed-in account name. In many apps the single most identifying pixel on screen is the corner that says who you are.
- Quiet your notifications first. A message preview sliding in at the moment of capture is a classic accidental disclosure, and it is someone else's content, not yours. Most systems have a do-not-disturb mode; turn it on for the ten seconds you need.
- Clear the search field and the address bar if what you typed to get there is itself revealing.
- Use a view that does not contain your identity where one exists - a signed-out page, a public listing, a documentation page - when what you need to show is how something behaves rather than what your account holds.
The payoff is not aesthetic. A narrow capture has no covered region, so there is nothing to under-cover and no cover geometry to publish. There is no wider original that differs from what you sent, so there is no pair of files that can be overlaid against each other and no forgotten copy that contains what you removed. And it collapses the hardest part of redaction, which is not drawing boxes but noticing everything that needs one - a problem that scales with how much is in the frame. Finding everything that needs redacting before you start makes the same argument from the other end: a smaller frame is a smaller search, and the omissions that never get caught are the ones in the parts of a wide capture you never examined.
Two limits, both worth respecting. Do not re-capture when the state you need to show has already changed or cannot be reproduced - then you have the frame you have, and the job is to redact it well. And do not let a cleaner capture quietly become a weaker one: if the value of the image is that it shows your real account at a real moment, a version produced from a signed-out or demo view proves something different. Narrow the frame; do not swap the subject.
Transcription: when it is right, and the two costs
Typing the content out is the most underused option on the list, and the objection to it is always the same: nobody will believe me. Sometimes that is correct. Frequently it is a reflex.
Transcription is the right vehicle whenever the payload is text and the dispute risk is low. A delivery date to a colleague. A reference number to a support queue. An error string in a question to a forum. The quoted wording of a policy. In each of those the image would have delivered the same handful of characters wrapped in a picture of your desktop.
The first cost is provenance. The recipient sees your typing, not the system's output, and for anything contested that difference matters. The mitigation is not to pretend otherwise: quote exactly, say where the text came from and when you saw it, and add that you still hold the original and can supply it if needed. That last part is an argument for keeping the untouched capture in a place you control rather than deleting it in a burst of tidiness - offering it later is only possible if it still exists.
The second cost is fidelity, and it is the one people underrate. A transcription passes through your attention, and attention improves things. It fixes the typo in the error message, rounds the amount, tidies the wording, drops the field label that gave the number its meaning. Every one of those edits makes your account slightly less usable as a record. Copy rather than retype where you can, reproduce error text character for character, keep the labels attached to the values, and mark anything you are summarising as a summary.
Against those costs, put the thing a transcription does better than any image: the recipient can act on it. A number in a picture has to be read and re-typed by them, at their own risk of error, and cannot be searched for in their system a month later. A number in text can.
When the image really is required
Plenty of situations pass this test honestly. The rendering is the subject. A process requires the attachment. You need to evidence what a system said, to someone who may be disinclined to believe you. The recipient has asked for the screenshot and meant it. In those cases the editor above is the right tool and the rest of this site applies as written.
The decision still buys you something, though. Having asked what the image is for, you usually know that only one panel of it is doing the work, which turns a whole-screen redaction into a narrow capture with two covers on it. And it tells you what must stay legible: if a covered value is the one the recipient needs in order to act, an over-redacted image simply gets replaced by a hastier second one. Redacting for someone who already knows half the answer takes that further - your coverage should be calibrated to the widest reader the file plausibly reaches, with named exceptions for the values the immediate reader genuinely needs, and against a reader who holds the original the boxes themselves become the new information.
What the editor above can and cannot do for this
The tool on this page makes option one safe. It has no opinion on whether option one was the right choice, and it cannot give you back the material a wider frame contained. A few specifics about how it behaves, read from its own code, matter once you have decided that an image is what you are sending.
A fresh capture can go straight in from the clipboard. The page listens for a paste and loads the first image item on the clipboard directly into the canvas, so if your system can put a capture on the clipboard without writing a file, a re-captured narrow screenshot can be redacted and exported without a second file ever appearing in a screenshots folder. Whether your system offers a clipboard-only capture and which shortcut does it is an operating system question - check your own. The reason this is worth knowing on a page about re-capturing is that the usual objection to taking a second screenshot is that it creates a second file to account for.
Every export is a newly written PNG. Download hands back the current canvas as a freshly encoded PNG named with a timestamp, so tags the source file carried do not travel with it, and the button can be pressed as many times as you like in one session. Coverage is painted onto the working canvas, Undo steps back through saved snapshots, and Clear redraws from the original image the page still holds in memory.
The view is fitted; the file is not. The canvas is created at the image's true pixel dimensions while being displayed scaled down to the panel, inside a box that scrolls. Two consequences: text that looks like mush here is stored at full resolution and reads normally to anyone who zooms, and a tall capture can be exported with regions that were never on your screen during the session, because Download writes the whole canvas. Both are arguments for a narrow capture over a careful sweep of a wide one.
Small selections are discarded silently. A rectangle under about four image pixels in either direction, or an oval under six, is dropped rather than applied, and a freehand lasso needs at least three points. A quick tap over a short value may not have covered anything.
Solid fill removes structure; blur and pixelate transform it. Black Box paints a flat fill that does not depend on what was underneath. Blur redraws the region from a copy scaled down by a factor of ten and back up, and Pixelate averages into blocks sized at a twelfth of the region's shorter side with a floor of six pixels - both preserve coarse layout such as length, gaps and line count.
All of it runs on the device the image is already on: the page reads your file in the browser, draws it into a canvas, and hands the result back as a download. There is no account and no history for the picture to sit in, and the working copy exists only while the tab is open.
Common mistakes and misconceptions
Treating the screenshot as the cheap option. It is the cheapest thing to produce and the most expensive thing to make safe. The costs land in different places, which is why the trade keeps getting made badly.
Sending the whole screen because that is what the shortcut captured. The default capture region is a property of your keyboard, not of your message. Nothing about the situation asked for the other four windows.
Redacting a list when you needed one row. If nine of the ten rows have to be covered, the frame was wrong. Open the one record and capture that.
Typing the details and attaching the screenshot anyway, for completeness. Completeness is the failure. Once the values are in the message the image is adding only the parts you did not mean to send.
Believing a crop is the same as a narrower capture. A crop is an edit to a frame that already contained the material, and the wider frame usually still exists somewhere. A narrower capture never contained it.
Reading an attachment field as a requirement. A form that can take a file does not necessarily need one. Ask what the recipient needs to see before deciding that a picture is the answer.
Re-capturing from the same session and forgetting the furniture. The second capture is only narrower if you actually collapsed the sidebar, cleared the search box and hid the account name. Otherwise you have taken the same photograph twice.
Over-correcting into description when the visual is the evidence. If the recipient needs to see how something rendered, or that a system displayed a particular thing, a sentence about it is not a substitute. Send the image and cover it properly.
Assuming a narrow capture needs no review. It needs less, not none. Look at the edges of the new frame before you send it, because narrowing moves the risk to the margins rather than removing it.