Why a Redaction Box Doesn't Land Where You Drew It
Most redaction advice is about what survives underneath the black. This is about something simpler and more embarrassing: the rectangle not being where you thought you put it.
There are two completely different ways a redaction can fail, and they need completely different fixes. The first is the famous one: the black is only paint, and the text is still sitting underneath it, ready to be copied, searched, or lifted out by anyone who opens the file properly. That is a failure of the software, and the answer is software that genuinely destroys the covered pixels rather than drawing over them.
The second kind of failure gets almost no attention, because it is not clever and nobody writes papers about it. The removal works exactly as designed — and the rectangle is in slightly the wrong place. It is two millimetres short of the end of the account number. It covers the label and not the value. It never got stored at all, because the drag was too quick. It looked perfect on screen and arrived in the finished file shifted by a third of a line. None of that is recoverable text, and none of it is a cryptographic problem. It is the gap between your hand, the screen, and the geometry of the exported document.
That gap is worth understanding in detail, because it is the one failure mode where the tool cannot help you by being smarter. A hand-drawn redaction tool has no idea what is under your cursor — it never reads or interprets the contents of your document at all — so it cannot nudge a box to the edge of a word or warn you that you missed the last digit. Placement is entirely yours. What follows is what actually happens between the drag and the download, and the specific things that move, shrink or swallow a rectangle along the way.
What happens between your cursor and the file
Three different coordinate systems are involved, and most placement surprises come from the joins between them.
The first is the page as the PDF defines it, measured in points. That never changes. The second is the page as displayed: when a page is opened it is scaled to fit the width of the viewer area, with the scale worked out from your window width rather than from any setting you chose. There is deliberately no zoom button in the toolbar — the size of your browser window is the zoom control. The third is the exported page, which is rebuilt at a fixed multiple of the page's natural size no matter what your screen was doing.
Your rectangle is captured in the second of those systems: the coordinates you see. At download time it has to be translated into the third. That translation is a simple multiplication by the ratio between the export scale and the display scale that was in force when you drew — which works perfectly as long as the tool's record of that display scale still matches the coordinates it is holding. Keeping those two in step is, in practice, the whole story.
Five things that move, shrink or swallow a box
- A drag that was too small. On release, the rectangle between your press point and your release point is measured, and if it is under roughly three pixels in either dimension it is discarded rather than stored. This is intentional — it stops accidental clicks from scattering invisible black slivers across the page — but it is completely silent. If you flick at a short field and nothing turns black, this is why. The status bar's box counter is the ground truth: if it did not increase, nothing was saved.
- Resizing the window after you have started. Changing the window width changes the display scale, so the rectangles already on screen have to be rescaled to stay over the same content. That adjustment is applied to the page you are currently looking at and to pages you boxed earlier — but the scale that gets recorded for the export mapping is refreshed only for the page being rendered. Pages you boxed earlier and have navigated away from can therefore be rescaled on screen while the export still assumes the old scale, and the result is boxes that drift and grow in the downloaded file. Rotating a phone or tablet is a resize. So, in most browsers, is changing the zoom level. The simple rule is to settle your window before you draw the first box.
- Boxes belonging to a page, not the document. Rectangles are stored per page, and so are the controls that remove them. Undo takes back the most recent box on the page you are viewing; Clear page empties that page. If you draw a box, move to page 7, and then press Undo expecting to take back the last thing you did, nothing happens — the last thing you did was on page 6, and Undo is now looking at page 7's empty list.
- Releasing outside the page. This one works in your favour once you know about it. The drag is tracked across the whole window, but the coordinates are clamped to the page, so if you start inside the page and pull outward past its edge, the rectangle stops flush with the boundary. That is the reliable way to cover something that runs right to the margin — rather than trying to land exactly on the edge, overshoot it. The one caveat is that releasing the button entirely outside the browser window may mean the release is never registered, leaving a rubber band following your cursor. A single click on the page ends it harmlessly, because a zero-size drag is discarded.
- Judging coverage from the translucent preview. While you drag, the rectangle is shown as a semi-transparent grey fill with a dashed red outline, so you can still see what you are covering and adjust. The moment you release, it becomes solid black. People sometimes read the see-through preview as "this is not really covering it" and drag wider to compensate, or conversely trust a preview edge that is a pixel or two off because the text showing through looks reassuringly covered. Judge the edges from the committed black box, not from the preview.
A placement workflow that holds up
- Size the window first. Maximise it, close the sidebar, put the laptop on the desk rather than balancing it. The page renders to fit the viewer width, so a wider window means a larger page and finer control per pixel of hand movement. Do this before the first box, not after the fortieth.
- Work the document in one pass, page by page. Finish a page before moving on. Because both the storage and the correction controls are per-page, a linear pass is far easier to keep track of than jumping around.
- Start each drag at the corner you are surest about. Usually that is the top-left of the text you are covering. Then pull down and right past the end of the content, so the imprecise end of the gesture falls in whitespace rather than on the last character.
- Overshoot the margins deliberately. Where content runs to the edge of the page, drag beyond the edge and let the clamp do the work.
- Watch the counter, not the canvas. After each box, glance at "Boxes on this page". It is the only confirmation that a rectangle was actually stored rather than discarded as a stray click.
- If you resized anything, page back through everything. Rendering a page again re-records its display scale. Walking from page one to the end after a resize costs seconds and puts the export mapping back in step.
- Check the downloaded file, not the editor. Open the exported PDF and look at every page you touched at full size. The editor shows you your intentions; the file shows you the result. This is the step that catches everything above, and it is the one most often skipped because the editor looked fine.
Common mistakes and misconceptions
"The preview is the file." The on-screen overlay and the exported page are produced by two separate pieces of code at two different scales. They agree almost all the time, which is exactly why the rare disagreement gets shipped — nobody checks something that has never been wrong before.
Treating Undo as a session-wide history. It removes one box from the current page. It is not a timeline of your work, and it will not rescue a mistake you made two pages ago.
Resizing the window to "see it better" halfway through. The most natural instinct in the middle of a fiddly redaction is the one most likely to shift earlier boxes. If you must, page back through afterwards.
Assuming a bigger window gives a sharper output. It does not. The export resolution is fixed. A bigger window buys you aim, not quality.
Drawing a second box to patch a gap. It works visually, but it leaves you with overlapping rectangles that are harder to review, and it doubles the count of redactions on the page — which is itself information you are publishing. Undo and redraw one clean rectangle instead.
Trusting a phone for precision work. A fingertip is a blunt instrument against six-point type, and the page is displayed small because the window is small. Phones are fine for a signature block or a whole paragraph; they are a poor choice for picking the last four digits out of a table.
Confusing this with the question of how big a box should be. Accuracy and sizing policy are different problems. This page is about getting the rectangle where you meant it to go; how wide you should deliberately make it, to avoid the box itself becoming a measurement of the hidden content, is a separate decision.
Related guides
See also, or use the redaction tool above:
- Can the Size of a Redaction Box Reveal What's Underneath?
- Why Redacting a PDF on a Phone Is Different From a Desktop
Frequently asked questions
I dragged a box and nothing appeared. What happened?
Almost certainly the drag was too small to count. When you release the pointer, the tool measures the rectangle between where you pressed and where you let go, and if either the width or the height is under about three pixels it throws the rectangle away instead of storing it. That rule exists so a stray click does not leave an invisible black sliver on your page, but it is silent: there is no warning, no error, and the box counter in the status bar simply stays where it was. The same thing happens if you click once without moving at all, which is the intended way to cancel a drag that got stuck. So the diagnosis is easy — look at the "Boxes on this page" counter. If it did not go up by one, nothing was stored, and you should drag again with a deliberate movement rather than a flick. A second cause worth ruling out is that you released the button outside the browser window entirely, in which case the drag never finished. Click once anywhere on the page to clear it, then redraw.
Can I move or resize a redaction box after I have drawn it?
No. There are no selection handles, no drag-to-move and no edit mode. Once a rectangle is committed it is fixed, and your only corrections are Undo, which removes the most recently drawn box, and Clear page, which removes every box on the page you are currently viewing. Both of those act on the current page only — they will never touch work you did on another page, which is usually what you want but occasionally surprises people who expect Undo to walk backwards through the whole session. The practical consequence is that placement is a one-shot action, so it pays to start the drag from the corner you are most confident about. If a box lands wrong, Undo and redraw rather than drawing a second box to patch the gap, because overlapping rectangles are harder to audit later when you are checking the finished file.
Does resizing the browser window affect boxes I have already drawn?
It can, so the safe habit is to set your window size before you start drawing and leave it alone until you have downloaded the file. The page is rendered to fit the width of the viewer, so changing the window changes the scale at which everything is displayed, and the tool rescales your stored rectangles to match. That adjustment is reliable for the page you are looking at when the resize happens. Pages you boxed earlier and have since navigated away from are the risk: their rectangles are rescaled, but the scale factor recorded for mapping them into the exported file is not refreshed until that page is rendered again. If you do resize mid-session — or rotate a phone or tablet, or change the browser's zoom level, both of which count as resizes — page back through every page you have already boxed before you hit download. Rendering a page again re-records its scale and puts the mapping back in step.
Does making the page bigger on screen make the redaction more accurate?
It makes your aim more accurate, not the output. The exported file is always rebuilt at twice the page's natural size, regardless of how large or small the page looked while you were working, so the resolution of the finished PDF does not change when you widen the window. What does change is how many screen pixels a line of text occupies while you are dragging. On a page displayed small, a single pixel of hand wobble represents a larger slice of the real document, and the margin for error at the edge of a word shrinks accordingly. On a wide window the same wobble covers less of the page. There is no zoom control in the tool — the width of your browser window is the zoom — so maximising the window, or collapsing a sidebar, is the straightforward way to get finer control before you start. Everything stays in your browser either way; no upload is required at any size.