Free · No Signup

Redacting an Image Before You Paste It Into a Document

The cover you drew on the slide is an object sitting on top. The picture underneath went into the file whole — and it comes back out whole.

🔒 No upload · Runs in your browser · Instant download

Nearly every page on this site treats the image as the thing you hand over: you cover what is sensitive, you export it, you send it. But a great many redacted images are never sent as images at all. They get pasted into a report, dropped onto a slide, attached inside a shared doc, or embedded in a spreadsheet that goes round a committee. The moment a picture goes inside another file, a second question appears that has nothing to do with how carefully you covered anything — what did the container keep?

For the formats most people actually use, the answer is documented and not really in dispute. A .docx, .pptx or .xlsx is a ZIP archive. Open one with any ordinary archive tool and the pictures are sitting there in a folder — word/media, ppt/media, xl/media — as plain image files, at the quality and resolution they were inserted with. That is not a flaw or an oversight; it is how the format is designed, so that the application can re-render or re-scale a picture later without degrading it.

Which means that if you cropped the picture after inserting it, or dragged a filled rectangle over the part you wanted hidden, you have changed how the document draws that picture. You have not changed the picture. The distinction is invisible on screen and decisive in the file, and it is the whole subject of this page. If you want the underlying point about cropping in its own right, see does cropping a photo remove the cropped part permanently?

Mode
Shape

Drop your image here

Or click to browse · Paste with Ctrl+V also works

PNG · JPG · WebP · GIF
How It Works
1

Open

Drop your image in or paste from clipboard.

2

Pick Mode

Black Box, Blur, or Pixelate.

3

Select Areas

Rectangle, oval, or freehand lasso — then hide what you selected.

4

Download

Hit Download PNG. Done.

SquooshNeed to shrink your image after editing? Squoosh is a free browser-based image compressor with no upload required.

Visit Squoosh →
Guide

One sentence carries this page: redacting inside the document edits the document, not the image — and the document is a container that kept your picture exactly as you gave it to it.

Why this is a container problem, not an image problem

Everywhere else on this site, a redaction succeeds or fails on the pixels: is the cover opaque, is the blur strong enough, did you leave enough of a number visible to be reconstructed. Here the pixels can be perfect and the outcome can still be a disclosure, because the file you send is not the picture. It is a package, and the package has its own rules about what it holds on to.

The modern Office formats make this easy to see. Take a copy of any .pptx, rename the copy to .zip, and open it. Inside is a directory tree of XML files describing the slides, and a folder of media containing every image in the deck as a standalone file. The XML says where each picture goes, how big to draw it, which corner of it to show, and what shapes to paint on top. The media folder holds the picture itself — untouched, whole, and at whatever resolution it had when it was inserted.

Once you have that picture in your head, the failure modes stop being surprising. Every editing operation you perform on an inserted image is a change to the instructions, not to the media. The application renders the instructions faithfully, you look at the render, and you conclude that the image has been edited. It has not.

Crop inside a document is a display setting

Cropping is the clearest case. Insert a photo, crop away the half you do not want, and the application stores a note saying which rectangle of the picture to display. Press the Crop control again and the discarded half swings back into view, because it never went anywhere. Anyone can do this. It is not a recovery technique or an exploit; it is a button on the ribbon.

Microsoft supplies two controls for actually removing that data, and the existence of the controls is the clearest confirmation of what the default behaviour is. The Compress Pictures dialog carries a checkbox labelled Delete cropped areas of pictures. Separately, under File → Options → Advanced, in the Image Size and Quality group, there is a Discard editing data checkbox that drops the retained data when the file is saved and reopened.

Both are useful. Neither is something to stake a disclosure on. There is a long-standing thread on Microsoft’s own support forum from users reporting that they ticked Delete cropped areas of pictures, pressed OK, saved, reopened the document — and found the cropped regions still present when they pressed Crop again, with no clear pattern to when it worked. Whether that affects the build in front of you is not something the application will tell you. The safe conclusion is not “never use these options”; it is “never let the sensitive content get into the file in the first place, so that it does not matter whether they worked”.

A shape on top is a shape on top

The second failure mode is drawing a black rectangle over the sensitive region of a picture. On screen it is indistinguishable from a real redaction. In the file it is a separate drawing object with a position, a size and a fill colour, stored alongside the picture rather than merged into it.

There is no clever attack required to undo it. Click the rectangle, press Delete. Or right-click the picture and use the application’s own Save as Picture command, which saves the picture — not the shapes arranged over it. Or skip the application entirely and read the media folder out of the archive. Three routes, all trivial, all available to anyone the document reaches, including people it gets forwarded to weeks later.

This matters more than the crop case because it is the one people reach for deliberately. Cropping is usually about layout, and the disclosure is accidental. Drawing the rectangle is a considered privacy decision that produces no privacy at all — and because it looks so convincing, nobody goes back to check it.

