Sending a client a finished page? A Drive link hands them a file in a filing cabinet to download or preview flattened. A private link hands them the thing itself, already open. The three places the two diverge: rendering, control, and who the link assumes the reader is.
A lot of people arrive at this question from the other direction — not "which should I use" but "what is this thing I'm about to send". Quick answers, then the comparison.
It's a pointer to a file, not to a page. The URL identifies one file sitting in Drive. Whoever opens it is being let into Drive to look at that file — which is why what they see is Drive's own preview surface with Drive's own buttons around it, rather than your thing filling the window.
That's why it's so long. The bulk of a Drive URL is the file's ID — the unique handle Drive uses for that one file. It isn't decoration and you can't trim it; that string is the address.
What one actually looks like. Three shapes, depending on what you shared:
file https://drive.google.com/file/d/<FILE_ID>/view?usp=sharing
folder https://drive.google.com/drive/folders/<FOLDER_ID>?usp=sharing
Doc https://docs.google.com/document/d/<DOC_ID>/edit?usp=sharing
Reading it left to right: the host tells you whether it's a Drive file or a Google editor document; /d/ announces the ID is next; the long middle chunk is the ID; the last segment is the mode you're handing over (/view, /edit, /preview); ?usp=sharing is just a tag noting the link came from the Share button, and it carries no permission of its own — deleting it changes nothing about who can open the file.
How long is that ID? Not a fixed number, and Google doesn't publish one. Its own developer documentation calls it "a unique, opaque ID" and commits only to it being stable — the ID survives renaming the file. Different products mint different-looking IDs, so a Doc and an uploaded PDF won't match in length. The practical version: it's long, it's meaningless to read, and you can't shorten it without breaking it. If the length itself is the problem — you're pasting this into a slide, a printed page, or a message where it looks awful — that's a case for a short link that stays under your control, not for editing the Drive URL.
"Share" and "Copy link" aren't the same action. Copying the link gives you the URL, but the URL only works for whoever the file's general-access setting already allows. Sharing with named people is the other path: they get access attached to their account. Copy a link while access is still restricted and you've sent something that asks the recipient to request permission — the single most common way a Drive hand-off goes wrong.
Does it expire? Not on a schedule you set when you send it. What ends access is something you change afterwards — the sharing setting, the file's location, or the file existing at all. If you wanted the link to stop working on a date, Drive isn't where that setting lives; that's the expiring-link shape, and it's a different kind of object.
And if the file is an HTML page, it won't run. Drive treats it as a file to hold, so the reader gets a download or a flattened preview instead of the working page. That one is the whole reason this comparison exists — why an HTML attachment opens as raw code goes through the mechanism.
With that out of the way, the actual choice.
The reflex, when you've made something and need to get it to someone, is to drop it in Google Drive and send the link. It's right there, everyone has it, and the link "just works." For a lot of things — a doc you're co-writing, a folder of assets, a spreadsheet — that reflex is correct, and nothing below argues otherwise.
But there's one job where the reflex quietly works against you, and it's a job more and more people have now: you built a finished, self-contained thing — a report, a one-page proposal, a dashboard, a page an AI tool generated — and you want a specific person to open it and look at it. For that job, a Drive link and a private link are not two flavors of the same thing. They hand over two different objects.
A Google Drive link points at a file in a filing cabinet. That framing explains almost everything Drive does well and everything it does awkwardly. A filing cabinet is superb at holding files — many of them, versioned, co-edited, searchable, safe. When you send someone a drawer key, what they get is access to a file: they can download it, or Drive can show them a preview of it. The file is the unit.
A private link points at a page in a screening room. You're not handing over a file to retrieve; you're handing over a finished thing that's already playing. The reader clicks and they're in the room — the page has rendered, the charts have drawn, the interactivity is live. There's nothing to download, nothing to open in a second app, no "which program does this file need." The experience is the unit.
For a self-contained web page, those are genuinely different deliverables, and the difference lands in three specific places.
A self-contained HTML page is built to run in a browser — its whole point is that the scripts fire and the layout holds. Drive, being a filing cabinet, treats it as a file: the recipient downloads raw .html (which many people don't know what to do with), or Drive shows a preview that flattens it. Either way the thing you built to run arrives as a thing to retrieve. If the page was just text and images you might not notice. If it had a chart that redraws, a calculator that returns a number, a toggle, a filter — that's the part that dies in the cabinet.
A private-link host serves the same file as a live page. The reader opens the URL and the page runs the way you built it. This is the same reason an AI tool's own share link often won't open cleanly for the person you sent it to — the container the file travels in decides whether it arrives as a page or as a puzzle.
Drive's sharing model is coarse by design, because it's built around accounts — the people who collaborate on the file. A file is either restricted to named accounts (the reader signs in as one of them) or open to "anyone with the link." That second setting is the one people reach for to avoid the account friction, and it's exactly the one that quietly loses control: the link is an ordinary URL that keeps working for anyone it's ever forwarded to, with no expiry and no password on the file itself. And even "anyone with the link" can hit a Google sign-in wall depending on the reader's browser state — or get blocked outright if your file lives in a work or school Workspace that restricts outside access.
A private link assumes only a browser. The URL is a 32-character random string — not listed, not indexed, not guessable — so the baseline is already private. On top of that baseline you add control deliberately: an expiry when the page shouldn't outlive the moment, a password when the contents are sensitive. Nothing is reachable that you didn't hand out, and handing it out doesn't require the reader to be anyone in particular.
If the thing you're sending is a finished self-contained page, drop the HTML — or a ZIP bundle — and get a private link in under a minute. The person you send it to needs no account, on Google or anywhere else. It opens, and it runs.
When you deliver something one-way — to a client, a stakeholder, a reviewer — a quiet question follows: did they actually open it? Drive's activity view is built around editors and collaborators, because that's what a filing cabinet cares about. It's not built to answer "did the one person I sent this to look at it, and did they come back." A private link records views on every link, and reading that access log tells you one person re-opening a page from several people finding it — the exact signal a one-way delivery needs and a shared drawer doesn't surface.
None of this makes Drive the wrong tool — it makes it the wrong tool for one job. Drive is where a document several people edit together should live. It's where a folder of working files belongs, where a big video goes, where the archive copy sits so it survives without depending on any one host. Those are storage-and-collaboration jobs, and a private-link host doesn't do them and shouldn't try.
The split is clean:
Most people only own the filing cabinet, so they use it for both — and the delivery job is the one that comes out flattened. It's the same reason emailing a ZIP of your files or dropping them on WeTransfer each has its own friction: they're all file-transfer tools pressed into a delivery job. If what you're handing over is a finished thing meant to be looked at, hand over the room, not the drawer.
Private, no-index links and password protection are free on every plan, with one always-on link (free links otherwise default to a 7-day expiry). Solo ($4.99/mo) makes links permanent and adds the detailed access log; Studio ($14.99/mo) adds a custom domain and white-label, so the page reads as yours instead of a shared drawer's.
A Drive link and a private link both look like "a URL you send someone." But one points at a file to retrieve and one points at a page to look at. Decide which you're actually handing over, and the choice makes itself.
WeTransfer is a courier: it drops the file and leaves, and the link self-destructs. A private link is a room that stays open. Which fits depends on whether you're moving a file or showing a finished page — and on how big it is.
Every list of free HTML hosts assumes you'll sign up. If you won't, the field narrows to a handful — and each one charges you for it in a different currency. Which hosts genuinely need no account, what you give up, and when signing up is the cheaper trade.
Sending a file attaches a frozen copy to an inbox; sending a link hands over a URL you still control. The three places that gap shows up — size ceilings, what actually renders, and who holds the deliverable after it lands.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.