Guide
One sentence carries this page: a request for a redacted screenshot has to name the regions, because the person you are asking cannot know which parts of their own screen matter to you.
Why asking is a different job from redacting
Redacting is a visual task. You look at a frame, you find what should not be in it, you cover it, you check your work. Every skill involved is a skill of inspection, and all of it depends on being able to see the thing you are protecting.
Requesting is a specification task, and you have to do it blind. You are describing a frame you have never seen, to someone whose screen is laid out differently from yours, in a sentence they will read once. None of your inspection skills transfer. What matters instead is precision about two separate questions that people routinely collapse into one: what must be legible when it arrives, and what must not be in it at all.
Collapsing them is what produces the two standard failures, and they pull in opposite directions. Under-redaction is the famous one: they cover the card number and leave the full name, the date of birth, the postal address and the fourteen other rows of the statement, because the card number was the only thing that looked obviously secret. Over-redaction is just as common and gets discussed far less: they black out the error code, the reference number and the timestamp, because those look like identifiers, and now the screenshot proves nothing and you have to ask again. A second round trip is not a disaster, but it is a second capture, a second image in transit and a second chance for the first mistake.
Both failures have the same root. You asked a question that required your context to answer, and the person answering did not have your context. They do not know that the account identifier in the address bar is the thing you will use to find their record, or that the sidebar is showing other people's names, or that the only part of the screen you actually care about is a single error banner. There is nothing to fix in their judgement. There is something to fix in the question.
Name the region, not the rule
“Please redact any sensitive information before sending” is the default phrasing and it is close to useless, because it hands the hard part — deciding what counts as sensitive here — to the one person in the exchange who cannot decide it. It also reads as a disclaimer rather than an instruction, which is roughly how it gets treated.
The alternative is to say what you need to see and what you want covered, by position on the screen. Positions work because they do not require any judgement to act on:
“I need to be able to read the red error banner across the top and the time in the corner. Please cover the account menu in the top right, the list of names down the left-hand side, and the browser address bar.”
That sentence is longer than the vague version by about ten words and it does several things at once. It tells them that the error banner is load-bearing, so they will not cover it. It tells them that three specific regions are not, so they will. It gives them a way to check their own work before sending, which the vague version does not. And it quietly tells them something they did not know, which is that you care about the address bar — a region almost nobody thinks of as part of a screenshot, and one of the more reliable places for an account number or a session token to be sitting in plain view.
Two refinements are worth the effort when the stakes justify it. First, if you have seen this screen before — because it is your own product, your own form, your own portal — you already know its layout, so describe it from memory rather than in generalities. Second, if you are sending the request more than once, write it down once and reuse it. A request that works is an asset, not a one-off.
Ask for less capture, not just more cover
The strongest form of the request is not “cover more of it”. It is “capture less of it”. A region that was never inside the frame cannot be covered badly, cannot be recovered from the file, and cannot turn out to have been blurred rather than blocked. It is the only part of this whole problem that is not a judgement call.
In rough order of how much they reduce the exposure:
Ask for the value instead of the image. If what you need is an error code, a reference number, a date or the exact wording of a message, ask them to type it out. It is less work for them than taking and editing a screenshot, and it collects exactly the information you need and nothing adjacent to it. A surprising share of screenshot requests are really value requests with extra steps.
Ask for a window, not a screen. Most operating systems can capture a single window, and most people do not know the shortcut. Telling them — one clause, in the request — removes the taskbar, the notifications, the other open applications, the wallpaper and the second monitor in one move.
Ask them to zoom in or crop to the panel. A capture of one dialog box has a tiny fraction of the surface area of a full desktop, and every pixel outside it is a pixel neither of you has to think about.
Ask them to re-create it somewhere clean. This one is underused and it is often the best answer. If the view can be reproduced in a private browser window, a fresh profile, a demo account or with test data, the screenshot of the reproduction carries no real data at all, and nobody has to redact anything.
Only when none of those work does the conversation become about covering regions — and by then the frame is much smaller, so the covering job is smaller too.
One thing to discourage explicitly: a photo of a monitor taken with a phone. It is what people reach for when the screenshot shortcut feels like a hassle, and it is worse on every axis. It captures the room behind the screen, the desk, whatever is reflected in the glass, and it typically arrives at an angle and a resolution that make the part you needed hardest to read and the parts you did not need perfectly legible.
Say how to cover it, in one clause
Left to themselves, most people blur. It feels proportionate — softer than a black block, less like destroying evidence — and on small text it is frequently not enough. The same goes for pixelation at a coarse-looking but recoverable block size. You will not be able to tell from the arriving image whether the blur was strong enough; you will only be able to tell that it was blurred.
So specify it: “use a solid block rather than a blur — blurred text often stays readable”. One clause, and an entire category of failure stops arriving. It is also the single easiest part of the request for the other person to comply with, because a solid block takes no skill and no judgement at all.
Give them somewhere to do it, too. “Please redact it” implies finding software, and a non-trivial number of people respond to that by giving up and sending the raw screenshot with an apology. A link to a single page that opens and works is a much higher-compliance ask than an instruction to go and acquire a capability. What you should not do is ask them to install anything, create an account, or sign in to something to carry out a favour for you.
A request you can paste
Adapt the specifics; keep the order, because the order is doing work. What you need to see comes first, so it does not get covered. How little to capture comes before what to cover, because reducing the frame reduces the covering job.
“Could you send me a screenshot of the error? Two things that would help: if you can, capture just the dialog box rather than the whole screen (on Windows that's Alt plus Print Screen, on a Mac it's Shift-Command-4 then Space). I need to be able to read the error text and the time. Please cover your name and email in the top-right corner and anything in the address bar — a solid block rather than a blur, since blurred text is often still readable. If it's easier, you can do that at hideshot.com, which runs in the browser with nothing to install.”
Four sentences. It names what must survive, shrinks the frame, names three regions to cover, specifies the method, and removes the tooling excuse. Nothing in it asks the recipient to decide what is sensitive.
When it arrives over-exposed anyway
Sometimes it will. The handling rule is to stop before replying, because replying is how a single over-shared image becomes several. Do not forward it, do not quote it into a thread that has more recipients than the original, do not drop it into a shared channel to ask a colleague whether it is a problem, and do not attach it to an internal ticket where it will be indexed and retained.
Then delete it from wherever it landed, if your systems allow that, and ask again — naming the specific region that was the problem, not the category. “The list of names down the left” gets a better second attempt than “personal data”. Keep the tone flat and procedural; people who have just over-shared tend to either apologise at length or get defensive, and neither of those produces a better second screenshot.
Resist the temptation to simply redact it yourself and move on. That produces a safe copy, which is useful if you have to pass the image on, but it does not undo the receipt — the original is already in your mail store, your attachments, your index and last night's backup. It also means nobody upstream learns that the request needed improving, so the same image arrives again next month. Whether an over-exposed image in your inbox triggers any logging or notification duty depends on who you are and what was in it, and that is a question for whoever owns that policy where you work rather than one this page can answer.
Channel matters as much as wording
A perfectly worded request sent in the wrong place still produces a bad outcome. Three cases worth watching for.
Public threads. If you are asking in a forum, a public issue tracker or an open community channel, the screenshot is not going to you — it is going to everyone, permanently, and usually into a search index. Ask for the redacted version there, or move the exchange somewhere private, or ask for the text instead.
Reply-all. An image attached to a thread goes to every current recipient and every future one, including whoever gets looped in next week. If the image needs to reach two people, start a new message to those two people.
Channels you cannot clean up. Before you ask anyone for an image, know whether you can actually delete an attachment from wherever it will land. If you cannot — and in plenty of ticketing and chat systems you cannot, at least not without an administrator — then the cost of a failed request is permanent, and that should push you much harder toward asking for a typed value rather than a picture.
Collect less, and the rest gets easier
There is a principle underneath all of this that is worth stating plainly, because it reframes the whole exercise: the cheapest data to protect is the data you never received. Every image that arrives in your systems is something you now have to store correctly, retain for the right length of time, produce if someone asks for their file, and account for if something goes wrong. A screenshot is an unusually indiscriminate collection instrument — it captures whatever was in the frame, including the things neither party was thinking about — and it arrives as an opaque blob that no automated process is going to review for you.
That instinct is also written into data protection law in some jurisdictions. The GDPR's second article of principle requires that personal data be, in its own words, “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed” — the principle it calls data minimisation. Whether that regulation applies to you depends entirely on your circumstances, and this is not legal advice about your situation. But the operational version needs no legal hook at all. Ask for the narrowest thing that answers your question. If a typed error code answers it, do not ask for a picture of the error code.
What the editor above is and is not suitable for linking
If you are going to point someone at a tool, it is worth knowing what they will find. The editor on this page is region-based: three modes — Black Box, Blur and Pixelate — across three selection shapes, rectangle, oval and freehand lasso. Every operation replaces the pixels inside the region drawn. Black Box fills it with a solid dark colour; Blur downsamples the region heavily and scales it back up; Pixelate replaces blocks with a single sampled colour. Undo steps back one cover and Clear restores the untouched image, so a nervous first-timer cannot wreck anything irreversibly. Black Box is the default mode, and selecting Blur or Pixelate raises a warning bar saying that those two may leave details visible — which is the same point your request should be making.
Download PNG writes the current canvas out as hideshot-<timestamp>.png, re-encoded from scratch rather than copied from the source file. It all runs in the browser: the image is decoded, edited and exported on the sender's own machine, and nothing is sent anywhere. For a request to a stranger that matters more than it sounds, because it means there is nothing to sign up for, nothing to install, and no second party involved in the favour you are asking for.
Two limits to know before you lean on it. There is no crop, no resize and no rotate, so if your request asks for a tightly framed capture, that has to happen in their screenshot tool, not here. And there is no automatic detection of faces, text or anything else — every cover is drawn by hand, which is precisely why your request has to name the regions rather than trust the tool to find them. If the person you are asking is sending a screenshot to a support queue, the sender-side version of this whole problem is laid out in redact a screenshot for a bug report or support ticket, which is a reasonable thing to link them instead.
Common mistakes and misconceptions
“Please remove anything sensitive.” The most common wording and the weakest. Sensitivity is relative to your system and your purpose, and the person reading the request has neither. It also reads as a liability disclaimer rather than an instruction, which is how it gets treated.
“I'll ask for the full screen just in case, and ignore what I don't need.” You cannot ignore it. Once it is in your mail or your ticket it is stored, retained, indexed, backed up and potentially disclosable, whether or not you looked at it. Asking for more than you need converts their screen into your liability.
“They redacted it, so it is redacted.” They probably checked their editor's preview rather than the saved file, and they almost certainly did not zoom in. If the cover is a blur over small text, assume it may be readable until you have looked at it closely yourself.
“A blur is fine, it is only a name.” Blur strength is not visible in the result. You will see that something was softened; you will not see whether softening it was sufficient. Specify a solid block and the question never comes up.
“I'll just redact it myself on the way in.” That protects onward recipients and does nothing about the copy you already hold. It also hides the problem from everyone upstream, so the request never improves.
“Asking twice looks incompetent.” A clarifying question before the capture costs one message. An over-exposed image costs a deletion you may not be able to perform, a conversation you did not want, and sometimes a disclosure you have to report. Ask the question.
“It's a photo of their own screen, so it's their risk.” It stops being only their risk the moment it reaches you. From then on you are the one storing it, and you are the one who has to explain it if it goes somewhere it should not have.
“They know their own screen better than I do.” They know the layout better. You know which fields are identifiers in your system, which values are reusable, and what you will do with the image next. Neither of you has the whole picture, which is exactly why the request has to carry your half of it.