It opens on your computer but not on their phone (2026)

Your page works. You opened it, it looked right, you sent it on. Then: "I can't open it on my phone."

First: which of the two did you send?

Scroll up in the chat and look at the message itself. This one glance decides everything.

• The recipient got an attachment — a paperclip, a filename, something ending in .html. You sent a file.
• The recipient got something beginning with 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.

Branch one: you sent a file

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.)

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.

Branch two: you sent an address, and it still didn't open

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:

• previews of a live session — the page exists while your editor is open, and the reader gets a blank screen once it isn't;
• workspace or account links — perfectly designed for colleagues who are already signed in, and a login wall for everyone else;
• links that assume the reader is you — which is why they work flawlessly on your devices, including your phone, and fail on theirs.

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.

Both branches end in the same place

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:

• If you want something permanent and public, and you don't mind a one-time setup, the repository-based routes are a solid answer — plenty of non-technical people push through that first configuration once and never think about it again.
• If what you have is one finished page you want someone to look at now, an upload-and-get-a-link tool is the shorter road: no repository, no build, no deploy vocabulary. Worth checking two things before you commit — how long the link lives, and whether it's public or unlisted. (A comparison of the free options lays out which is which.)

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.