PDF vs URL: which to send a client in 2026

2026-05-24·12 min readclient-deliverysharing

By Sankalp Agarwal · Founder, Anchorify

For most client deliverables in 2026, a URL is the more practical choice. Not because PDFs are broken, but because the six dimensions that actually matter for client delivery -- file size, mobile rendering, freshness, analytics, accessibility, and professionalism -- consistently favor a web page over an attachment. The answer shifts in a few specific cases, and this piece maps all of them.

Email attachment limits make large PDFs unreliable

Gmail caps personal accounts at 25 MB per attachment, and Microsoft 365's practical per-message limit sits between 35 and 50 MB for most tenants. Those numbers sound generous until your deliverable includes charts, embedded images, a logo header, or multiple sections with screenshots. A 20-slide strategy deck with good graphics can easily land at 18-22 MB. A report with several data visualizations can push past the Gmail limit entirely.

When a Gmail attachment exceeds 25 MB, Gmail does not reject the send with an error. It silently replaces the attachment with a Google Drive link. The recipient clicks what they think is a direct file and lands in Drive, where they may or may not have permission to open it. That's the worst of both worlds: the sender thought they sent a file, the recipient gets a permission dialog.

URLs have no size limit from the sender's side. The document lives on a server; the client gets a link. The rendering cost is theirs -- on their device, using their bandwidth -- but the sender never has to think about it.

Mobile rendering: the app-switch problem

On mobile, a PDF attachment forces the recipient into a system viewer. On iOS this is Quick Look, which opens as an overlay before handing off to Files or a PDF reader app. On Android, behavior varies by manufacturer. Samsung devices open PDFs in their own viewer; Pixel phones hand off to Google Drive. In all cases, the recipient leaves the email thread and lands in a different app context.

A URL opens in the device's browser. No app switch. The recipient stays in the same reading context they were already in. Browser rendering handles zoom, text reflow, and system font scaling automatically.

Two-column PDF layouts often break at phone width. A PDF formatted to look clean at A4 becomes a horizontal scrolling problem at 390px. Responsive HTML pages, by design, reflow to the screen width. For recipients reading on their phone during a commute or between meetings -- which is a realistic scenario for a client getting your report -- the format difference is noticeable.

SEO and discoverability: HTML wins on every signal

Google indexes PDFs and can read their text content. A PDF hosted at a stable URL can rank in search results. That said, HTML pages carry signals PDFs structurally cannot.