The order of operations that actually works

1. Redact the image while it is still an image. Use something that replaces pixels rather than layering objects. The editor on this page paints its covers directly into the canvas — the covered pixels are overwritten before any file is written — so the exported PNG is a flat picture with nothing underneath the covers to find.

2. Export, and treat that export as the only version that goes anywhere near the document. From here on, the original file and the redacted export are two different things with two different handling rules.

3. Insert the export. Not the original. This sounds obvious and it is the step that actually goes wrong, usually because someone dropped the original in first to check the layout, then swapped it later. See below.

4. If a wrong picture ever went in, do not replace it — delete it and start again. A Change Picture or Replace Image command updates what the document displays. Whether it also removes the previous media part, and whether it does so immediately or only on a later save, varies by application and version. You cannot see the answer from inside the editor. Deleting the picture, saving, and inserting the redacted one fresh is not much slower and does not require you to be right about implementation details.

5. Do the layout work at full size, not by cropping to hide things. Cropping for composition is fine. Cropping as a privacy measure is the thing this page exists to warn about. If a region must not reach the recipient, cover it in the image before you insert it, and then crop for layout afterwards if you still want to.

6. Audit the finished file, not the finished page. Save it, take a copy, open the copy as an archive, and look in the media folder. Everything legible there is in the document you are about to send. This is the only check that tests the file rather than your application’s rendering of it, it takes about a minute, and it needs nothing beyond the archive tool your operating system already has. Delete the extracted copy when you are done.

Cloud editors, PDF export and everything else

The mechanics above are specific to the Office formats because those are the ones you can open and verify yourself. The reasoning generalises further than the evidence does, so treat the rest conditionally.

In any editor where the picture and the cover are distinct objects — which is essentially all of them, including browser-based document and slide tools — the same structural question applies: is the original picture still held somewhere in the document’s stored state? For a cloud editor you often cannot inspect the stored state at all, and the downloaded export may differ from what the service retains on its side, including in version history. That opacity is not evidence of a problem, but it is a good reason not to rely on in-document covering when you have the option of not needing to.

The same caution applies to exporting the document as a PDF and hoping that flattens everything. Sometimes an export path rasterises a page into flat pixels; sometimes it preserves the layered objects faithfully, because preserving them is normally the desirable behaviour. It varies by application, version and export options, and PDF is entirely capable of holding a full-resolution image with a vector rectangle drawn on top — the identical failure in a new wrapper. If your image was flattened before insertion, none of this matters. If it was not, an export step is a bet on an implementation detail you cannot see.

What the editor above does and does not do

The editor on this page is region-based: three modes — Black Box, Blur and Pixelate — across three selection shapes, rectangle, oval and freehand lasso. Every operation replaces the pixels inside the region you drew. Black Box fills the region with a solid dark colour; Blur downsamples the region heavily and scales it back up; Pixelate replaces blocks with a single sampled colour. Undo steps back one cover, Clear restores the untouched image.

There is no crop, no resize and no rotate, which in this context is a feature rather than a gap — the covers are the only thing it does, and they are destructive by construction. Download PNG writes the current canvas out as hideshot-<timestamp>.png, re-encoded from scratch, so nothing from the source file is carried across into it. All of it runs in your browser: the image is decoded, edited and exported on your own machine, and nothing is sent anywhere. The file you then insert into your document is a flat picture with no layers, no history and no retained original, which is exactly the property the container cannot undermine. For the question of what to do with the untouched source file once you have that export, see what happens to the unredacted original after you redact it.

Common mistakes and misconceptions

“The slide looks right, so it is right.” The rendering is generated from instructions plus media. You are looking at the instructions being obeyed. The media is the part that travels.

“I will crop it in the document, that is the same as removing it.” It is a note about which rectangle to display. The rest of the picture is still in the archive, and un-cropping it is a single click.

“I ticked Delete cropped areas, so it is gone.” Probably, but users have reported it silently failing, and you get no confirmation either way. Use it as a tidy-up, never as the protection itself.

“A black rectangle over the region is a redaction.” It is a shape sitting on top of an unmodified picture. Selecting it and pressing Delete reveals what is underneath, and so does saving the picture out of the document.

“I put the original in first and swapped it for the redacted version later.” This is the most common way a correctly redacted image ends up in a document alongside the thing it was meant to replace. Whether the superseded media part is actually removed depends on the application and the command you used. Delete and reinsert rather than replace, then check the archive.

“I will just export to PDF at the end.” Sometimes that flattens. Sometimes it carries the layers straight through. You cannot tell which from the ribbon, and you do not have to care if the picture was already flat when it went in.

“It is an internal document, so it does not matter.” Internal documents get forwarded, attached to tickets, pulled into shared drives and indexed by search. The number of people who could open the archive is not the number of people in the meeting.

The Document Kept the Picture You Gave It

