Your Filename and Alt Text Can Leak What You Redacted

It helps to split disclosure into two categories. In-band disclosure lives inside the image file: the visible pixels, and the EXIF, IPTC or XMP tags embedded in the bytes. Out-of-band disclosure rides alongside the file in fields that no image editor can see or change. Covering the pixels closes the first channel. Stripping the tags closes the second. The third - text that you or your device wrote about the image - stays wide open unless you go and look at it on purpose.

The asymmetry is what makes this bite. Redaction is a deliberate, effortful act that you remember performing. Filenames are generated automatically; captions are typed reflexively while you are thinking about the request you are making, not about privacy. You will remember blacking out the address. You will not remember that your phone named the capture after whatever app was in the foreground, because you never typed that name.

The five text fields that travel with your image

1. The filename. It goes with the file when you attach it to an email, drop it into a ticket, add it to a repository, or share it in chat. Most systems store and display it verbatim.
2. Alt text or the description field. Written to describe the image for people using screen readers - which means a conscientious description is, by construction, a description of what you hid.
3. The caption or message body. The sentence explaining why you are sending the screenshot is very often a plain-text restatement of the redacted content. In practice this leaks more frequently than the filename.
4. The title of the container. Ticket subject, email subject line, shared album name, folder name, document heading, pull request title. The image sits inside something, and that something is usually named after the thing you are trying not to name.
5. The link preview. When a shared URL unfurls in a chat client, the preview text is assembled by the host from whatever it has - which on some platforms includes the uploaded filename.

Why screenshot filenames are worse than photo filenames

Camera photos are the easy case. A phone or a DSLR names captures with a neutral counter - IMG_4417.JPG, DSC_0031 - which says nothing about content. Screenshots behave differently. Operating system capture tools generally name files with a date and time, and on a number of Android builds and some third-party desktop capture utilities the name also includes the foreground application or window title. A “save as” or export from inside an application frequently inherits the document name instead. The result is that a screenshot you redacted carefully can still arrive named after the bank, the client, the case number, or the internal system it came from.

The reason a name is worse than it sounds is reach. Filenames are listed, logged and indexed in surfaces the image itself never reaches. An issue tracker shows attachment names in a table that a whole team scrolls past without opening anything. Mail clients show attachment names in the message list, next to the preview pane. Some content management systems pre-fill an image's title or description from the uploaded filename, and many build the public image URL directly from it - at which point the name is crawlable, quotable, and outlives the image you later swapped out. A black box protects the pixels from someone who opens the file. It does nothing for the twenty people who only ever saw the row in a list.

Alt text is the field literally designed to describe what you hid

Alt text exists so that someone using a screen reader gets the same information a sighted reader gets. That is a real obligation, not a nicety, and it collides head-on with redaction: good alt text describes the meaningful content of the image, and part of the meaningful content is the thing you just covered.

The way out is to describe the image's function in its context, not the data underneath the boxes. Three versions of the same alt text make the rule obvious:

Discloses: “Bank statement showing account 4521 with a $1,340 charge from Acme on 3 March.” Everything you redacted is now in a text field, indexed and quotable.

Useless: “Redacted image.” Safe, but it strands a screen reader user with strictly less than a sighted reader gets from the same picture.

Correct: “Bank statement with the account number and mailing address covered by black boxes; a single highlighted transaction line is readable.” It names what is visible, it names the fact that regions are covered, and it restates nothing that is underneath them.

The standard to hold yourself to is parity, not silence. Describe the redaction as part of the image, because it is part of the image now. If a field is genuinely decorative and carries no information, an empty alt attribute is the right answer so assistive technology can skip it - but a redacted screenshot attached to a support ticket is never decorative.

A pre-send checklist

1. Redact the pixels first and export. Do not write any surrounding text until the image is final, so you are describing the redacted version rather than the one in your head.
2. Rename the file to something that describes its role, not its contents: statement-redacted.png, not statement-acct-4521-redacted.png. Note that “redacted” in a name is itself a small signal that something sensitive is inside.
3. Read your caption back as if you had never seen the image. If the caption alone tells a stranger what is under the black box, rewrite it.
4. Check the container title - the ticket subject, the email subject, the album name. This is the field people forget most reliably because it was written before the image existed.
5. Fill in alt text deliberately rather than letting a system generate it from the filename. If the platform pre-filled it, overwrite it.
6. Attach the file by browsing to it by name, so you can see the name you are actually sending instead of the one you meant to send.

What the tool on this page does and does not fix

HideShot's export is written to a generated name of the form hideshot-<timestamp>.png, so the name of the file you opened is not carried into the file you download. The export is also re-encoded from the canvas pixels into a new PNG, which means tags embedded in the source file are not copied into it. Both of those close real leak paths, and both happen on your device - the image is read from disk into a local canvas and the PNG is produced by your own browser.

What it cannot do is reach into the destination. Alt text, captions, ticket subjects and album names live in whatever system you are sending to, and they are yours to check. It also cannot stop you from renaming the download back into something revealing on your way to the attach dialog, which is a surprisingly common way to undo the protection you just got for free.

Common mistakes and misconceptions

“The image is redacted, so the name is irrelevant.” The name reaches a wider audience than the image does, because listing a file is cheaper than opening one.

Writing the caption before finishing the redaction. You end up describing the original. Redact, export, then write.

Trusting an auto-generated description. If a platform derives alt text or a title from the filename, a revealing filename propagates into a second field - and now you have two to clean up instead of one.

Assuming deletion is retroactive. Replacing an image usually does not retract the filename from mail listings, notification emails, audit logs, or a URL that was already crawled. The name is the part that persists.

Using “redacted image” as alt text and calling it accessible. It is not. It is an empty field with extra steps, and it fails the people the field exists for.

Checking the filename but not the folder. Shared drives and albums carry their own names, and a file called scan-01.png inside a folder named for a client discloses just as effectively.

None of this replaces the pixel work. If you have not confirmed the cover itself holds up, do that first - redacting a screenshot for a bug report or support ticket walks through the attachment case end to end, and the metadata page covers the tags inside the file. This page is the third pass: the text you wrote around it.