PDF to link: turn any PDF into a shareable URL.

If you just want a link and you want it now, skip the theory and pick one of these three. Each takes under a minute, none costs anything, and each hands you a URL you can paste into an email, a chat message, a QR code, or an anchor tag on your own site.

Google Drive is the fastest if you already use Gmail. Upload the PDF, right-click it, choose Share, flip the general access dropdown to Anyone with the link, then copy the URL. The link opens the file in Drive's preview viewer — good for read-only sharing and works on any device without a Google account on the other end.

Dropbox is the fastest if you want a URL that looks clean and predictable. Drag the file into your Dropbox folder, click Share, pick Create link, and copy. The default link opens Dropbox's viewer; swap ?dl=0 for ?dl=1at the end and the same URL becomes a direct download — the pattern is worth remembering, it's covered in section 06.

A file-transfer service like file.io or tmpfiles.org is the fastest if you need to share once and don't want anything left over. Drop the PDF on the page, get a URL back, send it, done. These links expire — sometimes after one download, sometimes after a few days — which is a feature when you want the file to disappear on its own and a bug when you don't.

For anything else — a permanent URL on your own domain, a direct-download link that respects Content-Disposition, or a link you can rotate the file behind without changing the URL — read on. The rest of this guide is the trade-off menu.

Google Drive is the default answer for most people, and there are good reasons for that. Fifteen gigabytes of storage on the free tier, no separate account to create if you already have Gmail, and the resulting link works on any device without the recipient needing a Google account of their own — provided you set the permission correctly.

The click path is short. Open drive.google.com, drag the PDF into the window, wait for the upload to finish, right-click the file, and choose Share. In the panel that opens, look at the bottom section labeled General access and change it from Restricted to Anyone with the link. Then click Copy linkand paste. That's it.

The URL you get looks like https://drive.google.com/file/d/<file-id>/view?usp=sharing. Opening it lands the recipient on Drive's built-in PDF viewer, where they can page through the document, download it with the toolbar button, or open it in their own Drive.

Two catches worth knowing. First, Drive links are viewer links, not direct-download links — see section 04 for the difference and section 06 for the exact URL surgery that turns a Drive viewer link into a direct-download URL. Second, the link is only as permanent as the file. If you delete the PDF or move it to a folder with different sharing, the URL breaks. For long-lived public files, either leave the original alone or move up to a host that lets you keep the URL stable while swapping the file underneath — covered in section 05.

If Google Drive isn't your default, you almost certainly already have one of these three. They all do the same job — store a file and hand you a public URL — and they all have small differences that matter once you start using the link for real work.

Dropbox gives you 2 GB free. Right-click the PDF in the desktop app or the web UI, choose Share, select Create link, and copy. The URL ends in ?dl=0, which opens Dropbox's web viewer. The nice property is that Dropbox exposes a documented URL toggle: change dl=0 to dl=1 and the same URL is a direct download. That predictability makes Dropbox the friendliest of the three for QR codes, email buttons, and anywhere you want the click to trigger a download.

OneDrivegives you 5 GB free, more if you have a Microsoft 365 subscription. The share button generates a link that opens in OneDrive's viewer. You can toggle between view and editpermissions in the sharing panel, and enterprise plans add expiry dates and password protection. The URLs are longer than Dropbox's and use a short-code redirector, which is fine for most uses but harder to eyeball or truncate cleanly.

Boxgives you 10 GB free — the most generous of the three — and is the one most likely to already be approved inside a large company. The shared link opens Box's preview, and paid tiers add fine-grained access controls, custom URL slugs, and analytics on views and downloads. For personal use it's overkill; for team use where audit trail matters, it's often the right answer.

None of the three lets you use your own domain on the free tier. If that matters, jump ahead to section 05 on self-hosting. For a broader ranking with pros and cons per host, see the comparison table in section 07.

Not all PDF links are the same shape, and picking the wrong shape is the single most common reason a link "works but feels wrong." There are two categories worth naming.

