Replacing a page you have already handed someone is a different problem from publishing it the first time. Why the usual answer is 'learn git', who that answer is actually for, and what the other routes really cost.
There is a specific, slightly sinking moment that almost no hosting guide covers. You made a page, you got a link, you sent it to someone. Then the file changed — you regenerated it, you fixed a number, the client asked for one thing to be different. And now you are holding a new file and an old link that is already sitting in somebody else's inbox.
Search that problem and the answers arrive fast and all agree: put it in a repo, connect a build, deploy from there. Somewhere in the replies, reliably, is a version of version control is programming 101.
That advice is not wrong. It is just answering a question you did not ask, and it is worth being precise about why — because the reason is not that the advice is bad. It is that publishing and replacing are different jobs, and git is built for the second one at a scale most people never reach.
Git solves a problem that is genuinely hard: many people changing the same thing over time, and needing to know who changed what, and being able to go back. Every part of that machinery — commits, branches, history, review — exists to make that survivable.
If your page lives in a codebase, if a teammate also edits it, if a bad change needs to be undone next Tuesday, that machinery is not overhead. It is the whole point, and you should use it.
The mismatch shows up when none of those conditions hold. One person. One file. A file that is usually not edited so much as regenerated — you go back to the tool that made it, ask for the fix, and get a whole new file out. There is no line-by-line diff to review, because every line moved. There is no collaborator to coordinate with. History would be a folder of near-identical files nobody will open. (When the change really is one line — a typo, a price, a date — regenerating the whole file is the long way round; our online HTML editor opens the file, edits the code or the rendered page directly, and hands it back without anything leaving your browser.)
For that shape of work, the advice lands as: to change one file, first learn a system for coordinating many people changing many files. It is a reasonable answer given to the wrong question, which is a much more common failure than a wrong answer.
Here is the distinction that actually decides how painful updating will be, and it is not a feature-list item. It is structural.
Some hosts treat the URL as a slot. The address exists first and independently; a file sits in it; you can put a different file in the same slot. The link you sent is a stable thing that points at whatever is currently there.
Some hosts treat the URL as a result. The address is produced by a deploy. Deploy again and you have produced something again — which may land on the same address if it is configured to, or may be a fresh one alongside the old.
Neither is a defect. Deploy-produced addresses are how you get preview URLs per branch, atomic rollbacks, and the ability to have three versions live at once — real capabilities that slot-shaped hosting does not give you. But the two shapes fail in opposite directions, and the failure mode of the second one is the nasty one:
The old link does not error. It quietly keeps serving the old file.
Nobody sees a broken page. Nobody writes to ask what happened. They just read something out of date and act on it, and you find out later, if at all. A link that dies loudly is a much smaller problem than a link that lies quietly — this is the same trap that shows up when a workflow republishes the page on every run, just reached by hand instead of by automation.
Drop a self-contained HTML or ZIP and get an unguessable link in seconds. Upload a new version to the same page later and the link you already sent keeps working — no repo, no deploy step. Private and no-index by default; password and expiry optional.
Four questions, in the order that matters. None of them is "which host is best."
1. If I upload a new version, does the link I already sent keep working? Ask it exactly this way. "Supports updates" is not the same claim — plenty of tools let you update and hand you a new address, which is useless for a link that is already out of your hands.
2. Do I need the old version back? If yes, you need history, and a plain file swap will not give it to you. This is the honest case for git even at one-person scale — not because updating is hard, but because undoing is.
3. Does the page need a backend? If it has to log people in, take a payment, or save what someone types, none of this applies. That is not a static page, and the right tools are platforms built for it — Vercel and Netlify do this properly and a static link host, however convenient, will not.
4. Who is allowed to open it, and does that change when the file does? Most people never ask this and then discover the answer at a bad time. Replacing a file usually does not change who can reach it — the page is as public or as private after the swap as it was before. If a draft was fine being findable and the final version is not, that is a decision to make deliberately, not something the upload does for you. The private-versus-public dial is a separate control from the file, and it stays where you left it.
Structural, not a feature table — these do not expire:
Once you send a link, it stops being yours. It is in an inbox, a Slack thread, a printed QR code, a calendar invite from three weeks ago. You cannot recall it and you usually cannot find every place it landed.
That is what makes replacing different from publishing. Publishing is a thing you do to a file. Replacing is a thing that happens to every copy of a link you have already given away — and the mechanics of your host decide whether that is one upload or a small archaeology project.
Worth deciding before you send the first link, rather than after. Making a page self-contained in one file helps here too: a single file has exactly one thing to replace, so a swap is a swap rather than a coordination problem across assets.
Client-side encryption tools turn your page into an encrypted file, so the protection and the artifact are the same object — every edit means re-running the tool and re-uploading. What that actually costs, the salt setting that decides whether your old share links survive, and when a hosted password is the better trade.
Your Slidev or reveal.js deck is already a self-contained web app. Skip the public deploy, the screenshot, and the PDF flattening: run the build, zip the dist folder, and turn it into one private link that keeps every fragment, transition, and code highlight stepping exactly as it did locally.
You ran ng build and now someone needs to open it — QA, a client, a stakeholder — before the real deployment gets scheduled. What to upload, what happens to relative asset paths, and the one honest limit: a refresh on an in-app route returns 404 unless you switch to hash routing.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.