Excel Hyperlinks: How xl/worksheets/_rels/sheet*.xml.rels Preserves UNC Paths, Mailto Addresses, SharePoint URLs, and Teams Chat Links That Survive Cell Deletion and Reveal Internal Network Topology

Where Hyperlinks Live Inside an XLSX

Excel splits hyperlink storage across two cooperating XML parts. The worksheet itself contains a <hyperlinks> element — usually sitting just before the <printOptions> or <pageMargins> blocks — that lists every cell range that carries a link, the optional tooltip, and a relationship identifier:

The first two entries each carry an r:id attribute that resolves through the worksheet’s sibling relationship file at xl/worksheets/_rels/sheet1.xml.rels. That file is where the actual URL lives:

The third entry in the worksheet XML uses a location attribute rather than a relationship identifier. That is the in-workbook anchor form: it jumps to a cell on another sheet by name. Anchor hyperlinks never appear in the rels file because they have no external target; they live entirely in the worksheet XML and reference sheet names directly. The two storage paths matter because cleanup pipelines have to handle both: deleting only the worksheet’s <hyperlinks> block leaves orphan relationships behind, and deleting only the relationship file leaves the worksheet block pointing at relationship IDs that no longer resolve.

UNC Paths: A Map of the Internal File Server Estate

The single richest category of hyperlink leakage is the UNC path. When an author drags a file from a Windows shared drive onto an Excel cell, the resulting hyperlink target uses the file:// scheme followed by the server name, share name, and full folder hierarchy down to the destination file. A workbook that contains a few dozen such hyperlinks is shipping a small map of the organisation’s file server topology:

A reader who has never set foot inside the organisation learns, from those seven lines alone, that there is a regional file server estate split between EMEA, US, and London locations; that Finance, Audit, Tax, Treasury, and Legal each operate from named subdirectories on those servers; that the Legal department is running an M&A project codenamed Atlas with a dedicated data room; that Treasury hedges EUR/USD on a quarterly cycle and tracks counterparty risk in a separate matrix; and that the corporate DNS suffix is acme.local. The visible cell text in the workbook usually reads something like “CFO close plan” or “Audit PBC” — nothing that hints at the depth of the underlying network topology.

UNC paths persist even when the linked file no longer exists. The relationship part records the target as a string; Excel never validates it on save. A workbook that points at files behind a long-decommissioned file server keeps the dead path intact in its rels file forever. The leaked metadata is therefore not just the current topology but the historical topology — every server the organisation has retired, every folder it has reorganised, every project code it has finished archiving.

mailto: Links and the Quiet Directory Leak

The second category of hyperlink target with high leakage value is the mailto: link. Authors create them by typing an email address into a cell or by pasting from an Outlook address book. Excel stores the entire mailto: URI, including optional ?subject=, &cc=, &bcc=, and &body= components:

The first two mailto entries leak an individual name (Janet Maller) and an internal distribution list (legal-emea@acme.com) paired with the CFO’s direct email. The third entry leaks the existence of an external counsel relationship, a redline-versioning convention (v9 means the document has been through at least nine rounds), and an e-discovery hold address that is BCC’d on outgoing legal correspondence — a strong indicator that the organisation is in active litigation. The fourth entry confirms the external auditor by domain. Each of those facts is interesting in isolation; collected from a single workbook, they sketch a small org chart.

Email addresses also fingerprint the organisation’s naming convention. janet.maller@acme.com follows a first.last pattern that lets an investigator generate plausible addresses for any other employee they know the name of — useful for phishing or for cross-referencing with leaked credentials. A second hyperlink to jmaller@acme.com instead would suggest a parallel firstInitial+last alias scheme; once both forms are observed, the alias structure is established.

SharePoint, OneDrive, and the Tenant Fingerprint

Modern hyperlinks pasted from a browser tab open on SharePoint or OneDrive carry the full HTTPS URL of the underlying document, complete with the tenant identifier, site collection, and document ID. The URL is much more informative than a UNC path because it is signed, namespaced, and tied to a specific Microsoft 365 tenant:

The hostname acmecorp.sharepoint.com reveals the tenant slug. The path segment /sites/Finance-CFO/ is the SharePoint site URL chosen by whoever provisioned the site. The /personal/jmaller_acme_com/ path on the OneDrive variant exposes a specific user’s personal site URL, which embeds their email address with the at-sign replaced by underscores. The third entry confirms the existence of a SharePoint site dedicated to the M&A project codenamed Atlas. All three URLs are stable identifiers: anyone with the same tenant access can paste them into a browser and try to open the underlying files.

