You can see the HTML file. Now decide who else can. (2026)

You have an .html file. Maybe a report, a design export, something an AI tool produced. The first thing you want is to look at it — rendered, styled, behaving — rather than read its source.

That part is easy, and it is worth noticing that it commits you to nothing. Drag the file onto a browser tab and it draws locally, or drop it into a viewer that renders it in the page without uploading anything. Either way the file has not gone anywhere, and no decision has been made.

The decision comes one step later, and it is the one most tools make on your behalf.

The step that looks like a formality

To let somebody else open the file, it has to live somewhere that answers requests. Every "get a link" tool does this, and they all feel like the same action: drop file, receive URL.

They are not the same action. The URL you get back carries a posture:

• A findable address — short, readable, indexable. Anyone who searches the right words, or who works through the obvious guesses, can arrive. That is a feature when the point is to be found.
• An unguessable address — a long random tail, kept out of search results. It renders for anyone holding the link and is effectively unreachable for anyone who isn't.

Same file, same rendering, opposite defaults about strangers. And because the tools present both as "upload and get a link", the choice usually gets made by whichever tool you happened to open.

Which one the file in front of you needs

The useful question is not "is this sensitive". It is "is being found part of this file's job?"

If yes — a launch page, a portfolio, something you want to rank, a URL you'll print — then public is correct and hiding it would defeat the purpose.

If no — a client draft, a proposal, an internal report, a prototype you want three named people to look at — then a findable address is not a neutral default. It is a small ongoing exposure you did not ask for, in exchange for a benefit you did not want.

Most files people are holding when they ask "how do I send this" are in the second group.

Why sending the file instead doesn't dodge the question

The obvious workaround is to skip hosting and just email the file. In practice that trades one problem for a worse one: mail clients and chat apps don't render .html attachments as pages, so the recipient gets raw code or a download prompt instead of your page. Most people stop there.

So the file ends up hosted anyway — often hastily, often publicly, because the fastest tool to hand was a public one. The decision still got made; it just got made under time pressure and without being noticed.

Unguessable is not the same as locked

Worth being precise, because "private link" gets used loosely. An unguessable address is strong protection against discovery — nobody crawls or guesses their way to a 32-character random tail. It is not protection against forwarding. Whoever holds the link can open it, and can pass it on.

That is the honest boundary, and it is why a password and an expiry exist as separate, deliberate controls rather than being folded into the link itself. If the consequence of the wrong person opening the page is real, the address alone should not be carrying that weight.

The order that saves you the awkward version

1. Look at it first. Render the file locally — nothing uploaded, nothing decided.
2. Check it stands alone. If it depends on files sitting next to it on your disk, inline them or send the folder as a zip, or it will arrive broken.
3. Then choose the posture. Findable, or unguessable — and pick it on purpose, per document, not once at signup.
4. Add a control if the link alone isn't enough. A password for sensitive work, an expiry for anything time-bound.

Doing it in that order means the broken draft never had a public address, even briefly. Doing it in the other order is how a client sees version one.

When you genuinely want both

Some documents want to be private by default and searchable on purpose — a published case study that started life as a client deliverable, say. That is a per-document flip, not an account-wide mode, and it should be reversible, because a file's job changes more often than an account's does.