When the Attachment Isn't Attached: Hyperlinks in eDiscovery

By Claude and Gemini with Sid Newby | May 2026

Pull up a recent email production and try this: open a relevant message, find the underlined blue text in the body, and click it. Half the time, nothing happens. The link is dead text in a TIFF or a near-native PDF. The other half, the link launches a browser, hits a Google Drive URL, and either redirects to a sign-in page you do not have credentials for or returns a friendly notice that the document has been moved. The Bates stamp on the email is real. The thing the email is talking about — the spreadsheet, the deck, the contract — is not in the production. It is sitting on someone else's tenant, in some version that may not be the version that was sent, governed by retention rules that nobody on the case team has read.

This is what most modern document productions look like in May 2026. The email family is no longer self-contained. The "attachment" is a pointer, and the pointer leads somewhere the producing party may not fully control, in a format the platform was never designed to capture as evidence. Five years of federal magistrate rulings on this exact problem have produced a doctrinal split, three competing technical workarounds, and a collection cost line item that small firms cannot afford. Doug Austin at eDiscovery Today flagged a webinar on the topic this morning, and the surface area of the issue is now wide enough that the legal industry's standard answer — meet and confer about it — is no longer adequate.^[1]

The hyperlinked file question is not a niche edge case. It is the central architectural shift in business communications since email became discoverable, and it is breaking the categories of preservation, collection, and production that the Federal Rules of Civil Procedure were designed around.

What a Hyperlink Is Not

A traditional email attachment is a file. Bytes. The bytes travel inside the message, sit on the mail server alongside the headers, and get collected together when somebody pulls the mailbox. Microsoft Outlook calls this a .msg with embedded MAPI properties. Gmail calls it a MIME multipart message. Either way, the document and the email are one object on disk. The chain of custody is one chain. The hash covers everything. The producing party hands over a single file family with a clear parent-child relationship: email-with-attachment, attachment-of-email.

A hyperlinked file is something fundamentally different. The email contains a URL. The URL points at a file stored elsewhere — typically SharePoint, OneDrive, Google Drive, Dropbox, Box, or a third-party document management platform — and that file lives independently from the email. It has its own retention rules, its own access permissions, its own version history, and its own potential to be moved, renamed, edited, or deleted by users who never received the email at all.

Microsoft started defaulting to this behavior in 2020 when it shipped what it calls cloud attachments in Outlook. Click "Attach File" in modern Outlook on a document already in OneDrive or SharePoint, and Outlook gives you two choices: attach the actual bytes (a copy), or attach a link (a sharing URL with permissions inheritance). Most users pick the link. The link is faster, smaller, automatically updated when someone edits the source, and conveniently dodges the 25-megabyte mail-server attachment cap. Microsoft's support documentation explicitly recommends links over copies.^[2] Google made the same shift in Gmail, with hyperlinks to Drive becoming the default sharing pattern across Google Workspace deployments. Slack and Microsoft Teams chat messages use the same model — a chat attachment is almost always a link to a file living in a separate location, not the file itself.

The result is that the words email attachment and chat attachment, in May 2026, do not mean what they meant in 2015. They are statistically far more likely to be a URL than a file. And nobody asked the discovery community whether the change was acceptable.

Figure 1: How hyperlinked files break the email family. The traditional path on top keeps email and attachment together as a single artifact. The modern path on the bottom splits the email and the linked content into two separate collection problems with different retention, custody, and version rules.

The technical artifact people are calling a "modern attachment" is not actually an attachment in any of the senses Federal Rule of Evidence 901(b)(4) presumes when it talks about authentication of writings, or that Federal Rule of Civil Procedure 34(b)(2)(E) presumes when it talks about producing electronically stored information in the form in which it is "ordinarily maintained." It is a reference. It is a footnote in the email. Treating it as if it were the document itself requires a series of architectural decisions — which version, retrieved from where, by what process, on what date — that nobody has agreed on yet.

The Five-Year Doctrinal Split

The first federal court to publish a thoughtful opinion on hyperlinks-as-attachments was Magistrate Judge Katharine Parker in the Southern District of New York. Nichols v. Noom, Inc., decided in March 2021, involved Gmail-to-Google Drive hyperlinks at a wellness company.^[3] Plaintiffs wanted the linked Drive documents produced as part of the email families they linked from. Noom said no, that pulling and matching contemporaneous versions of every linked document would cost roughly $180,000 using Metaspike's Forensic Email Collector tool, and that the production was not proportional to the case.^[4]

