What Happens to Hyperlinks When You Redact a PDF?

Most of the redaction failures covered elsewhere on this site involve something that was printed on the page and then imperfectly hidden — live text under a drawn rectangle, an OCR layer under an image, an author name in the document properties. A hyperlink is a different shape of problem, and it deserves separating out, because the thing that leaks was never printed on the page in the first place. It has no ink. You cannot see it, and covering the part you can see does not necessarily touch it.

Here is the structure. When a PDF page is displayed, almost everything you look at comes from that page's content stream: the instructions that draw glyphs, lines and images at particular coordinates. A link is not in there. A link is an annotation — an entry in a separate list attached to the page, holding a rectangle that defines the clickable area and an action dictionary that defines what happens when you click it. The two are only loosely related. The rectangle happens to sit over some words, and by convention those words are styled to look like a link, but nothing enforces that. The rectangle can sit over an image, over blank space, or over text that reads as something completely different from where it actually goes.

So consider what happens when you redact by adding a black shape to a page. You have appended drawing instructions to the content stream. The annotation list is untouched. The hotspot is still live. The destination string is still stored in the file. Hover over the black box in a reader and the target may appear in the status bar; right-click and you can copy the link address. The words are hidden and the thing they pointed at is not.

Why the destination is often the sensitive part

It is easy to assume a link is harmless because you read its label. The label is the part under your control; the target frequently is not, because it was generated by whatever system produced the document. A few patterns worth knowing:

• Mailto links. Anchor text reading "contact the case manager" can carry a named individual's email address, which is precisely the kind of detail people redact from the visible page and then leave in the link.
• Cloud sharing links. A share URL often encodes an account name, a workspace or tenant identifier, a folder path, or a token. Tokens are the serious case: where a link is designed to grant access without a login, the URL is effectively a credential, and pasting it into a document you are redacting hands that credential to whoever gets the file.
• Portal and record links. Case management, payroll, HR, billing and patient systems commonly build URLs containing a record identifier in the path or query string. The number itself looks meaningless. What matters is whether your recipient can resolve it — a colleague with portal access clicks once and sees the full record.
• Internal hostnames. An intranet address discloses the organisation, and often a department or system name, even when the page has been scrubbed of letterhead.
• Tracking parameters. Query strings appended by mail and analytics platforms can carry a campaign, a list identifier, or a recipient reference from the original send.
• Links that are not web links. The PDF format supports actions that jump to a location in another document or launch an external file, and those store a file path. A path can expose a machine's folder structure, a client or matter name, and the account name of whoever authored the document. There are also actions that run embedded script, and a script action can itself contain a web address.

None of this is exotic. It is the ordinary result of copying a link out of a browser or a mail client and pasting it into a document.

The other direction: redaction that silently breaks links

The reverse failure is quieter and gets noticed later, usually by the recipient. If your redaction method flattens the page — rasterizing it to an image, printing to PDF, or exporting through a pipeline that rebuilds the file — every link annotation disappears along with everything else in the structure. The text still looks like a link, blue and underlined, and it does nothing at all.

For a two-page letter, nobody cares. For longer documents this can matter a great deal: a clickable table of contents in a report, cross-references between exhibits in a filing, citation links in a research document, a footer address that recipients are expected to click. The document arrives visually intact and functionally inert, and because the styling survives, the recipient's first assumption is that their reader is broken rather than that the file changed. If the links are load-bearing, that is something to decide on deliberately and mention when you send the file — not something to discover from a confused reply.

A check to run before you export

1. Enumerate the links, don't eyeball them. Open the file in a browser's built-in PDF viewer, where link annotations become genuinely clickable areas, and sweep each page with the cursor. A desktop editor's link tool will list links per page, and a preflight or sanitize function will enumerate annotations across the whole document, which is what you want for anything long.
2. Read the whole target, not the domain. Hover, or right-click and copy the address, and read the full string. The identifying material is almost always in the path, the query string or the fragment — the end, not the beginning.
3. Do not click to find out. Opening a per-document or tokenised link can register a visit, and for a file you are handling carefully that access record is itself a disclosure. Read the address instead of visiting it.
4. Look for links with no visible styling. An annotation is only a rectangle. It may sit over an image, a logo, a header, or nothing at all. This is exactly the case that a visual read of the page will never catch, and the reason enumerating beats eyeballing.
5. Ask the resolution question for each one. As with any reference number: does this target contain, or let this specific recipient retrieve, something you are covering elsewhere in the document? If yes or you cannot tell, it has to go.
6. Decide function before you remove. Note which links the recipient actually needs. If some are essential and others are sensitive, the answer may be to edit the source document and regenerate it rather than to redact the output.
7. Verify on the exported file, not the original. Reopen the finished PDF in a browser viewer and hover over every place a link used to be. If nothing highlights and nothing appears on right-click, you are done. This is the only check that proves the result.

What this tool does with links

HidePDF does not edit your file. When you click download, it creates a new, empty PDF, renders each page of your document to an image with your boxes burned into that image, and places those images into the new document. Nothing is carried across from the original's object structure — so the output has no annotation list at all. No link annotations, no comment annotations, no form fields, no outline. Every hyperlink in the document becomes flat pixels.

That is a clean answer to the leak on this page: there is no surviving hotspot and no stored target, because there is no annotation to survive. It is also, unavoidably, the second problem. The export is an image-based document, so links are gone whether you wanted them gone or not, and the same is true of selectable text throughout the file. If a printed web address is visible in the text and you want it hidden, you still have to draw a box over it — flattening removes the link, not the characters. And all of this happens on your own device, inside the browser tab, with no upload required.

One detail worth knowing about the preview: the on-screen render draws annotation appearances into the page image where an annotation has one. Link annotations normally have no visible appearance, so they show up as nothing — but a sticky-note icon, a stamp or an ink markup can be painted into the rendered page and then baked permanently into the export. If your document has visible review markup you did not intend to publish, remove it in your editor before you come here.

Common mistakes and misconceptions

"I covered the link, so the link is covered." You covered the anchor text. Whether the annotation went with it depends entirely on the tool. Check the exported file rather than assuming.

Judging a link by its label. The label was written by a person; the target was usually generated by a system. They are not required to have anything to do with each other.

Only checking blue underlined text. Link annotations carry no mandatory styling and may sit over images or empty space.

Treating a share link as a reference rather than a key. Where a link is designed to grant access without a login, it functions as a credential, not a pointer.

Assuming a text search of the file will find the URLs. PDF objects are frequently stored compressed, so a plain text scan can come back clean on a file full of links. A negative result there proves nothing.

Forgetting the recipient needed the links. Flattening is silent. The document still looks right, which is why nobody catches this until after it is sent.

Assuming flattening also removes visible addresses. It removes the clickable behaviour. A URL printed in the body text remains perfectly readable and still has to be boxed by hand.

Related guides

See also, or use the redaction tool above:

• Can sensitive data hide in PDF comments, bookmarks, or attachments?
• Why a QR code or barcode can undo your PDF redaction

Frequently asked questions