Most redaction advice is about pixels - is the cover opaque, is the blur strong enough, how much of a number can stay visible. This page is about what happens after all of that, when the image stops being the thing you send and becomes something you paste into a report, a deck, a ticket or a shared spreadsheet. At that point the file you hand over is a container, and the container has its own rules. The modern Office formats are ZIP archives: rename a copy of a .pptx to .zip, open it, and every picture in the deck is sitting in a media folder as an ordinary image file at the resolution it was inserted with. The slides themselves are XML describing where to draw each picture, which rectangle of it to show, and what shapes to paint on top. Editing an inserted image changes those instructions. It does not change the media.

Two consequences follow, and between them they account for most in-document redaction failures. Cropping a picture after inserting it records which portion to display; press Crop again and the trimmed-off part swings back, because it never left. Microsoft ships a "Delete cropped areas of pictures" checkbox in the Compress Pictures dialog and a "Discard editing data" option under File, Options, Advanced precisely to deal with this - though users have reported the former failing to take effect, with no indication either way from the application. And a black rectangle dragged over the sensitive region is a drawing object layered on an untouched picture: select it, press Delete, and the content is back. So is using the application's own Save as Picture command, which saves the picture rather than the shapes arranged over it. None of this requires a technique. It requires a click.

The fix is ordering rather than vigilance. Redact the image while it is still an image, in something that replaces pixels rather than layering objects, export the flattened file, and insert that - never the original, not even temporarily to check the layout. If a wrong picture did go in, delete it and insert again rather than using a replace command, because whether the superseded media part is actually removed depends on the application and version. Then audit the file rather than the page: save it, take a copy, open the copy as an archive and look in the media folder. Whatever is legible there is in the document you are about to send, regardless of how the pages render. Do the same before relying on a PDF export to flatten anything, since some export paths rasterise and others faithfully carry the layers through. If the picture was already flat when it went in, none of that matters, which is the entire point of doing it in that order.

Frequently asked questions

I cropped the picture after putting it in the document. Is the part I cropped off still in the file?

By default, yes. Cropping a picture inside Word, PowerPoint or Excel changes how the picture is drawn, not what the picture is; press the Crop control again and the trimmed-off area is still there to drag back. Microsoft ships two controls specifically to deal with this, which is itself the clearest evidence of the default: a "Delete cropped areas of pictures" checkbox in the Compress Pictures dialog, and a "Discard editing data" checkbox under File then Options then Advanced, in the Image Size and Quality group. Both are worth knowing about, but neither should be the thing your privacy depends on. There is a long-standing report on Microsoft’s own support forum from users who selected the Compress Pictures option, saved, reopened the document and found the cropped areas still present, and there is no way to tell from inside the application which build you are running. If the cropped-off region is sensitive, do not crop it in the document at all. Remove it from the image file before the picture ever gets inserted.

I drew a black rectangle over the sensitive part of a slide. Does that count as redacting it?

No. It is a drawing object positioned on top of a picture object, and the two are stored separately. The picture went into the file as a complete image and is still in there as a complete image; the rectangle is a shape with coordinates and a fill colour that the application paints over it at display time. Anyone who selects the rectangle and presses Delete sees what is underneath. So does anyone who right-clicks the picture and saves it out, and so does anyone who opens the document file as an archive and reads the media folder directly. This is the single most common way a carefully considered redaction ends up disclosing exactly what it was meant to protect, and the reason it happens so often is that the slide on screen looks completely convincing. What you see rendered is not what the file contains.

How do I actually check what a finished document is carrying?

Open it as an archive and look. The modern Office formats — .docx, .pptx and .xlsx — are ZIP containers, and every picture in the document sits inside them as an ordinary image file, in a folder called word/media, ppt/media or xl/media depending on the application, at the quality and resolution it was inserted with. On Windows you can take a copy of the file, rename the copy from .docx to .zip and open it; on macOS or Linux, unzip the copy into a scratch folder. Then open the media folder and look at the pictures with your own eyes. Whatever is legible there is in the document, regardless of what the pages look like. It takes about a minute, it needs no special software, and it is the only check that tests the file rather than the rendering of it. Do it on a copy, and delete the extracted folder afterwards.

Does exporting the document to PDF flatten everything and solve the problem?

Do not assume so. Export behaviour varies by application, by version and by the options selected during export, and PDF is perfectly capable of storing a full-resolution image with a separate vector rectangle drawn over it — which is the same failure in a new container. Some export paths do rasterise a page into flat pixels; others faithfully preserve the layered objects, because preserving them is usually the point. Treating export as a sanitising step means betting on an implementation detail you cannot see from the outside. The reliable approach does not need the bet: if the image inserted into the document was already flattened, with the sensitive pixels replaced before it was ever inserted, then nothing in the export path can matter, because there is nothing left in the picture to recover. If you do want to lean on an export step, verify it the same way as anything else — open the resulting PDF, try to select and move the cover, and try to extract the images.