Judge Parker agreed with Noom. The ruling was clean: a hyperlinked document is not an attachment. An attachment, she wrote, is "a necessary part of" the email — the link is not. Plaintiffs could request specific linked documents by Bates number and Noom would produce them, but the producing party was not obligated to rebuild every email family with its referenced Drive files.

That ruling held for about two years and shaped most early ESI protocols. Then the cases started to fragment.

In In re StubHub Refund Litigation (N.D. Cal. April 2023), Magistrate Judge Thomas Hixson ordered StubHub to produce linked documents as the parties had originally agreed in their ESI protocol, then — after StubHub's 30(b)(6) witness testified about how genuinely impossible it was at scale — modified the order on the basis that performance was infeasible.^[5] The case became a study in why protocol language written before the engineering team understood the ask is dangerous.

In In re Meta Pixel Healthcare Litigation (N.D. Cal. 2024), Magistrate Judge Lisa Cisneros held that hyperlinked documents are not the same as conventional attachments for family-relationship purposes, but that individual linked documents may still be requested and produced.^[6] A middle-ground ruling. Splitting the difference.

Then came Uber. The In re Uber Technologies, Inc. Passenger Sexual Assault Litigation MDL produced what is, as of May 2026, the most detailed federal ruling on hyperlinked file production.^[7] Judge Cisneros ruled in 2024 that hyperlinked documents are attachments under that case's ESI protocol, because the email and the linked document together "reflect a single communication at a specific point in time." Uber was ordered to capture metadata linking each hyperlinked Drive file back to its source email using a LINKBEGBATES field. Then in March 2025, the court issued a follow-on order distinguishing between Google Drive hyperlinks (technologically feasible to produce) and hyperlinks that had transitioned into Google Vault retention storage (not feasible at scale) and hyperlinks to public websites (URLs sufficient, no production required).^[8] The ruling created three tiers of treatment in a single case.

Two more 2026 rulings have continued the trajectory. In Yotta Technologies Inc. v. Evolve Bank & Trust (N.D. Cal. Jan. 22, 2026), the court again addressed modern attachments and reinforced the proportionality framework.^[9] In United Ass'n National Pension Fund v. Carvana Co. (D. Ariz. Jan. 12, 2026), Magistrate Judge John Boyle took a sample-and-test approach: plaintiffs select 250 representative responsive emails with hyperlinks, defendants run FEC re-collection on those 250 within ten days and produce the contemporaneous versions of the linked content.^[10] Sampling instead of full production. Borrowed straight from TAR-2 validation methodology.

Figure 2: The federal-court treatment of hyperlinked files has moved from a clean "links are not attachments" rule in 2021 to a tiered-by-platform, sampling-based set of approaches in 2026. There is no single national rule. The doctrine fragments by storage platform, by ESI protocol language, and by the specific feasibility evidence the producing party can put on the record.

The cases share a common feature: every single one turns, ultimately, on what a particular ESI protocol said and what the producing party's specific technical infrastructure could do. There is no off-the-shelf rule. Two parties facing the same factual situation can land in completely different places depending on whose order language got adopted in the meet-and-confer six months before anyone understood what they were agreeing to.

The $180,000 Question

The cost numbers in these cases tell the rest of the story. Noom's $180,000 estimate for FEC-based re-collection of Google Drive hyperlinks was the first concrete public figure on what producing modern attachments actually costs at scale.^[4] That number is now five years old. The data volumes have grown. The number of platforms involved has multiplied. The collection budget for a mid-sized matter where hyperlinked files are central to the dispute is substantially higher than $180,000 in 2026.

Metaspike's Forensic Email Collector — the tool Noom estimated against — is the most-cited specialized solution for this problem. It costs about $699 a year per licensed machine and works by re-driving authentication into Gmail or Microsoft 365 to re-pull contemporaneous versions of linked content matched to specific emails.^[11] Per-machine licensing means firms running collection at any volume need multiple seats. The labor cost — forensic specialists driving the tool, validating output, documenting chain of custody — is the dominant line item. Software is a rounding error compared to the people running it.

