Redacting a PDF Without Precise Mouse Control

There are plenty of ways a PDF redaction can go wrong, and almost all of the attention goes to the invisible ones: text still sitting under the black, a hidden layer, metadata naming the author, an OCR layer nobody thought about. Those are questions about the file. This page is about a question that comes earlier and gets written about far less — whether you can make the gesture the tool is waiting for.

HidePDF has exactly one way to place a redaction: you press on the page, drag out a rectangle, and release. That is a sustained, aimed, two-handed-precision movement, repeated once for every item you need to cover. For most people it is unremarkable. If you work with a keyboard instead of a mouse, if a tremor or limited range of motion makes a held drag unreliable, if you drive the pointer with a head tracker, a trackball or a switch, or if you cannot see the edges of a line of six-point type clearly enough to aim at them, then the standard advice on this site — maximise the window, start from the top-left corner, pull past the end of the text — is answering a question you did not ask.

So this is the honest version: what the tool actually requires from your hands and eyes, which parts of it are already keyboard-operable, where the genuine dead ends are, and what to put in place around it so a document still gets redacted properly rather than approximately.

What the tool really demands, step by step

It helps to separate the workflow into the parts that need a pointer and the parts that do not, because the split is sharper than you would guess.

Opening the document needs a pointer. The drop area is a click target that opens your system file dialog, and it also accepts a file dragged onto it. The file input itself is hidden, and nothing on the page carries an explicit tab stop, which means tabbing will not land you on a file picker. A keyboard with no pointer emulation available simply cannot get past this step — that is a real limitation, not a trick you are missing.

Drawing each box needs a pointer. There is no keystroke that starts a rectangle, no click-once-then-click-again mode, and no way to type the coordinates of a region. Two details of how the drag is tracked do work in your favour, though. The movement and the release are watched at the window level rather than only on the page, so you can let go anywhere and the rectangle still completes. And the coordinates are clamped to the page, so if you start inside the page and pull out past its edge, the box stops flush against the boundary. Aiming at the exact margin is therefore never necessary: deliberately overshoot and let the clamp finish the edge for you.

Everything else is keyboard-operable already. Prev and Next, Undo, Clear page, New PDF and Download Redacted PDF are ordinary buttons, reachable with Tab and activated with Enter or Space. So page navigation, correction and the final export do not need the mouse at all.

Two more mechanics are worth knowing before you adapt anything. A rectangle under roughly three pixels in either dimension is thrown away rather than stored, with no warning — which is mostly protective, since a stray click cannot scatter invisible slivers of black across your page, but it also means a twitch that registers as a near-zero drag produces nothing. And nothing is timed. You can hold the button down, stop moving completely, and carry on a minute later; slow is not penalised, and there is no flick gesture anywhere in the tool.

Where the standards sit on this

If you need to make a formal case — to an employer, a procurement process, or an accessibility reviewer — the relevant yardstick is WCAG 2.2, which added success criterion 2.5.7, Dragging Movements, at Level AA. Its requirement is that "all functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author."

Whether drawing an arbitrary freehand rectangle over a document counts as essential dragging is a judgement call rather than a settled answer, and it is the reason a great many annotation and markup tools still work the way this one does. We are not going to claim the exemption on our own behalf here. What is fair to say is that the drag is the only gesture in the tool that raises the question at all, and that if you are assessing this tool against a written accessibility policy, that single criterion is the one to look at first.

Driving the drag from the keyboard

The practical route for most keyboard users is pointer emulation at the operating system level, because a held-and-released pointer button is precisely what a drag needs, and both major desktop systems ship it.

On a Mac, Mouse Keys lives in System Settings, under Accessibility, in Pointer Control. With it on, the pointer moves from the numeric keypad using 7, 8, 9, 4, 6, 1, 2 and 3, or from the main keyboard using 7, 8, 9, U, O, J, K and L. A click is 5 on the keypad, or I on the keyboard. The two keys that matter for redaction are the ones people overlook: press and hold the button is 0 on the keypad or M on the keyboard, and release is the period key in both layouts. A rectangle is then four discrete steps — move to the first corner, hold, move to the opposite corner, release — with as much thinking time as you like in between. Note that while Mouse Keys is on, the keyboard and keypad stop entering text, so turn it off before you try to type a filename in the save dialog. The same Pointer Control panel also offers alternate pointer actions driven by switches or facial expressions, and a head pointer option for moving the pointer without hands.