Pair this layer with the custom XML parts that carry sensitivity-label GUIDs and the persona IDs that resolve commenter identities back to a tenant, and a workbook frequently identifies its originating Microsoft 365 tenant by three independent fingerprints. Even a partial cleanup that removes one or two of those fingerprints leaves the others in place.

Teams Deep Links: Channel Structures in the Open

Microsoft Teams uses a distinctive deep-link URL format for chat messages and channel conversations. Authors who paste a link from Copy link to message in Teams into an Excel cell end up shipping the entire URL through the hyperlink layer:

The tenantId parameter is the same Microsoft Entra ID GUID that appears in MSIP sensitivity labels. The groupId identifies the underlying Microsoft 365 group, which in turn names the Teams team. The channel name is in the URL path in URL-encoded form. The second hyperlink reveals that Project Atlas is organised into numbered workstreams — structural information about how the project is run that would not otherwise appear anywhere in the workbook’s visible content.

Teams chat hyperlinks are especially valuable to investigators because they are stable, durable references into a private conversation. Even without access to the underlying Teams content, the URL itself documents the existence of the conversation, names the channel, identifies the tenant, and frequently shows a timestamp suffix that lets a reader place the original message on a timeline.

The tooltip Attribute: Custom Hover Text as Quiet Annotation

Every <hyperlink> element supports an optional tooltip attribute that holds the screen-tip text the author typed into the Insert Link dialog. The tooltip is presented when a user hovers over the cell and otherwise stays out of sight. Because it is invisible during normal viewing and never gets rendered into the cell’s display text, authors routinely use it to leave short editorial notes for themselves:

Each tooltip is a small candid annotation about the linked document. The first explicitly tags the target as confidential and pre-board, indicating that a more polished version exists somewhere else. The second documents the existence of a parallel data-room copy with different (presumably sanitised) numbers — an admission that two versions of the same file are in circulation. The third names individuals and an internal handoff sequence. None of those facts is in the visible cell text; all of them are in the worksheet XML as plain UTF-8.

Display Text vs Target URL: The Bait-and-Switch Pattern

Hyperlinks carry two separately editable pieces of text: the cell value (the “display text”) and the relationship Target URL. Excel does not enforce any relationship between them. An author can show https://acme.com/pricing in the cell while the actual hyperlink target is file://fs-emea-01/Finance/CFO/internal-pricing-floors.xlsx, and the user clicking the cell would open the internal file. The pattern is sometimes used innocently — an author wants a friendly label on a cluttered internal URL — and sometimes deliberately, to disguise the real destination from anyone reading the workbook in print form or in a non-Excel viewer.

From a metadata-leakage perspective, the display/target divergence is doubly informative. The display text tells a reader how the author summarised the destination — what label the author wanted readers to see. The target tells a reader where the link actually goes. When the two disagree, the difference is a small commentary on the author’s intent. An investigator who sees a cell labelled “Vendor pricing” and a target of /Finance/CFO/internal-margin-analysis.xlsx reads both: the author was trying to send the recipient to one document while keeping the label generic enough not to attract attention.

Anchor Links to Sheets That No Longer Exist

Anchor hyperlinks — the in-workbook variant with a location attribute — reference cells on other worksheets by name. The hyperlink layer does not validate that the referenced sheet still exists. A workbook whose author has deleted the Forecast sheet at some point in its history but never tidied up the index page still carries hyperlinks pointing at Forecast!A1:

A reader who knows the workbook only contains an Index, a Pipeline, and a Notes sheet now knows it once also contained a Forecast sheet and a DealRoom_Atlas sheet, each of which the author considered important enough to add to the index. The same evidence appears in the defined-names symbol table and in the calculation chain, but the hyperlink layer is the easiest of the three to read and frequently the most deliberate — sheets named in the hyperlink layer were sheets the author considered navigable, which usually means they contained content rather than scratch work.

Orphan Relationships: Why Remove Hyperlinks Does Not

Excel exposes a Right-click > Remove Hyperlink command on a single cell and a Home > Clear > Remove Hyperlinks command on a selection. Both commands have a well-defined semantic in the UI: the link is removed from the cell, the cell’s formatting reverts to normal text, and a click no longer opens the target. The XML side of those commands is less tidy. Excel removes the <hyperlink> entry from the worksheet’s <hyperlinks> block but does not always remove the corresponding <Relationship> entry from the worksheet’s rels file. The result is an orphan: a relationship record pointing at a URL that no longer has any worksheet element referring to it.