A viewer URLpoints at a webpage the host wraps around your PDF. Google Drive's /view URL, Dropbox's ?dl=0 URL, and OneDrive's default share URL are all viewer URLs. Click one and you land on a Drive / Dropbox / OneDrive page with a preview, a download button, and the host's branding. Recipients can read the PDF without downloading it, which is friendly for casual sharing. The trade-off is that the URL doesn't behave like a file — you can't <embed>it, browsers won't treat it as a PDF for "save as," and analytics tools won't count it as a download.

A direct-download URL points at the raw PDF bytes with a proper Content-Type: application/pdf header. Click one in a browser and one of two things happens: the browser's built-in PDF viewer opens the file inline, or (depending on the Content-Disposition header) the browser downloads it. Direct-download URLs are the ones you want in <a href> tags, QR codes,<embed> and <iframe> elements, and email buttons that say "Download the PDF."

A rough rule of thumb: viewer URLs are for humans, direct URLs are for browsers and code. If you're sending a link to one person over email or chat, a viewer URL is fine. If the link is going into a webpage, a template, a printed QR code, or anywhere it will be clicked more than a handful of times, use a direct URL — the recipient experience is faster and the behavior is predictable across browsers.

The next two sections cover how to get direct URLs from each host and how to control whether the file opens in the browser or triggers a download.

Cloud storage is fine until you want the URL to read yourdomain.com/guide.pdf instead of drive.google.com/file/d/<random-string>/view. The moment a custom domain matters — for brand, for memorability, for trust when a stranger clicks — you're in self-hosted territory. Fortunately, self-hosting a single PDF is close to free.

Netlify is the softest landing. Create a free account, drop a folder containing your PDF into their deploy zone, and you get a URL like https://your-site.netlify.app/guide.pdf in seconds. Add a custom domain from the settings and the URL becomes https://yourdomain.com/guide.pdf. The PDF is served with proper headers, opens inline in browsers, and stays stable — you can replace the file with a new version at the same path and the URL keeps working. Cloudflare Pages and Vercel work the same way with the same free tier.

Amazon S3 is the industrial option. Create a bucket, upload the PDF, mark it public (or generate a signed URL if you want time-limited access), and you get a URL at https://<bucket>.s3.amazonaws.com/guide.pdf. Put CloudFront in front to serve from your own domain and get a global CDN for pennies per month. This is what you use when the PDF has to survive real traffic — thousands of downloads a day, embedded in an app, linked from an ad campaign.

GitHub Pagesis the developer's free lunch. Push the PDF into a public GitHub repository, enable Pages in the repo settings, and the file is served at https://<username>.github.io/<repo>/guide.pdf. Custom domain is a two-line CNAME record. The catch is that the repo is public, so don't use GitHub Pages for anything you wouldn't post on Twitter.

All three approaches let you rotate the underlying PDF while keeping the URL stable — the property that makes them worth the extra ten minutes of setup over a Drive share.

Every PDF URL implicitly picks a behavior when clicked: open in the browser's built-in PDF viewer, or trigger a download to the user's device. Which of the two happens is controlled by the Content-Disposition HTTP header the host sends with the file. inline opens in the browser, attachment triggers a download. Most hosts default to inline for PDFs; a few let you override.

Google Drive. The default /view?usp=sharingURL opens Drive's viewer, not the raw PDF. To get a direct-download URL that forces the download, rewrite it as https://drive.google.com/uc?export=download&id=<file-id>. The file ID is the long string between /d/ and /view in the share URL. This works for files under 100 MB; larger files show an interstitial confirmation page.

Dropbox. The default share URL ends in ?dl=0 and opens the Dropbox viewer. Change the query string to ?dl=1 and the same URL is a direct download that skips the viewer entirely. To keep the file inline but bypass the viewer, swap the hostname from www.dropbox.com to dl.dropboxusercontent.com — the browser then loads the raw PDF and opens it in the built-in viewer.

OneDrive. Append &download=1to the share URL to force a download. There isn't a clean documented pattern for inline; the viewer is the default and mostly the only option.

Self-hosted (Netlify, S3, GitHub Pages). You control the headers directly. Serve with Content-Disposition: inline to preview in the browser and Content-Disposition: attachment; filename="guide.pdf" to force a download with a specific filename. On Netlify, this goes in a _headersfile; on S3, it's an object metadata setting; on GitHub Pages, the default is inline and can't be changed.