Guide
One sentence carries this page: a cover removes a region, so it can only remove things that are in a region. Some of what identifies a picture is not in a region. It is a property of the frame as a whole, or it is distributed across exactly the parts you are deliberately keeping visible, and no amount of careful boxing touches it.
This is not sloppy redaction and it is not a sweep you failed to do. You can identify the problem precisely, understand it completely, and still find that the tool in front of you has no operation that applies to it. The response has to come from somewhere other than the editor.
Values have edges. Properties do not.
The useful split is between a value and a property.
A value is a thing the picture contains. An account number, a name, a face, a door number, a QR code. It occupies pixels, those pixels have a boundary, and replacing them with a flat fill genuinely removes it. Every technique page on this site is about values, and for values the technique is the whole answer.
A property is something the picture is. Its dimensions. Its colour cast. The style of the prose inside it. The particular combination of software visible in it. The fact that its menus are in one language and its date format follows one convention. You cannot point at where the property is, because it is not anywhere - it is a description of the whole thing, or a pattern spread thinly over everything.
The test is simple and it is worth running explicitly on anything that is worrying you: if I drew a box around this, what would I draw it around? If you can answer, it is a value and you have a tool. If the honest answer is "all of it" or "the bits I need to keep", it is a property and the tool will not help.
The trap is that properties often masquerade as values. It feels like the identifying thing in a chat screenshot is the name at the top, because the name is a value and values are what we have learned to look for. The name is the easy half. The hard half is the six messages of prose beneath it, which are the reason you are sharing the image.
The families worth knowing
These come up repeatedly. None of them is exotic.
1. Writing style. In a chat, email or comment screenshot, the text is the payload, so it stays visible by definition. But prose carries identity independent of the name attached to it: sentence rhythm, punctuation habits, characteristic openings and sign-offs, whether someone writes in one block or in six short bursts, particular phrasings they reuse. How much this gives away scales with how much text is visible and how well the reader already knows the person, so it ranges from nothing at all to immediate recognition. It has no bounding box, because the box would be the content.
2. Your software configuration. A desktop or browser screenshot shows a set of choices: theme and accent colour, font rendering, taskbar contents, sidebar order, which browser it is, which extensions put icons in the toolbar, whether you run some unusual little utility most people have never heard of. Each item is a region, technically. The identifier is not any item, it is the combination - and you cannot box a combination without boxing everything in it.
3. The physical screen. On a photograph of a screen, or on a device screenshot that captures its own rendering quirks: a dead or stuck pixel, a crack pattern, a scratch, a bubble under a screen protector, a colour cast or brightness profile, dust in a consistent pattern. A crack in particular is close to unique and it runs across the whole frame. You can lasso it, but you will be lassoing a third of the image.
4. Locale and formatting. Interface language, keyboard layout hints, currency symbol, date order, twelve versus twenty-four hour clock, decimal separator, units. Individually these are weak - they narrow you to a region of the world rather than to a person. Collectively, and in combination with anything else on this list, they cut the candidate set hard. And they appear in dozens of small places at once: the clock, the menus, every date in every row.
5. Frame geometry. The pixel dimensions of the file, the aspect ratio, the rendered scale, whether a scrollbar is present and how long its thumb is, whether the window is maximised. These describe your display and your habits. This one is a genuine property of the file rather than of its content - which is why, unlike everything else here, no drawing operation of any kind can touch it.
6. The shape of the data. Cover every value in a table and you still publish how many rows there are. Cover every message and you still publish how many there were, how long each one was, and how they clustered in time. Cover the numbers on a chart and the curve remains. Blur and pixelate are especially weak here, because they are explicitly structure-preserving: they destroy samples while keeping length, spacing and line count intact. A column of pixelated values still announces how many values and how long each one was.
Some of these overlap with ordinary background leakage - a poster on the wall, a letter on the desk, a view through a window. Those are values, they sit in regions, and redacting background info that can doxx you is the page for them. The families above are what remains after you have done all of that correctly.
Nothing on the list identifies you. The list does.
This is the part that makes edgeless identifiers genuinely harder than the region kind, and it is worth stating plainly.
Take any single property and it looks harmless, and it is harmless. Millions of people use that operating system. Millions use that theme. Millions have their clock in that format. Millions have a window roughly that size. Assessed one at a time, every item fails to be a problem, so every item survives the review - and reviewing one at a time is exactly what a region-by-region sweep trains you to do.
But identification does not work one attribute at a time. Each weak attribute divides the set of people the picture could belong to. A common operating system might halve it. A distinctive theme might cut it by a lot more. An unusual app in the dock, a particular font, an uncommon window size, a locale, a crack in a specific place - stack six or seven of those and the surviving set can be very small, even though no single one of them was worth mentioning. This is ordinary reasoning about combinations rather than anything exotic, and it is the reason "none of this is sensitive on its own" is not a defence.
Two practical consequences follow. First, the decision cannot be made per-item; it has to be made about the set. Second, effort should go to the rarest attributes rather than the most obviously personal ones, because rarity is what does the narrowing. A default-looking window on the most common system in the world is camouflage. A heavily customised one is a signature.
Rarity is measured inside the reader's candidate set
Rare compared to what? Not compared to the whole world. Compared to the set of people the reader would plausibly consider.
If you post a screenshot publicly and nothing narrows it, the candidate set is enormous, and even a fairly unusual configuration may not pick you out. If you post it inside a community of two hundred people who know each other, the candidate set is two hundred, and an unusual setup very likely identifies you within it - possibly to people who have seen you share your screen. If you send it to one colleague who has sat next to you, the candidate set is one and every property is redundant.
That last case matters because it cuts both ways. Against a reader who already knows the frame is yours, none of this is a leak at all - you are not telling them anything they do not have. Fretting about your desktop theme in a screenshot sent to your own team is wasted effort. The question is always the widest plausible reader over the file's whole life, not the person you are sending it to right now.
So the test to run is: among the people who might see this, how many have a setup that would produce this exact combination of attributes? If the answer is "most of them", you are looking at camouflage and you should leave it alone. If the answer is "possibly only me", you have found the thing to act on - and, as the next section explains, acting on it almost certainly means not using this frame.
Why more covers make it worse, not better
The instinct on discovering a distributed identifier is to cover more. Box the taskbar, box the sidebar, box the clock, box the unusual icon. This goes wrong in three separate ways.
It destroys the picture. Properties are spread across the frame by definition, so covering them means covering large fractions of it. At some point the recipient can no longer tell what they are looking at, replies asking for a clearer version, and gets a hastier second image that is worse than the first one would have been.
It does not reach the worst cases. The prose in a chat screenshot cannot be covered without covering the message. The dimensions of the file cannot be covered at all. Structure survives every cover that is not a solid fill, and solid fills over the data are the same as not sending the data.
And the cover pattern is itself a property. A frame with nineteen black rectangles in a distinctive arrangement is a fairly specific object. The geometry of your covers maps what you considered sensitive, which is a statement about you, and a reader who has seen two of your redacted screenshots has seen your redaction style twice.
The conclusion is not that covering is bad. It is that covering is the wrong instrument for this class of problem, in the ordinary way that a hammer is the wrong instrument for a screw. Reach for a different one.
What actually works: change the frame, not the pixels
Every effective response to an edgeless identifier is a change to what gets captured, not an edit to what was captured. There are four, roughly in order of how often they are the right answer.
Capture less. This is the single highest-value move and it is almost always available. A property of the frame ceases to exist when the frame changes. Capture one window rather than the whole desktop and the taskbar, the wallpaper, the dock and every other application vanish - not covered, absent. Capture one region rather than one window and the title bar, the theme chrome and the window dimensions go with it. Open one record rather than the list it sits in. Collapse the sidebar. Clear the search box. Each of these removes a whole family at once, at no cost to legibility, and none of them requires a single box to be drawn.
Re-capture in a neutral state. Where the configuration is the identifier, produce the frame somewhere ordinary: a default theme, a fresh window at a common size, a profile without your extensions, default zoom. This is not redaction - it is re-rendering the same information from a surface that says less about you. It takes a couple of minutes and it is dramatically more effective than any amount of covering, because it removes attributes instead of hiding them.
Retype instead of showing. When the identifier is the prose itself, the only real fix is to stop shipping the prose. Paraphrase it, quote the one line that matters, or describe the exchange in your own words. This costs you provenance - typed text is not evidence that a system displayed anything - so it is the right move when you are conveying content and the wrong move when you are evidencing a display. When a redacted screenshot is the wrong thing to send works through that trade-off properly.
Normalise the geometry. If the frame size is a concern, set the window to a common size before capturing, or resize the exported file afterwards in a tool that does resizing. Note that this has to happen outside the editor on this page, which cannot change dimensions at all.
The ordering rule that falls out of all four: decide what to capture before you capture it. Once the picture exists, your options have already narrowed to editing, and editing is exactly the operation that does not work on properties.
When you cannot re-capture
Sometimes the frame is fixed. It is evidence of a state that no longer exists, somebody else sent it to you, or the system has since changed. Re-capture is not on the table and the advice above is useless.
What is left is honest triage rather than a fix:
- List the properties, then rank them by rarity within the likely audience. Most will be common enough to ignore. Usually one or two are doing nearly all the narrowing.
- Cover the rare ones specifically, using the lasso where the shape is irregular - a crack, a curved element, an odd-shaped icon cluster. Use the opaque mode, not blur or pixelate, because structure is precisely what you are trying to remove here.
- Leave the common ones alone. They are camouflage and covering them costs legibility for nothing.
- Narrow the audience instead of the image. If the properties cannot be removed, reduce the number of people in a position to match them. This is a real control and it is often the only one available.
- Say what the residual risk is if you are handing the image to someone who will decide what to do with it. An uncoverable identifier that the recipient does not know about is worse than one they do.
Notice that none of these claims to solve the problem. That is the honest position. A property of the frame is not removable by an operation on a region, and a page that told you otherwise would be selling you something.
What the editor above does and does not do
Everything here is read from the page's own code, and it is worth being exact, because the limits are the point of this page rather than an embarrassment.
It is region-based, completely. Three modes - Black Box, Blur, Pixelate - and three selection shapes - rectangle, oval, lasso. Every single operation takes an area you indicate and replaces the pixels inside it. There is no crop, no resize, no rotate, no colour adjustment, no global filter and no whole-image operation of any kind. If the thing you want gone has no region, this editor has no move for it, and that is a statement about the shape of the problem rather than a missing feature.
The export has the same dimensions as the input. The canvas is created at the source image's width and height, and Download writes the entire canvas out. Your file comes back the size it went in. Where frame geometry is part of what identifies the picture, the fix has to happen before the file reaches this page, or in a separate resizing tool afterwards.
Black Box is the right mode for structure. It paints a flat fill of a single near-black value across the selection, and the result does not depend on what was underneath. Blur redraws the region from a copy scaled down by a factor of ten; Pixelate averages into blocks sized at a twelfth of the region's shorter side with a floor of six pixels. Both destroy samples, but both preserve coarse shape - length, spacing, line count, the outline of a curve. Since coarse shape is what most of the families on this page are made of, the structure-preserving modes are the wrong choice for them.
The lasso is the tool for irregular properties. A crack, a reflection, a scattered cluster of icons and a curved element are not rectangles. The lasso follows an arbitrary outline and needs at least three points to register; rectangle drags under about four image pixels, and ovals under six, are discarded silently with no error, so a quick tap over a thin feature may have done nothing at all.
Re-encoding removes what the file said, not what it showed. Download writes a fresh PNG from the canvas. A canvas holds pixels only, so tags carried by the source file do not travel into the export. Every property discussed on this page is visible content rather than a tag, so none of them are affected by that. Two different leaks; a save fixes one of them.
The preview is not the file. The canvas is displayed fitted to the panel inside a scrolling box, while the pixels are stored at full size. Something that looks like an unreadable smudge on screen may be perfectly legible to anyone who zooms the export, and a tall capture can be exported with regions that were never on your screen during the session.
Work is destructive, Undo restores. Coverage is painted onto the working canvas, Undo steps back through saved pixel snapshots, and Clear redraws from the original image the page still holds. All of it runs on the device the picture is already on: the page reads your file in the browser, draws it into a canvas, and hands the result back as a download. The working copy exists only while the tab is open.
Common mistakes and misconceptions
Treating anonymity as a sum of removed fields. The most common version. Every named value is covered, the frame is declared anonymous, and the configuration, prose and geometry that identify it just as well were never assessed because they were not fields.
Judging each attribute on its own. Every item passing the "is this sensitive?" test individually is exactly what the failure looks like from the inside. The narrowing happens in the combination, so the set is what needs judging.
Assuming blur or pixelate handles a distributed feature. Both are structure-preserving by design. Pixelating a column of values leaves the column, its row count and its value lengths; blurring a distinctive outline leaves the outline.
Covering the name in a chat screenshot and calling it anonymous. The name is the value and the prose is the property. You covered the easy half and kept the half that a reader who knows the person recognises on sight.
Boxing more and more of the frame when the covers are not working. If covering more is not converging, the thing you are chasing has no edges, and the next box will not be the one that fixes it.
Re-capturing on the same customised setup and treating it as a clean frame. A new capture with identical configuration carries identical properties. Re-capture only helps if something about the capture actually changed - a narrower region, a neutral profile, a default window.
Forgetting that the export keeps your frame size. Dimensions are not content, so no editing pass on this page or any other selection-based tool will alter them. If the size matters, change the window or resize afterwards.
Assuming re-encoding anonymises the picture. Saving a fresh file drops the tags the old file carried. It cannot drop anything that was drawn in the image, which is where every property on this page lives.
Worrying about properties against an audience that already knows. Against a reader who knows the frame is yours, none of this discloses anything. Calibrate to the widest plausible viewer over the file's life, then stop.
Covering so much that the image stops working. An unreadable picture gets a request for a better one, and the replacement is usually made in a hurry. A frame that was never captured wide is better than a wide frame heavily covered.