Guide
One sentence carries this page: a published redaction has to be perceivable both by readers who cannot see the image and by readers who cannot resolve it, and the field that serves the first group is the field most likely to leak.
Three readers, not one
A private redaction has a single reader whose eyes you can more or less assume. A published one has at least three, and they want incompatible things.
The reader who sees the image. They see a mark, infer an absence, and read around it. Everything this site normally worries about applies to them: whether the value is recoverable, whether context gives it away, whether the shape of the mark is itself informative.
The reader who never sees the image. A screen reader user receives your text alternative and nothing else. This is worth stating clearly because it cuts both ways. Covering pixels is genuinely effective against assistive technology — there is no hidden text layer in a PNG and nothing in the covered region for any reader, human or software, to recover. That also means the text you wrote is the entire channel. If it is thin, you have published an image that works for one audience and not the other.
The reader who sees the image but cannot resolve it. Low vision, magnification at 200% or 400%, colour vision deficiency, a glossy phone screen outdoors, a platform-level contrast filter. For them the mark either registers or it does not, and if it does not they read a partial image as a complete one and quietly draw the wrong conclusion.
The tension between the first two is the thing that makes this its own problem. The most informative alt text you could write is the most disclosive. There is no setting to toggle; it is a judgement, and it has a reliable shape.
The text alternative has to do two jobs at once
The resolution is to describe the category and the purpose, never the content. A pattern that works has four parts: what kind of document or screen this is, what has been covered expressed as a type of field, what remains legible, and why the image is on the page.
So: utility bill from a named supplier, with the account number and the service address covered by black boxes, and the billing period and the total legible, shown as an example of the layout. A screen reader user now knows what the image is, that something was withheld, roughly what kind of thing it was, what they are not missing, and why it is there. No value appears anywhere in it.
Both failure modes are common. Naming the value — statement showing account 4521 — is a disclosure, and it lands in a field that is machine-readable, indexable and reproduced in search snippets, which makes it worse than the same slip in body prose. Writing only redacted image is the opposite failure: safe, useless, and a reader using assistive technology ends up with strictly less than everyone else. Parity is the target, not silence. The disclosure side of the same field, including the other text fields that travel with an image, is worked through in filename and alt text can leak what you redacted.
Empty alt is a claim, not a safe default. Success Criterion 1.1.1 has an explicit exception: if non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented so that assistive technology can ignore it — which in HTML is alt="". Applying that to a redacted screenshot is almost always wrong. You covered something because the picture carries evidence, and evidence is not decoration. If an image really is decorative, the honest move is to remove it, because then nobody has to rely on your redaction being perfect.
Put the long version where it can be long. If the detail will not survive a sentence or two, write a visible caption or a paragraph beside the image and keep the alt attribute short. One caution: a caption is more public than an alt attribute, not less. The non-disclosure test does not relax because the text moved.
The mark itself has a contrast requirement
This is the half people never think of as an accessibility question at all. WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast, a Level AA criterion, requires a contrast ratio of at least 3:1 against adjacent colours for “Graphical Objects — parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.” A redaction mark is squarely a part of the graphic required to understand the content. Miss it and you misread the image as complete.
Run the numbers on the mark this editor actually draws. Black Box fills your selection with flat #111111. Computed with the WCAG relative luminance formula, that gives roughly:
18.9:1 against white · 17.3:1 against this page’s own background · 1.6:1 against a mid-dark chat interface · 1.3:1 against a dark code editor surface · 1.1:1 against a near-black panel · 1.0:1 against a very dark interface background.
On a light capture the mark clears the threshold with six times the margin it needs. On a dark capture it fails it by a factor of two or three, and it fails it silently, because the pixels really are gone and the export really is correct. The editor draws the fill and never strokes an outline around it, so there is no border to rescue the mark either. The practical options are to re-capture the screen in light mode, to frame the capture so the mark sits against a lighter region, or to add an outline and a caption outside this editor. The legibility problem in its own right, including why your own eye is a poor judge of it, is covered in when a black box is invisible on a dark screenshot.
One clarification, because it is easy to over-apply the standard: you are not being asked to measure the contrast of the interface text inside the screenshot. Success Criterion 1.4.3 explicitly excuses text that is “part of a picture that contains significant other visual content” from its 4.5:1 requirement. The thing to measure is the mark you added.
What magnification does to each mode
Readers with low vision work at magnifications that make most people wince. Success Criterion 1.4.4 Resize Text asks that text be resizable to 200% without loss, and it specifically exempts images of text — so a screenshot is not obliged to scale gracefully. The consequence still lands on your reader, and the three modes behave very differently.
Black Box scales perfectly. A flat fill has nothing to resolve. At 100% or 400% it reads as a rectangle somebody drew on purpose, which is exactly the message you want carried.
Pixelate becomes conspicuous. The block size here is the shorter side of your selection divided by twelve, with a floor of six image pixels, each block filled with one sampled colour. Magnified, that is an obvious grid, so it reads as deliberate — while simultaneously being the condition under which the surviving per-block colours are easiest to read as structure. Legible as an editorial act, weakest as concealment.
Blur reads as a fault. It is a fixed factor-of-ten downsample of your selection scaled back up with low-quality smoothing. Under magnification a soft region looks like a loading state, a compression artefact or a half-broken image, and readers interpret it that way. A mark mistaken for a defect has not communicated that anything was withheld.
That last point is an accessibility failure that is entirely separate from whether the value is recoverable. For an image you are publishing, it argues for the box on grounds that have nothing to do with security.
Do not let colour carry the meaning
Success Criterion 1.4.1 Use of Color, Level A, states that “Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.” On redacted images this bites in one specific situation, and it is a situation that shows up in exactly the documents most likely to have an accessibility obligation attached.
If you are publishing a report where different marks mean different grounds for withholding — personal data here, commercial confidence there, a third party’s information somewhere else — and you encode that in colour, the distinction vanishes for a colour-blind reader, for anyone printing in greyscale, and for anyone whose platform is applying a colour filter. Carry the distinction in text instead: number the marks and state the key in the caption, or use visibly different mark shapes and say which is which. This editor cannot draw a legend, a number or any other text, so that key belongs in the surrounding page rather than in the pixels.
A related caution worth stating as a caution rather than a fact: platform-level display adjustments such as inverted colours, increased contrast and colour filters change how any mark reads, and the behaviour varies by platform and by whether the adjustment is applied to images at all. Do not reason about it from first principles. If your audience includes people who use one, turn it on and look.
A pre-publish checklist
1. Ask whether the image is needed at all. Success Criterion 1.4.5 Images of Text asks that text be used rather than images of text where the technology allows, with an exception where “a particular presentation of text is essential to the information being conveyed.” A capture showing a specific interface state usually clears that bar comfortably. A capture of a paragraph of prose does not, and publishing the prose as text removes the redaction problem rather than solving it.
2. Redact, then measure the mark against what is next to it. Not against the page background — against the pixels the mark actually touches.
3. Write the alt text. Document type, the fact of the redaction, the category covered, what remains legible, why the image is there. One or two sentences.
4. Write a caption if the detail matters, and apply the same disclosure test to it.
5. Re-read both purely for disclosure. Read them as an adversary would, not as the author. These two fields are the cheapest place to undo an otherwise careful redaction.
6. Rename the file. It travels with the image, it is frequently announced when alt text is absent, and screenshot filenames describe their contents more often than people remember.
7. Look at the published page at 400% and in greyscale. Both are one browser or operating-system setting away, and they catch the invisible-mark failure in seconds.
8. If marks carry categories, add the text key before the page goes out, not after someone asks.
What this editor does and does not do here
Regions only, nothing automatic. It covers rectangles, ovals and freehand shapes you draw. There is no text detection and no way to cover every instance of a value at once.
No text drawing of any kind. The editor contains no call that writes text to the canvas, so you cannot letter a box, add a legend, or number your marks. It also fills the mark path without stroking it, so there is no outline option. Everything textual — alt text, caption, key — is work in your publishing system.
The export carries no text fields either. The PNG is written from the canvas, so it leaves behind whatever titles, captions and EXIF the source file had, and it carries no alt text because an image file cannot. Attaching that is a separate step every time.
Always PNG. The download is a PNG named hideshot-<timestamp>.png whatever you opened. A JPEG in becomes a PNG out, which means the edge of your mark picks up no fresh compression ringing — a small point in favour of legibility.
No crop, resize or rotate. The canvas is created at the source image’s exact pixel dimensions and nothing alters them. A screenshot too wide to read on a phone is still too wide after redaction, and the fix is a narrower capture rather than a smaller mark.
Small covers fail silently. A rectangle drag under about four image pixels, or an oval under six, is discarded with no message, and a lasso needs at least three sampled points before it applies.
One file at a time. Loading the next image resets the undo history without a prompt, so download each finished PNG before moving on.
Nothing leaves the browser. There is no fetch, XMLHttpRequest or WebSocket call in the editor and no browser storage of any kind; the image stays in the tab and the PNG is written from the canvas on your own machine.
Your clipboard still holds the original. Pasting a capture in with Ctrl+V works, but there is no clipboard-write code, so pressing paste in your CMS afterwards attaches the unredacted image. Upload the downloaded PNG instead.
Common mistakes and misconceptions
“A screen reader might read the text under the box.” It cannot. Covering replaces the pixels and a PNG has no text layer. The real risk runs the other way: a reader’s own text-recognition or image-description feature will happily read everything you left visible.
“alt=”redacted screenshot” is fine.” It is safe and it is useless. The standard asks for equivalent purpose, and that is not it.
“Empty alt is the cautious choice.” Empty alt declares the image decorative. If the image is decorative, remove it; if it is evidence, describe it.
“The box is black, so obviously it is visible.” Against a very dark interface, #111111 computes to about 1.0:1. It is a mark only on light pixels.
“Accessibility and redaction pull in the same direction.” Not always, and the published case is where they collide: the most useful description is the most disclosive. Describing the category rather than the content is what resolves it.
“The caption is a safer place for the detail than the alt text.” A caption is read by everybody. It is the more public field, not the less.
“The tool should put a REDACTED label on the box.” It cannot — no text drawing exists in it. Nothing in the pixels will ever explain itself, which is precisely why the explanation has to live in your markup.
“Nobody actually zooms to 400%.” People do, routinely, which is why there are success criteria written about it.
“Passing the criteria is the goal.” The goal is that a reader who cannot see the image understands what the image was for and that something was withheld from it. Conformance is the floor under that, not a substitute for it.