There are two real alternatives. The first is Microsoft Purview's cloud attachment retention labels, which Microsoft shipped as a preview feature for Microsoft 365 Premium eDiscovery and updated as recently as March 2026.^[12] The way it works: an organization creates a retention label, configures it to auto-apply to cloud attachments, and Microsoft's backend then preserves a copy of each file at the moment it is shared in any Teams chat or Outlook message. The shared version and the live version both end up in the review set, sharing a FamilyId with the parent email. This solves the version drift problem if — and only if — the organization configured the label policy before the litigation hold trigger. Retroactive preservation does not work. The version that was shared three years ago is gone if nobody told SharePoint to keep a copy.

The second alternative is what most enterprises are actually doing in 2026, which is nothing systematic. They are relying on collection vendors to write custom scripts against SharePoint and Drive APIs, matching emails to current versions, and disclosing in their cover letters that "current versions are produced where contemporaneous versions are not technologically feasible to recover." This is the de facto standard. It is not what most ESI protocols promise.

Table 1: Modern-attachment collection options and the asymmetry in who can afford each. Cost figures are practitioner estimates for matters in the 100,000-to-500,000 document range; specific figures vary heavily with platform mix, custodian count, and whether Google Vault transitions are involved. The $180,000 Noom figure cited in Nichols v. Noom was a 2021 Google-only estimate.^[4]

The cost asymmetry sets up the access-to-justice problem cleanly. A plaintiff's firm bringing a complex commercial case against a Microsoft 365 enterprise has three real options: hope the producing party voluntarily uses Purview correctly, demand FEC-based collection and try to win a fee shift, or accept current-version production with a written disclosure and hope nothing important changed between the email and the lawsuit. The defendant has a fourth option, which is to argue impossibility under the proportionality framework that Nichols established and watch the production scope contract on the way out the door. The mismatch between what the rules ask and what the technology costs is the whole game.

What the Vendors Actually Do

Vendor marketing has converged on the term modern attachments as a feature label.^[13] Most of the major review platforms — Relativity, Everlaw, DISCO, Reveal, Logikcull, Nextpoint — now advertise modern-attachment handling. The marketing copy is uniformly confident. The implementations are uniformly partial.

What review platforms actually do, end to end, is host the linked file (once collected) and link it to its source email through a metadata field — usually some variant of LinkedAttachmentBegBates or ParentLinkID or, after Uber, LINKBEGBATES.^[7] The hard part is not display. The hard part is collection — getting the right version of the linked file out of the source platform — and that work happens upstream of the review tool. The review platform can only display what the collection process delivers.

Slack data is the worst case. Slack files are objects in Slack's storage system rather than the user's mail server, with their own access permissions and their own versioning. Pulling a contemporaneous version of a file shared in a Slack channel three years ago requires either Slack's enterprise eDiscovery API or a third-party connector — and even then the file's metadata may not survive intact through the export process. The Sedona Conference's April 2025 Commentary on Discovery of Collaboration Platforms Data devoted significant attention to this problem and warned that "the explosive growth of these platforms has created significant legal and technical challenges for organizations, lawyers, and the judiciary."^[14] Translation: the vendor stack is behind, the rules are behind, the case law is barely catching up, and everybody is doing this on the fly.

Figure 3: The actual collection decision tree for a hyperlinked file in 2026. Green paths are defensible. Yellow paths are defensible only with explicit disclosure. Red paths require the producing party to admit on the record that the linked content was unrecoverable. Most productions today contain a mix of all three, and the proportions are usually buried in the cover letter rather than the production volume metadata.

The vendor message that "we handle modern attachments" almost always glosses over which color of path the platform actually supports. Every review platform handles the green path — load files with parent metadata — because that is just data ingestion. Far fewer platforms have an opinion about yellow. None of them solve red, because red is a fact about the source data, not a fact about the review tool.

What This Means for Your ESI Protocol

The practical guidance in 2026 starts with the meet-and-confer. ESI protocol language drafted in 2021 — when Nichols was the only published opinion — is dangerous in 2026, because most of those protocols treat hyperlinks either as a footnote or not at all. The producing party that signs an ESI protocol with vague language about "attachments" can find itself on the wrong end of a StubHub-style ruling six months later when the plaintiff argues the linked content was always part of the deal.

Five questions to put on the table at the 26(f):

1. Are hyperlinked files in scope at all? Nichols still stands as a defensible default-no for proportionality reasons, but courts have moved away from the bright-line rule. Document whichever way you go.