The same orphan pattern shows up in several common workflows. Copy-pasting cells with hyperlinks across worksheets creates relationship entries in the destination sheet’s rels file that survive even after the cells are subsequently deleted. Round-tripping a workbook through a non-Excel tool — openpyxl, a third-party converter, a Power Automate flow — frequently writes back a rels file that has accumulated relationship entries from earlier passes without the matching worksheet references. Cloud co-authoring sessions can preserve relationship entries from any participant’s session, even if the cell that triggered the relationship was edited away by someone else.

Orphan relationships are durable evidence that a hyperlink once existed at some point in the workbook’s history. They do not appear anywhere in the Excel UI — there is no “orphan hyperlinks” pane — and they survive every standard cleanup command. The only reliable way to detect them is to compare the relationship IDs cited by the worksheet’s <hyperlinks> block against the IDs present in the corresponding rels file and report on the set difference.

Copy-Paste Contamination From Browsers

A second common source of hyperlink leakage is browser-to-Excel copy-paste. Modern browsers place several formats on the clipboard simultaneously — plain text, HTML, RTF — and Excel preserves the rich form by default. When an author copies a table out of a web page or out of a SharePoint list and pastes it into a workbook, every linked cell in the source becomes a hyperlink in the destination, complete with the original URL targets:

Each URL exposes the existence and hostname of an internal system: Salesforce, Jira, Confluence, GitLab, Workday. The Salesforce opportunity ID and the Jira ticket ID are stable identifiers; an investigator with access to either system can look up the underlying record directly. The Confluence URL reveals an internal page name (Q4+Close+RACI) that documents the existence of a close-process RACI matrix. The GitLab URL exposes a repository path and a branch name. The Workday URL reveals the tenant identifier and the navigation path through the HR system. None of those links is part of the data the author intended to share; all of them are part of the data the recipient now has.

The same mechanism applies to copy-paste from Outlook, Teams, OneNote, and any other Microsoft 365 app whose clipboard payload includes a deep link. The pasted cells frequently look perfectly innocuous in Excel — just text values that happen to be underlined — while the relationship file fills up with internal system URLs.

Reading the Layer Without Excel

Enumerating the hyperlink layer requires nothing more than a ZIP reader and an XML parser. The most direct approach walks every xl/worksheets/_rels/sheet*.xml.rels file and emits every relationship whose type is hyperlink:

The script prints one line per relationship: the rels file it lives in, the relationship ID, and the target URL. For a workbook that has been through dozens of edits the output is frequently surprising even to the author — old SharePoint URLs from re-organised sites, mailto addresses for people who have left the company, file:// paths to servers that were decommissioned years ago. Each one is now in the XML, on the way to the recipient.

For ad-hoc inspection, renaming the XLSX to .zip, expanding it, and grepping for Target=, tooltip=, file://, mailto:, and sharepoint.com across the unzipped tree usually surfaces every interesting hyperlink in under a minute. The same workflow is what an opportunistic investigator runs the moment a workbook lands in their inbox.

What an Investigator Reconstructs From the Layer

In a single sweep through the hyperlink layer of a moderately-used workbook, a reader typically extracts:

• A map of the organisation’s internal file-server estate — hostnames, share names, departmental folder structures — from every file:// or \\-prefixed UNC target.
• Individual email addresses, alias conventions, and internal distribution lists from every mailto: target, including subject lines, CC and BCC lists, and body drafts.
• The Microsoft 365 tenant slug and a sample of site collection names from every *.sharepoint.com URL.
• A user’s OneDrive personal site URL (which embeds the email address) from every -my.sharepoint.com/personal/ target.
• The tenant Microsoft Entra ID GUID, group IDs, and channel names from every Teams deep link.
• Hostnames of internal systems — Salesforce, Jira, Confluence, GitLab, Workday, custom apps — from URLs accidentally pasted in from browser tabs.
• Editorial annotations the author considered private from every tooltip attribute, including version markers, confidentiality labels, and individual names.
• Names of worksheets that have since been deleted from location= attributes on anchor hyperlinks.
• Display-text-vs-target divergences that hint at the author’s intent in disguising the real destination.
• Historical state of the network topology from orphan relationship records that survived Remove Hyperlinks.
• Fingerprints of third-party tooling and macro-based exporters from rels files that have accumulated unreferenced entries.

