Somewhere in your screenshot is a token, a customer name, a phone number, or a notification you didn’t mean anyone to see. Covering it takes a couple of seconds. The part people skip is checking whether the cover actually works, and macOS doesn’t help much here, because its markup tools draw on top of a screenshot without ever changing the pixels underneath.

What macOS gives you, and what it doesn’t

After any capture, the floating thumbnail and Preview open the same markup toolbar: pen, shapes, text, a signature tool, plus colour and stroke controls. No blur, no pixelate, no redaction. That leaves two imperfect options.

A filled rectangle over a secret looks redacted in a thumbnail, and it looks redacted in a flattened export too. In Preview, though, that shape is an annotation rather than a change to the image, so anyone who opens the original file can click it, press Delete, and read what was underneath. Exporting a copy does bake the shape in, but the file you kept still carries the removable layer, so that has to be cleaned up as well.

Cropping is the only built-in that really removes pixels. If the sensitive part sits near an edge of the frame, crop it out. Information that isn’t in the file can’t be recovered from it.

For anything in the middle of the frame you need a tool that rewrites the pixels. Here is how the approaches differ.

Blur vs pixelate vs mask vs crop

Method What it does to the pixels Use it for
Blur Averages neighbouring pixels into each other Faces, names, and context you still want readable
Pixelate Replaces blocks of pixels with one flat colour Tokens, keys, numbers, exact values
Solid mask Overwrites the region with a single colour Anything where the shape of it doesn’t matter
Crop Removes the region from the frame entirely Anything near an edge

Two rules cover most decisions:

  • Crop whenever you can. It’s the only method where the sensitive pixels are gone from the file instead of transformed.
  • Blur or pixelate when the surrounding context has to survive. A blurred user@example.com still reads as an email address, and a pixelated 16-character token still reads as a 16-character token. That’s usually what you want. The reader learns the shape of the thing without its value.

Where blur and pixelate get weak

Both are lossy transformations, and both can be applied too gently:

  • Pixelate with coarse blocks. A mosaic whose blocks are only a couple of pixels wide can sometimes be reconstructed, especially on flat UI backgrounds. Make the blocks big enough that a single character no longer fits inside one.
  • A light blur can still be read. Some text stays legible through a mild blur, and phone numbers or the last four digits of a card tend to survive it. Look at the result zoomed out. If you can still guess characters, switch to pixelate or crop.
  • Check the whole frame, not just the region you marked. The same token often shows up twice, in a title bar, a second tab, or a notification in the corner. Cover every instance.
  • Cover it before the image leaves your Mac. A clear copy that has already been shared, attached or pasted somewhere can’t be pulled back, so do the covering first.

Doing it in a capture app

In Shotivo the annotation editor opens as soon as you release the region drag:

  1. Press ⌘⇧9 and drag over the region.
  2. Press b for blur or m for pixelate. Each tool’s key can be changed in Settings → Keyboard Shortcuts.
  3. Drag over the sensitive area. The corner handles let you resize it afterwards.
  4. Press ⌘↩ to share. The uploaded image is the flattened result, so the original pixels are not in it. ⌘S saves the same flattened image as a new file.

A few details decide how well it works. The blur strength is fixed (it scales with the size of the screenshot), so if text still reads through it, use pixelate instead. The pixelate blocks grow with the selection, at roughly a twelfth of its shorter side and never smaller than 6 pixels, so a larger selection gives coarser blocks. Shotivo has no solid-fill tool, so for a hard cover use pixelate or crop.

One more thing to know: Shotivo writes every raw capture to your save folder (~/Pictures/Shotivo/ by default) the moment you take it, before the editor opens. Sharing or saving the covered version doesn’t touch that file, so the unblurred original stays on disk until you delete it.

The annotation guide covers the rest of the toolset. The other half of the decision is how the image travels, and why a link beats an attachment explains that difference.

The two-minute check before you send

  1. Zoom out until the image is thumbnail-sized. If you can still read the secret, it isn’t covered.
  2. Scan the whole frame for a second copy of the same value.
  3. Check that the crop didn’t leave a half-visible edge of the token in frame.
  4. Send a link instead of the file when you can. How the options compare covers the tradeoffs. Keep in mind that a share link stays live until it expires, which is 7 days on Free.
  5. Delete the unblurred original so the covered copy is the only version left. In Shotivo that is the file from the moment of capture in your save folder.

Nothing warns you when a redaction fails. The mistake only becomes obvious once the image is somewhere you can’t take it back from, which is why the bug report workflow puts covering before attaching.