The page is fine. Your computer is fine. What differs is that a desktop knows what to do with an HTML file and a phone mostly doesn't — so the fix depends on whether you sent a file or an address. Here's how to tell which you sent.
Your page works. You opened it, it looked right, you sent it on. Then: "I can't open it on my phone."
Scroll up in the chat and look at the message itself. This one glance decides everything.
.html. You sent a file.https://. You sent an address.People conflate these because on your own machine they feel identical: both open the same page. Off your machine they are barely related.
This is the common one, and the phone is behaving exactly as designed.
Desktop operating systems have had a rule for thirty years: .html belongs to the browser. Double-click and the page renders. Phones never inherited that rule. Tap an .html attachment on a phone and it goes to a file previewer or a text viewer — so your recipient sees the source code, a download prompt they don't understand, or a blank screen.
It gets worse if the page isn't self-contained. If your styling lives in a separate .css file, or the images sit in a folder next to the page, then sending just the .html sends the skeleton without the skin. On a desktop that renders as an ugly wall of unstyled text; on a phone it usually renders as nothing useful at all. (If you're not sure whether your page is one file or a folder pretending to be one, sending a zip versus a hosted link walks through the difference.)
Before you send anything, it is worth knowing whether the file even stands up on its own: the online HTML viewer renders it in your browser with no upload, and its width switcher previews phone layout from a desktop — which is the half of this you can actually check yourself.
What doesn't fix it: asking them to try a different app, re-sending it, or zipping it. All of those move the problem onto the least-equipped person in the conversation. If your instruction to the recipient contains the words "then choose open with", the share has already failed.
Now the causes are less obvious, because an address looks universal.
Many links produced by AI builders and workspace tools aren't public addresses at all. They are:
There's a thirty-second test for all of these. Open your own link in a private browsing window. In that window you have no session and no login — you are, functionally, the person you sent it to. If it fails there, it will fail for them, and no amount of re-sending changes that. This whole family of failures has its own shape per tool, which why your AI share link won't open for them goes through one by one.
One more variant worth knowing: the link is genuinely public and fine, but something between you and the reader is blocking it — a company network, a mail scanner, an unfamiliar domain suffix. That looks like "it doesn't open for them" too, and it's a different diagnosis again.
Whichever branch you're in, the destination is identical: the page needs a URL, and the URL is what you send.
That's the whole reason people put a page online for an audience of three. It isn't about traffic or search or having a website. It's that a URL is the only format that every phone, on every operating system, with no app installed and no file management, already knows how to open. A file is something the reader has to handle. An address is something the reader just taps.
How you get that URL is a smaller question than it looks:
Either way, the thing you paste into the chat is an address. That's the actual fix, and it's the same fix in both branches — which is why it's worth spending the ten seconds to work out which branch you're in before you try anything else.
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.
Running the studio out of one folder per client is a good structure for making the work. It stops at the point where the client has to open it — a private repo needs a GitHub account, and Pages built from one is public by default. What the handover step actually needs, and how to add it without breaking the folder.
A .json Lottie is not a page — hand it to a client and they get a wall of numbers. What it takes to turn one into something that opens in any browser, and why the answer is smaller than the tooling suggests.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.