2. What platforms are involved? Microsoft 365 with Purview retention labels is not the same problem as Google Workspace mid-Vault transition, which is not the same problem as Slack Enterprise. The protocol should specify per-platform treatment.

3. Contemporaneous version, current version, or both? Make the parties commit on the record. The version drift problem is real and disclosing it after the fact is awkward; Carvana's sampling approach should be a template, not an exception.

4. Who pays? The producing party's default obligation under proportionality is shifting. Cases like Carvana are putting limits on production volume by ordering sample-based methodology. Plaintiffs who want full FEC collection should expect to argue for cost shifting or accept the sample.

5. What metadata field carries the parent-child link? LINKBEGBATES is becoming a de facto standard since Uber, but the field name needs to be in the protocol or the load files will be ambiguous on the back end.

The discipline here is the same discipline that worked when ephemeral messaging hit federal courts five years ago: assume the technology will not cooperate, document everything, and put your assumptions on the record before you need them. The ESI protocols that survive contact with hyperlinked-file disputes are the ones that read like operating manuals — specific platforms, specific versioning rules, specific metadata fields, specific cost-allocation language. The ESI protocols that explode are the ones written in generalities.

Where This Goes Next

The hyperlinked file problem is going to get worse before it gets better, because the underlying business behavior is irreversible. Cloud-stored documents shared by reference are how work gets done now. The 2020 default in Outlook, the default in Gmail, the default in Slack and Teams — those defaults are not changing back. The collaboration platforms have economic incentives to make linking easier and the friction of attaching actual files higher. Every major productivity platform shipped after 2020 treats files as URLs first and bytes second.

What changes is whose problem it is. Right now the problem belongs to the producing party, because the rules of civil procedure put preservation and production obligations on the producing party. But as Microsoft Purview retention labels and similar enterprise tools mature, the locus of responsibility quietly shifts back to the original platform vendor. If Microsoft preserves the shared-version snapshot by policy, it is Microsoft's metadata that ends up in evidence. If the policy is misconfigured, it is Microsoft's policy gap that the producing party has to explain. The same shift is happening with Google Workspace via Vault, with Slack via the Enterprise Grid eDiscovery API, and with Salesforce, Notion, and the rest of the SaaS stack as their own retention features mature.

The longer-term question is whether the federal rules catch up. The 2015 amendments to the FRCP — the ones that gave us the proportionality framework everyone is leaning on now — predated cloud attachments by half a decade. They were written for an email-and-PST world. The Sedona Conference is closer than the Advisory Committee, and the Sedona commentary on collaboration platforms is going to become the practitioner default while the rules grind through revision.^[14] But the practical reality is that the ESI protocol — a contract between the parties, written for one specific case — has become the most important document in the entire dispute about how hyperlinked files get treated. The rules let the parties bargain. The parties bargain in the dark. The bargain becomes binding when the production starts.

For litigation teams without enterprise budgets, the operational problem is straightforward: you cannot afford FEC at scale, you cannot retroactively configure Purview, and you are going to be working with current-version production in most cases. The defensible response is to disclose that on the record at the meet-and-confer and not pretend otherwise. The undefensible response is to pretend the linked content has been "produced" in the same sense as a traditional attachment when in fact what the other side has received is whatever version of a Drive document happened to exist on the day collection ran.

A small plaintiff's firm running a $2 million commercial case against a M365 enterprise defendant is not going to win the FEC-collection argument on the merits in 2026. Nichols still gives the defendant a clean proportionality answer. What that firm can win is the disclosure argument — tell us, on the record, what version of these linked files you actually produced, and what the version drift looks like for the population you did not re-collect. That argument is winnable today. It is also the only argument that scales down to matters where the price tag of doing it the FEC way is the case itself.

The phrase chain of custody used to mean something narrow. The investigator handed the bag to the lab tech who handed the bag to the prosecutor. In the modern productivity stack, the bag is open at both ends, the document keeps changing on its way through the chain, and the labels on the outside of the bag may or may not still match the contents. Civil litigation is not yet doing the work to admit that openly. Eventually, it will not have a choice.

Related Reading

• Hybrid Search in eDiscovery: How AI Retrieval Actually Works
• Copilot Is Everywhere: How Microsoft's AI Sprawl Is Creating the Biggest eDiscovery Blind Spot Since BYOD
• Caught Between Courts and Continents: The 2026 Guide to Cross-Border eDiscovery