On Windows 11, the equivalent is Mouse keys, reached with the Windows logo key plus U, or Start then Settings then Accessibility, then Interaction, then Mouse, where the Mouse keys switch is toggled with the Spacebar. It drives the pointer from the numeric keypad in the same way, and it likewise has hold-the-button and release-the-button actions mapped onto keypad keys — on most builds 0 to hold and the period key to release, but check what your own Mouse keys settings list, since this is the one detail that varies.

Anything else that presents itself to the browser as a pointer — a head tracker, an eye-gaze system, a trackball with a lockable drag button, a joystick mouse, switch access with a drag-lock — works for the same reason. The tool never asks where the pointer input came from. The only thing it would struggle with is an input that cannot hold a button down across a movement, which is exactly what a drag lock exists to solve.

Making the aim easier, whatever you are using

1. Settle the window before the first box. The page is scaled to fit the width of the viewer, so your window width is the zoom control, and there is no separate zoom in the toolbar. Maximise, collapse sidebars, and then leave it alone. Changing it later re-fits the page and rescales the boxes you have already drawn, which is a mess you do not want to manage on top of everything else.
2. Magnify with the system, not the browser. An operating-system magnifier enlarges what is on screen without changing the browser's layout, so nothing is re-fitted and nothing is rescaled. That makes it the safer way to get a close look mid-session. The trade-off is that you see less of the page at once, so you can lose track of where a rectangle's far corner is.
3. Redact by block, not by word. If fine aim is the scarce resource, spend it where it matters and cover a whole line, a whole cell or a whole address block instead of picking out four digits. Bigger rectangles are easier to land. They do have a separate cost — a box shaped tightly around the hidden content tells the reader something about its length — so cover generously rather than exactly, and prefer consistent, oversized blocks to fiddly ones.
4. Overshoot the edges on purpose. Because coordinates are clamped to the page, pulling past the margin lands the box flush with it. This is the single most useful trick available to an imprecise pointer.
5. Trust the counter, not your eyes. The status bar's "Boxes on this page" number is the only confirmation that a rectangle was stored rather than discarded. It is plain text that does not announce itself when it changes, so if you are using a screen reader or a magnifier you will need to look at it or navigate to it deliberately after each box.
6. Work one page at a time, in order. Boxes are stored per page, and Undo and Clear page act only on the page you are viewing. A linear pass is much easier to keep track of than jumping around.
7. Check the downloaded file before you send it. Open the exported PDF and look at each page you touched. The editor shows your intent; the file shows the result. If something is short, redo that page rather than patching it with a second overlapping rectangle.

Common mistakes and misconceptions

"A rough box must be a weaker redaction." It is not. Coverage and permanence are separate things. Whatever ends up inside the rectangle is gone from the exported file completely, because the page is rebuilt as an image with the black burned in. Imprecision costs you coverage — a missed digit at the end of a line — not security.

Trying to drag fast or smoothly. Nothing in the tool rewards it. A slow, stepped, interrupted drag produces exactly the same rectangle as a confident sweep.

Switching to a phone or tablet because tapping feels simpler. The target is blunter and the page is displayed smaller, so you get a larger finger and less document to aim it at. Touch is fine for a signature block or a whole paragraph and poor for anything smaller.

Leaving Mouse Keys on for the save dialog. It takes over the number keys, so filename typing stops working and people assume the download failed. Turn it off once the rectangles are drawn.

Expecting Undo to walk backwards through the session. It removes the last box on the current page only. If you have moved on a page, it has nothing to undo.

Assuming the output will be accessible to you later. The exported file is page images with no text layer, so your own screen reader will get nothing from it. Keep the original for your own reading.

Assuming a bigger window produces a sharper file. It does not. The export resolution is fixed at twice the page's natural size regardless of how the page looked while you worked. A bigger window buys aim, not quality. Everything stays inside your browser at any size; no upload is required at any point.

Related guides

See also, or use the redaction tool above:

• Why a Redaction Box Doesn't Land Where You Drew It
• Why Redacted PDFs Sometimes Fail Accessibility Standards

Frequently asked questions