Drop a folder, get a live site in seconds, no account — and a preview that Cloudflare's changelog says stays live for one hour unless you claim it. That's an excellent preview. Here's the line where the thing you're sending stops being a preview.
Cloudflare shipped Drop in July 2026: drag a folder or a zip into the browser, and a static site is live on Cloudflare's network. No account. No CLI. No Git repo. No build step.
It is very good. If your next thought was "wait, that's what I've been doing with three tools and a deploy pipeline," that reaction is correct and you should try it.
There's one line in the changelog worth reading twice, because it's the whole design:
a temporary live preview that stays live for 1 hour
Keeping it means clicking Claim, which means signing in or creating an account.
That's not a catch. It's an honest trade — total speed and no signup, in exchange for something that's explicitly temporary. The reason it's worth writing about is that it draws a line most people don't consciously draw, and the line is genuinely useful: a preview and a delivery are different objects.
People frame the choice as a feature comparison and then get confused when the answer keeps changing. It changes because they're comparing two products that are good at two different jobs.
A preview answers a question. Does the build render? Does this look right on a phone? Is the chart the one you meant? Its audience is you, or someone in the same conversation, right now. Its lifespan is minutes. Disposability isn't a limitation, it's a feature — nobody wants to garbage-collect a hundred previews later.
A delivery is the work arriving at someone. The audience is specific and usually external. It's opened when they get to it — after the school run, on a Tuesday, in another timezone. It gets forwarded to a colleague you've never met. Someone bookmarks it and comes back in three weeks to check a number.
Optimise for the first and you get exactly what Drop is: instant, accountless, one hour. Optimise for the second and you end up somewhere quite different, because the requirements stop being about speed of publish and start being about what remains true about the link tomorrow.
Not features anyone should have to shop for. Just the properties that follow from "someone else is holding this."
It's still there when they open it. The single most common failure isn't technical. You sent it Friday afternoon; they opened it Monday morning; the address was a preview. Nothing broke — the link did precisely what it said it would.
It can be closed. Access to a deliverable should end: a review window that shuts on the 14th, a proposal that closes when they sign, an NDA'd deck that shouldn't outlive the pitch. Choosing the end date when you send beats remembering to revoke it in three weeks, and which window matches which engagement is a decision worth making once and reusing.
The contents can change without the address changing. This is the one people underrate until it bites. A link you've handed to a client stops being a URL and becomes a thing in their inbox, their bookmarks, and their colleague's inbox. Every revision that mints a fresh address costs another message explaining which link is the real one — and someone always reads the old one anyway.
It isn't discoverable. A public preview URL is fine for a build test. A client deliverable turning up in a search result for their brand name is a different kind of bad day. The defence is an unguessable address plus a no-index instruction where a crawler will actually read it — and no public directory to browse in the first place.
Worth being blunt, because the rest of this reads like an argument and it isn't one.
If you're checking a build renders, showing a colleague a page in a thread, looking at your own work on a real phone rather than a resized browser window, or settling whether an export actually survived — a one-hour preview is the correct amount of infrastructure. Anything more is ceremony you'll clean up later. Use it.
And if you already have a Cloudflare account, claiming the deployment is a genuinely good outcome: a real project on one of the fastest networks going, a domain you can attach, and controls Cloudflare describes for making the site private and choosing who can view it. If the answer to what is this? is "a site," that's a fine place for it to live.
The friction sits in the middle, and it's a shape rather than a fault: you didn't want a disposable hour, and you didn't want a permanent project either. You wanted to hand one piece of work to one person and have it behave sensibly for a fortnight.
A self-contained HTML file, or a built folder zipped up, uploaded once. What comes back is a 32-character unguessable address carrying a noindex tag — not memorable, which is the point, because the link is the permission.
You set the clock rather than inheriting one. Without any account, an anonymous upload takes a single file up to 3 MB and self-destructs after 7 days, so a Friday link is still there on Monday. With a free account you choose the expiry, or turn it off. A password is free on every plan, so a forwarded link still needs the passphrase.
And when revision two exists, it replaces the contents at the same address — password and expiry intact, each version kept rather than overwritten. The bookmark keeps working and quietly points at the current thing. That's the property that turns a link into something you can send before the work is finished, which is a better way to work than the alternative of waiting until you're sure.
Drop the same folder and get an unguessable, no-index link with a clock you set — free to start, no account needed for the person opening it.
Instant hosting has been arriving from every direction this year, and each product picks a different way to keep "instant and free" sustainable. Vercel Drop's docs are explicit that each drop creates a new project — so the constraint lands on the URL rather than the clock. Cloudflare's lands on the clock. Others put it at the account boundary.
None of those is a flaw. They're all reasonable answers to "how do we give this away and stay solvent," and the arrival of this whole category is good news — it means the idea that your work can be a link rather than an attachment has stopped being a niche habit.
The useful move isn't picking a winner. It's asking one question before you send anything:
What happens after they open it?
If the answer is nothing — you learned what you needed and the link's job is done — take the fastest free thing available and don't think about it again.
If the answer is something — a reply, a forward, a decision, a revision, a second look next week — then you're not previewing. You're delivering, and the link needs to behave like part of the work rather than like a temporary window onto it.
A Drive link hands someone a file in a filing cabinet — download it, or preview a flattened copy. A private link hands them the finished thing, already open. Where the two diverge on rendering, control, and who the link assumes the reader is.
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.
A ZIP is a moving box: the recipient has to unpack it, find the entry file, and hope their mail provider didn't strip it. A hosted link is the room already set up. When a multi-file build should travel as a link instead of an attachment.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.