PDF Hyperlinks Not Working? Causes and How to Fix Them

PDF hyperlinks usually fail for one of five reasons: the text was never a real link, your reader is blocking it, a link to another file uses a path that no longer exists, merging, splitting or conversion broke it, or the target page has gone. Each has a quick check, and most can be fixed at the source.

The fix depends on which kind of link it is, so it helps to know how links are built inside a PDF. This article explains that briefly, then works through each cause with a check and a fix, and ends with the rules for links in eCTD submissions.

How does a link work inside a PDF?

In a PDF, the blue underlined text and the link are two separate things. ISO 32000-1, the PDF standard, defines a link annotation as either a hypertext link to a destination elsewhere in the document or an action to be performed (section 12.5.6.5). The W3C's accessibility guidance puts it simply: link annotations are associated with a geometric region of a page. The clickable area is a rectangle placed over the text, not the text itself.

What the rectangle does depends on its target:

• A destination in the same file, either explicit (a page and a position) or a named destination, which the standard describes as a destination referred to indirectly by a name (section 12.3.2.3).
• A remote go-to action, which jumps to a destination in another PDF file (section 12.6.4.3).
• A URI action, which resolves a web address (section 12.6.4.7).

Every cause below breaks one of these pieces: the rectangle, the target, or the reader's willingness to follow it.

Cause 1: the text was never a link

If there is no link annotation, there is nothing to click. Text that looks like a web address is just text unless the file contains a link rectangle over it, although some readers choose to detect addresses in text and make them clickable for you. That is why the same file can seem to have working links in one reader and none in another.

Check: hover over the link. If the cursor does not change to a pointing hand in a full PDF reader, there is probably no link annotation.

Fix: recreate the PDF from its source with the hyperlinks in place, using an export option that keeps links, or add the link in a PDF editor that can create link annotations.

Cause 2: your reader or organisation is blocking the link

Some readers ask before following a link to a website or another file, or block such links by policy. Adobe's help page on PDF security options lists "Enhanced Security" among Acrobat's settings, describing it as control over access to external links and multimedia content. Other readers have similar settings, and many organisations configure them centrally.

Check: click the link and watch for a security prompt or message, which is easy to dismiss without noticing. Try the same file in a second reader.

Fix: allow the link once if you trust the file and the address, or ask your IT team about the policy. Do not lower security settings for documents from unknown senders.

Cause 3: a link to another file uses a path that no longer exists

Links between files store a file path. If the path is absolute, such as a specific drive letter and folder on the author's computer, it will not exist on yours. If it is relative, it only works while the files keep the same names and the same position relative to each other.

This often goes wrong when a set of linked documents is emailed, opened from inside a ZIP file without extracting it, renamed, or uploaded to a document management system that stores each file separately. Opening one of the files in a web browser may also prevent links to neighbouring files from working, because the browser is not looking at a folder.

Check: right-click or inspect the link in a full PDF reader to see the target file name and path.

Fix: extract the whole set into one folder, keep the original folder structure and file names, and open the files from disk. If you are the author, use relative paths and test the set after copying it to a different location.

Cause 4: the links broke when pages were merged, split or converted

Links that jump within a document point either at a page object or at a named destination stored in the document catalogue. Tools that build a new file by copying pages may not rebuild either correctly.

We tested this on our own tools. Merge PDF and Split PDF both create a new document and copy pages into it with the pdf-lib library. In our test, links to web addresses survived. Links that jump to another page in the same document did not: an explicit link pointed at a copy of the target page that is not part of the new document, and the table of named destinations was not carried over, so named links had nothing to resolve to. Treat internal links as lost after merging or splitting with these tools.

Converting a PDF to images removes links completely, because the page becomes a picture. That includes rasterising tools and compression that falls back to rasterising, as our guide on compressing a PDF explains. Editing can also misplace links: because the link rectangle is tied to a region of the page, it does not move if the text underneath is edited and reflows.

Check: test a sample of internal links, such as table of contents entries and cross-references, in the processed file.

Fix: do the merging, splitting or editing first, and create internal links last. Where you can, assemble at the source, for example by combining the word-processor files and exporting once, so the links are generated for the final page order.

Cause 5: the target has moved or gone

A web link can be technically perfect and still fail because the page it points to has moved, been removed or now requires a login. The link annotation stores only the address.

Check: copy the link address and open it in a browser. A "page not found" message means the target is the problem, not the PDF.

Fix: update the link to the current address, or to a stable identifier where one exists, such as a DOI for a journal article.

A quick diagnostic order

1. Hover: does the cursor change? If not, there is no link (cause 1).
2. Click and watch for a security prompt (cause 2).
3. Inspect the target: is it a web address, a page in this file, or another file?
4. For another file, check the path and folder (cause 3).
5. For a page in this file, ask whether the file was merged, split, edited or converted (cause 4).
6. For a web address, open it in a browser (cause 5).
7. Try a second reader to rule out a viewer problem.

Hyperlinks in eCTD and regulatory submissions

Agencies expect links to work, and they say how to build them so they keep working on the agency's systems. The FDA's PDF Specifications ask for hypertext links throughout documents to supporting sections, references, appendices, tables and figures not on the same page. They say that using relative paths minimises the loss of hyperlink functionality when submissions are loaded onto network servers, and that absolute links referencing specific drives, and links to root directories, do not work once the submission is loaded. Links that open another file should open it in a new window, and links must remain active after conversion to PDF/A.

Appendix 7 of the ICH eCTD Specification v3.2.2 makes the same point about relative paths, and asks for the "Inherit Zoom" magnification setting for bookmarks and hyperlinks. The EMA's harmonised eCTD guidance (version 6.0.1) adds that overusing hyperlinks may confuse assessors and cause problems later in lifecycle management, while links back to previously submitted documents are welcome if they point to the correct location.

The practical rule for publishers is to create and check links after the final assembly step, on the final file names and folder structure. Our checklist on preparing PDFs for regulatory submissions covers bookmarks, fonts and the other checks agencies apply. Priya LifePDF is a general-purpose tool, not an eCTD publishing system, so use your publishing software's own link checks for submissions.