The first eight categories are content. The last three are tooling and process fingerprints. Together they typically reveal more about the organisation’s internal architecture, working relationships, and document hygiene than the visible data in the workbook does, because the hyperlink layer is where authors document connections rather than values.

Why Document Inspector Leaves Most of It Alone

Microsoft’s Document Inspector includes a check for hyperlinks, but the check is narrowly scoped. It reports the number of links to files and email addresses and offers a Remove All button. The button operates on the worksheet’s <hyperlinks> block and on cells whose displayed text is the same as the link target. It does not always sweep the relationship files for orphan entries, does not touch the tooltip attributes that remain on any links it has not removed, and does not address anchor hyperlinks pointing at deleted sheets at all.

The result is consistent with the pattern we have seen for data-validation rules, conditional-formatting rules, and the table layer: Document Inspector handles the headline cases and trusts the user not to care about the long tail. A workbook that has been “inspected and cleaned” routinely still ships every file://, mailto:, SharePoint, OneDrive, and Teams URL it ever carried, plus every tooltip annotation, plus every orphan relationship record.

How to Actually Strip the Layer

Reliable cleanup operates at the XML level and touches both halves of the layer in a single coordinated pass. The minimum sweep for a workbook bound for external release removes every <hyperlink> child from every worksheet’s <hyperlinks> block, removes every relationship of type hyperlink from every xl/worksheets/_rels/sheet*.xml.rels file, and rewrites the worksheets to drop any remaining empty <hyperlinks> wrapper elements:

The openpyxl library automates much of this: assigning None to cell.hyperlink for every cell on every worksheet and re-saving the workbook removes the worksheet-side elements. The matching relationship cleanup runs against the rels file directly to catch orphans that openpyxl has not been told about. Excel opens the resulting workbook without complaint and shows the former link cells as plain text values, with no underline and no hover behaviour.

For workbooks where some hyperlinks are essential — an internal index page that genuinely needs its anchor links, an external page that legitimately needs to point at a public document — the cleanup pass should enumerate the surviving relationships and validate each one against an allowlist of target domains. Any link whose target does not match the allowlist is stripped automatically. The allowlist is usually short: the organisation’s public website, perhaps the customer portal, and nothing else.

Hyperlinks as Part of a Coordinated Cleanup

Hyperlinks interlock with several other metadata layers that should be touched in the same pass. The external-links table shares the same TargetMode="External" mechanism through a different relationship type and frequently points at the same internal file servers. The Power Query connections and queryTable parts encode similar server names and credentials in M expressions and connection strings. The sensitivity-label GUIDs and the persona IDs in modern comments fingerprint the same tenant that SharePoint and Teams hyperlinks identify. Stripping the hyperlink layer without coordinating with those siblings leaves a workbook that has visibly been edited rather than a workbook that is genuinely clean.

The same coordinated pass should also reach into the defined-names symbol table — some named ranges store URL targets indirectly as hyperlink jump destinations — and into the drawing and image relationships, which can carry their own externally targeted hyperlinks attached to shapes and pictures rather than to cells. A cleanup that addresses only cell-level hyperlinks but ignores image-level ones is incomplete in exactly the same way that a sweep of the worksheet block but not the rels file is incomplete.

The Link Layer Is a Connection Map

Hyperlinks look like cell formatting and end up acting like a connection diagram for the organisation. Every UNC path is a fragment of file-server topology. Every mailto address is a fragment of the directory. Every SharePoint URL is a fragment of the tenant’s site collection map. Every Teams deep link is a fragment of the team-and-channel hierarchy. Every tooltip is a candid editorial note. None of those fragments appears in the cell’s rendered display text; all of them are in the XML as plain UTF-8, indexed by relationship ID, and trivially extractable with a ZIP reader and a five-line script.

For workbooks staying inside an organisation, hyperlinks are exactly what they were designed to be: a navigation convenience that connects spreadsheets to the rest of the working environment. For workbooks crossing the perimeter, they are one of the most concentrated pieces of internal architecture documentation the file is ever going to carry. The only durable defence is to rewrite the layer as part of a coordinated cleanup that touches both the worksheet <hyperlinks> blocks and the matching rels files, validates surviving entries against a short allowlist, and reads every tooltip as the editorial annotation it really is — leaving recipients with the values the author intended to disclose and none of the connection map they thought no one would ever see.