A modern Word (.docx) file stores every external hyperlink as a relationship entry inside its Office Open XML package, and the cleanest way to retrieve those addresses is to read that relationship file locally with a single-purpose extractor. To get every word link from a .docx, open the Word Hyperlink Extractor, choose the document from your device, and let the browser read its relationship XML in memory; the tool decodes the http, https, and mailto targets, drops duplicates, and returns a one-URL-per-line list that you can copy from the page or download as a plain .txt file. Because the relationship file is a small, well-defined part of the .docx package, the operation runs without parsing your paragraphs, comments, or images, which keeps the result both fast and conservative. You end up with an auditable list of safe external destinations only, separated from every internal bookmark, local path, or malformed target that Word may also store. This approach is well suited to reviewing sources before a report goes out, auditing a template received from another team, or collecting references from a long document where the visible anchor text alone is not enough.
The same task solved by hand, by scrolling through a 40-page report and copying every underlined address, almost always misses something. Hyperlinks in Word can sit behind a single word, an image, a citation field, a button, or a short phrase such as "see here," so a quick scan of visible text routinely omits links that are stored in the file but not visually obvious. The relationship-file approach reads what Word actually recorded instead of trying to guess what is on the page, which is why the resulting list can be trusted as a precise inventory rather than a best-effort scrape.
Why Word Documents Hide Their Hyperlink Destinations
Word treats a hyperlink as a relationship between the document content and an external destination, not just as styled text. According to the ECMA-376 Office Open XML standard, each external link is stored as a relationship entry in the word/_rels/document.xml.rels part of the package, keyed by ID, with a relationship type of http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink and a TargetMode of External. The visible blue, underlined phrase a reader clicks is just an anchor that points to that relationship ID; remove the formatting and the destination is still recorded.
This design has a practical side effect: the address you want is rarely visible in the document body. Authors wrap links around single words, citation fields, button shapes, footnote references, and decorative images, then move on. A reader skimming the document sees only the anchor text, while the destination is stored in the relationship file. That is also why pasting the visible text into a URL checker misses almost every link the file actually contains. The Microsoft Open XML documentation describes the same separation, noting that hyperlink behavior is recorded separately from the run that displays the anchor text. An extractor that reads the relationship part directly sidesteps the problem: it surfaces every link Word wrote, regardless of how the anchor was dressed up.
What the Extractor Reads and What It Skips
The extractor is deliberately narrow. It accepts one .docx file, validates that the file is a proper Office Open XML package, locates word/_rels/document.xml.rels, and keeps only Relationship entries whose type is hyperlink and whose TargetMode is External. The remaining targets are normalized and encoded XML entities are decoded. Duplicates are collapsed, and the result is presented as a flat list.
| Included in the TXT report | Excluded by design |
|---|---|
| http:// destinations stored as external relationships | Internal bookmarks and heading anchors |
| https:// destinations stored as external relationships | Local file paths and relative document references |
| mailto: addresses stored as external relationships | JavaScript-style, file://, and other unsafe protocols |
| External targets reached after XML entity decoding | Malformed targets the parser cannot interpret safely |
| Each unique URL listed once | Duplicate occurrences of the same URL |
The exclusions are not bugs; they are safeguards. An internal anchor such as #section-3 is a navigation aid, not a destination a reader can visit on the open web. A local path such as ../shared/draft.docx refers to a file on someone else's machine, which would be misleading to publish. By filtering these out up front, the tool produces a list that genuinely represents external web destinations rather than every clickable object Word is willing to record. Anchor text, page position, run formatting, and surrounding paragraph are also intentionally not preserved, because they belong to the document body rather than the relationship file. If you need that context, the original .docx is the source of truth.
Get Every Link from a Word Document in Three Steps
- Open the Word Hyperlink Extractor in your browser and choose one .docx Word document from your device. The file picker only accepts modern Word documents; legacy .doc files, encrypted packages, and oversized archives are rejected before any content is read.
- Wait while the browser reads external hyperlink relationships from the document package. The extraction happens locally on your machine: the document XML is parsed in memory, the relationship entries are filtered to hyperlink type and external target mode, and the surviving URLs are normalized and deduplicated. No upload occurs and no destination is visited.
- Review the safe destinations shown in the result panel and download the one-link-per-line TXT report. Each line is a single, document-supplied URL that you can paste into a spreadsheet, a URL checker, a citation tool, or any other local workflow that accepts plain text.
After the download, you can rename the .txt file to match your project, drop it into a shared folder, or pipe it into a separate auditing process. The file stays as small as a link list, which is useful when handing a curated bibliography of destinations to a colleague without exposing the original document body.
Reading and Reusing the One-Link-Per-Line Report
The TXT file is intentionally boring, and that is its main advantage. One URL per line means it can be parsed by sort, uniq, Excel, Google Sheets, Notepad++, or any line-oriented tool, with no headers, footers, or surrounding markup to strip first. If you need to alphabetize, deduplicate against another list, or run a column of addresses through a domain checker, the file drops in without preprocessing.
Because the report preserves the exact characters Word stored, sort the list and look for unexpected entries such as tracking redirects, regional variants of the same domain, or mailto addresses that no longer match the team that owns them. A quick pass with your editor's "find duplicates" or a line-sort will surface patterns that are easy to miss when scrolling through the .docx itself. The original anchor text is not preserved, so for any URL you want to investigate further, return to the source document, search the body for the destination, and note the surrounding sentence.
Where This List Helps and Where You Still Need the Original
The exported list is a precise inventory of safe external destinations, not a complete document audit. A visible address in the body of a document may be ordinary text that merely looks like a URL, and a link can live in a part of the package that the relationship file does not describe, such as a header, a footer, a comment, or an embedded object. Citations produced by reference managers and mail-merge fields can also store behavior the relationship file does not model. Treat the TXT report as a trustworthy starting point, then compare it against the visible document and your publishing requirements before publication.
The tool will not, and is not designed to, resolve redirects, request a website, check a domain's reputation, inspect a mail recipient, or decide whether a destination is safe to visit. Those checks belong to a separate, approved review process you should run on each address you intend to publish. A safer workflow is to preserve the original .docx, download the TXT report, compare the list with the visible source and your style guide, and run important URLs through your usual URL-checking pipeline.
Limits of a Local Relationship-File Extractor
Because the extractor reads only one part of the .docx package, it deliberately avoids the larger responsibilities of a full document parser. It does not attempt to render the document, count words, or interpret formatting. It does not run macros, evaluate fields, or follow embedded objects. The browser rejects malformed archives, oversized relationship XML, unsupported ZIP64 directory records, and packages that exceed the tool's stated local limits before a result is shown, which keeps a simple local extractor from turning into a general document reader. There is no batch crawl, no redirect expansion, no reputation score, and no spreadsheet export; the result is a reproducible list of safe-protocol external relationship targets and nothing more.
For most readers that scope is the right fit. A focused, conservative list you can paste into anything is more useful in practice than a fuzzy scrape that guesses at address formats and risks mislabeling internal references as external destinations. When you need a precise inventory of every external web link a .docx contains, the relationship file is the authoritative source, and a local extractor that reads nothing else is a direct way to surface it.