I shared a screenshot with sensitive info: what to do now
Short answer: do things in the order of what spreads fastest, not the order that feels natural. Revoke anything the screenshot unlocks first, because a live key or password is the part that gets worse by the minute. Then take the post down. Then work on the assumption that someone saw or saved it while it was up, and act accordingly. The instinct is to delete first because deleting feels like undoing, but deleting only removes your copy, and your copy was never the dangerous one.
First: kill what the screenshot unlocks
Anything in the image that grants access is the priority, because it stays dangerous only for as long as it stays valid, and you control how long that is. Before touching the post:
- API keys and tokens: rotate them now. A key in a screenshot is a key in the wild, and rotation makes the visible one worthless. The same logic is why hiding keys before sharing is framed as redaction being faster than revocation, but revocation is the tool you have after the fact.
- Passwords: change any that were visible, and anywhere else you reused them.
- URLs with tokens in them: invite links, password-reset links and signed share links are credentials wearing a URL costume. Regenerate or revoke them.
- Card numbers: freeze the card in your banking app and request a replacement. Freezing takes a minute and removes the urgency from everything else.
- Backup or recovery codes: regenerate the set. One visible code invalidates the assumption the whole set relies on.
Once the credential is dead, the clock stops. Everything after this point is about reducing exposure, not racing it.
Then take the post down
Now remove the image everywhere you put it. Delete the post, or edit it and strip the attachment if the words should stay. In chat, use the delete-for-everyone option where the platform offers one. In a ticket or an issue, replace the attachment with a cleaned version rather than just deleting, so the thread still makes sense and nobody re-uploads the original from their downloads folder to "fix" it.
Be realistic about what removal achieves. Platforms cache images, previews persist in notification trays and email digests, and anyone who had the thread open still has the pixels on their screen. Taking the post down closes the easy path for everyone who has not seen it yet, which is genuinely worth doing fast. It does not recall the copies that already exist, which is why the credential rotation came first.
Assume it was copied while it was up
The uncomfortable planning assumption: if it was visible, it was copyable, and you will never get confirmation either way. Public posts get scraped and archived by services you have never heard of, group chats get screenshotted by their quietest members, and the half-life of "I deleted it quickly" is shorter than it feels. The mechanics of why deletion only removes your copy are laid out in redacting screenshots before posting publicly, and they apply just as much after the mistake as before it.
This assumption is not cause for panic, it is what makes the rest of the checklist rational. You rotate credentials because someone might have them. You notify people because someone might have seen. Acting as if the window was zero is the only version of this that relies on luck.
What you cannot rotate
Credentials die when revoked. Personal information does not, so it gets a different playbook depending on whose it was.
| What leaked | What to actually do |
|---|---|
| Your own details | Change what is changeable and watch what is not. An email address in the wild means being sharper about phishing for a while; an account number means keeping an eye on statements. Mostly this is vigilance, not action. |
| Someone else's details | Tell them. What was visible, where, for how long, what you have done. They cannot protect themselves against a leak they do not know about, and hearing it from you beats discovering it. |
| Work or customer data | Tell whoever handles security or privacy, today. Most teams have seen this before and care about response speed far more than about blame. The bad version of this story is always the one where they find out later. |
Make the next one a non-event
Almost every leaked screenshot has the same backstory: the sharing was urgent, the redaction was a detour, and the detour lost. Nobody re-opens an editor when a colleague is waiting on the image. So the fix is not resolving to be more careful, it is making the redaction happen inside the capture itself. With ScrubShot the loop is: press the shortcut, drag the Scrub tool over anything sensitive to pixelate it irreversibly into the image, then copy and paste the cleaned version. The five seconds that would have prevented this entire checklist, every time, is the habit described in the privacy-first screenshot workflow, and the full picture of which redaction methods actually hold is in the guide to redacting screenshots on a Mac.
FAQ
- I deleted it within a minute. Am I fine?
- For a quiet post with a small audience, very probably, but treat the two halves differently. Personal detail seen by three followers for a minute is a near miss. A credential is not: an API key or password is cheap to rotate and catastrophic to leave live, so rotate it regardless of how fast the delete was. Speed shrinks the audience, it does not prove the audience was zero.
- Do I have to tell anyone at work?
- If the screenshot held work credentials, customer data or anything from an internal system, yes, and fast beats tidy. The person handling security would much rather hear about a leaked key that was rotated within the hour than discover it in a log three weeks later. A prompt, plain report almost always lands as competence, not carelessness.
- The screenshot showed someone else's details. What do I owe them?
- Tell them what was visible, where it was posted, for how long, and what you have done about it. It is an awkward message to send and the only honest move, because they cannot protect themselves against a leak they do not know happened. If it was their data in a work context, that is also the moment to loop in whoever handles privacy.
- The sensitive part was blurred or pixelated. Does that count?
- It depends entirely on how. A light blur or classic averaged-block pixelation over short text like a code or key should be treated as readable, because both can be attacked. A scrub that rewrote the pixels with blocks not derived from the content, which is what ScrubShot does, has nothing to recover, and that part of the screenshot is genuinely fine.
Try it
ScrubShot exists so this page never applies to you again: press the shortcut, scrub the sensitive parts straight into the image, and the cleaned screenshot is the only version that ever leaves your Mac. There is a free 7-day trial with no card required. After that it is $30 once.