Google cannot execute JavaScript in a PDF. This means no application/ld+json structured data blocks, no FAQ schema, no Article schema. Structured data is one of the cleaner signals for AI-powered search results (Google's AI Overviews, Perplexity, ChatGPT browse mode).

PDFs cannot carry Open Graph or Twitter Card metadata. When someone shares a PDF link on Slack or LinkedIn, the platform gets no preview image, no description, no title card. A URL served by a proper web page generates a rich link preview.

Canonical URL control is straightforward for HTML (a single <link rel="canonical"> tag). For PDFs, managing duplicate content or redirecting an old PDF URL requires server-level configuration most senders don't have access to.

For a deliverable meant only for a specific client, discoverability is irrelevant. But for a public report, a published template, or a guide you want to rank -- HTML is the only sensible format. See how this plays out against the Google Docs alternative for the full comparison.

Freshness: a PDF is frozen, a URL is not

Every PDF is a snapshot. Once exported and sent, the content is fixed. Fixing a number, correcting a sentence, adding a footnote, or updating a data point requires a new export and a new send. The client now has two versions of the file. Version confusion is not a hypothetical -- "which one is current, the one from March 3rd or March 7th?" is a real question that wastes everyone's time.

A URL can be updated in place. The source file changes, you republish, the URL stays the same. The client's bookmark still works. The link in their email still works. No re-send required.

This matters most for recurring deliverables. Monthly client reports are the clearest example. Send the same URL every month with updated content, and the client builds a habit around that link. If they missed last month's send, they can find it themselves. The SEO report template works exactly this way: write the report as a markdown file, publish it, send the URL. Next month, update the file and republish -- same URL, no permission dialog.

Version history compounds this advantage. A URL-based system can show diffs between versions and let you restore earlier states -- see how versioning works in Anchorify. A folder full of report-v1.pdf, report-v2-FINAL.pdf, report-v2-FINAL-edits.pdf does not.

Accessibility: most PDFs fail without extra work

An untagged PDF is inaccessible to screen readers. Tags provide the structural layer that assistive technology depends on: headings, links, lists, tables. Without that layer, a screen reader processes the PDF as an undifferentiated stream of text, or fails entirely on complex layouts.

Adding accessibility tags to a PDF requires Adobe Acrobat Pro -- not the free Acrobat Reader. The workflow involves enabling the Tags panel, using the Reading Order tool, adding alt text to images, and verifying table headers. Most senders do not do this, because most senders don't know it's required and don't have the tool.

Common PDF accessibility failures include:

• Images with no alt text
• No heading structure (all text treated as body copy)
• Tables with no marked header rows
• Links that don't describe their destination

HTML rendered in a browser is natively accessible when the underlying markup is correct: semantic heading tags, alt attributes on images, descriptive link text. No export step, no separate tool, no remediation workflow.

This matters beyond "being considerate." If any of your clients are in enterprise procurement, government contracts, or financial services, they may have internal accessibility requirements. An untagged PDF can fail those requirements automatically.

Analytics: PDFs are a black box

A PDF that you attach and send gives you zero data on what happens afterward. You know it was sent. You don't know if it was opened. You don't know if the recipient got to page three. You don't know if they forwarded it to a decision-maker who read it for 20 minutes.

PDFs cannot execute JavaScript. All modern analytics tools (GA4, PostHog, Mixpanel, Plausible) work by injecting a JS snippet that fires events. No JS execution, no events. Workarounds exist -- you can track the link click before the download starts -- but that tells you the file was downloaded, not read.

A URL delivered through a web application can track opens per visitor, time on page, scroll depth, and return visits. For a B2B deliverable -- a proposal, a strategy document, a project quote -- that data is commercially valuable. Knowing a prospect spent 14 minutes on the proposal and returned to the pricing section twice is a different sales signal than knowing you sent the PDF on Tuesday. See the analytics documentation for what Anchorify tracks per share.

The professionalism question

PDFs feel professional because they've been the default format for formal deliverables for about 30 years. The association is real: a PDF says "this is final, this is complete." But that association is built on familiarity, not on any design property unique to PDFs.

A well-rendered URL is equally credible. The risk is the opposite: a raw GitHub Gist URL, a naked Google Docs share link, or a long Dropbox URL looks unpolished. The format isn't the problem -- the rendering is. A purpose-built share page with clean typography, your branding, and a stable domain at least matches PDF professionalism, and for tech-forward clients it often exceeds it.

The question worth asking is whether the format serves the client or serves the sender's comfort with the familiar. For consultants and small agencies sending recurring reports, the answer usually points toward the URL once the rendering is good enough.

PDF vs URL: feature comparison

The table below maps each delivery dimension directly. Most cells have a clear winner; a few are context-dependent.

When PDF still makes sense

A URL is not always the right answer. Three cases favor a PDF:

Legal and compliance documents. Contracts, tax forms, audit reports. These are meant to be frozen at a point in time. The immutability of a PDF is the feature, not the bug. A signed contract should not update in place.

Offline-first use cases. If your client needs to read the document on a plane, print it, or file it without internet access, a PDF is the right tool. URLs require connectivity.

Branded print deliverables. A brand deck, a physical brochure, a print-spec document. PDFs preserve exact typography and print fidelity in ways web pages cannot.

Outside these three cases, the advantages tilt consistently toward a URL.

Frequently Asked Questions

Is it better to send a PDF or a link to a client?

For most recurring or updatable deliverables, a URL is better. It has no attachment size limit, renders natively on mobile, can be updated without a re-send, and gives you analytics on whether the client actually read it. PDF is the better choice for legally frozen documents (contracts, signed agreements) and anything that needs to be printed with exact fidelity. For monthly reports, proposals, strategy documents, and guides, a URL is more practical in nearly every dimension.

Can Google index a PDF the same as an HTML page?

Google can read text inside a PDF and index it for search. What it cannot do is execute JavaScript, parse structured data like JSON-LD schema, or follow canonical URL directives the same way it does for HTML. In practice, an HTML page with proper schema markup, an Open Graph image, and a canonical tag gives Google more signals and tends to perform better in both traditional search results and AI-generated answers. If discoverability matters for the deliverable, HTML is the right format.

How do I share a large document without hitting email attachment limits?

The simplest option is a URL. Publish the document to a web service and send the link. The recipient opens it in their browser; you never have to think about file size. If you need to send a PDF specifically, use Google Drive, Dropbox, or OneDrive to share a link to the file rather than attaching it directly -- most email clients will auto-upgrade the attachment anyway once you exceed 25 MB.

Are PDFs accessible to screen readers?

Only if the PDF has been tagged using Acrobat Pro. An untagged PDF cannot communicate document structure to a screen reader. Tags provide the heading hierarchy, link destinations, image alt text, and table headers that assistive technology requires to navigate the document. Adding tags requires Acrobat Pro (not the free Reader) and deliberate remediation of images, tables, and layout. HTML pages rendered in a browser are natively accessible when the underlying markup uses semantic tags correctly.

How do I send a deliverable that I can update later without re-sending?

Publish it at a URL instead of attaching a file. When you update the source document and republish, the URL stays the same -- the recipient's link and bookmark still work, and the content reflects the latest version. This is the core use case for tools like Anchorify: one command publishes a markdown or text file at a stable URL, and the same command updates it in place next time. Full setup is in the getting started guide.

Sources

• Gmail attachment size limits -- Google Support documentation for Gmail personal accounts.
• Creating Accessible PDFs -- WebAIM guide on PDF tagging, screen reader compatibility, and Acrobat Pro workflow.
• Introduction to Web Accessibility -- WebAIM overview of why accessible documents matter and the gap between HTML and PDF for assistive technology users.

Anchorify turns any markdown file into a shareable URL with one command. Publish your next client report or deliverable at a stable link, update it in place next month, and see who read it. Free during beta -- sign in at anchorify.io.

Last updated: 2026-05-24