Check the page on a real phone before you send it (2026)

There is a version of this that has happened to everyone who has ever handed over a web page. You built it, probably with an AI, in one file. On your monitor it is fine — spacing right, type right, the whole thing lands. You send the link. And the reply is a screenshot from a phone where the heading has wrapped into four lines, a button is half off the edge, and something you were quite pleased with is now sitting under something else.

Nothing broke. You just never looked at it on the device most people were going to open it on.

The awkward part is that the obvious way to look at it first — send the file to yourself — is the one route that does not work.

Why mailing yourself the file fails

A desktop has spent thirty years being taught that .html means open this in a browser. A phone mostly has not. Tap an HTML attachment on a phone and the operating system usually hands it to a file previewer or a text viewer, which shows you the source code, a blank sheet, or a share menu. It is not a bug and there is no setting on your end that fixes it. If you have hit this from the other direction — a recipient telling you the thing you sent will not open — that is the same mechanism, seen from their side.

The thing every phone does know how to open is an address. So the fix for previewing is the same as the fix for sending: stop moving the file, and put it somewhere it has a URL.

Which raises the fair objection: I don't want to publish it yet — it isn't finished.

That objection is only true if publishing means becoming public. It doesn't have to. A link that is unguessable and carries noindex is at an address without being on the web in any sense that matters: nobody can find it, nothing lists it, and search engines are told to stay away. You are not shipping. You are giving the file a door number so your own phone can find it.

Do the cheap check first

Open devtools, switch to device mode, pick a phone width. It takes four seconds and it catches most layout problems, which makes it the correct first move — not a lesser one.

Then be clear about what it did not check:

• The browser chrome moves. On a real phone the URL bar shrinks as you scroll and grows back when you scroll up, so the visible height changes mid-scroll. A layout pinned with 100vh gets clipped by exactly that much. Emulation holds the viewport still, so this class of bug is invisible in it. (100dvh is the unit that accounts for it.)
• iOS resizes your text for you. Safari applies its own text auto-sizing in some layouts, which is why a font that looked deliberately small on the desktop can arrive noticeably larger — or vice versa — and nothing in your CSS explains it.
• A cursor is not a thumb. A mouse pointer is a single pixel and never misses. Emulation will happily let you click a 20-pixel tap target that a real thumb cannot reliably hit.
• Fixed elements behave differently against a URL bar that is itself moving, which is why sticky headers and bottom bars are the two things most likely to look wrong only on hardware.

Everything on that list is a difference between a small window and a phone. Emulation gives you the first one honestly and does not claim to give you the second.

One thing worth checking in the file itself before you blame anything else — if this line is missing, a phone renders the page at desktop width and then shrinks the whole thing:

<meta name="viewport" content="width=device-width, initial-scale=1">

Most AI-generated pages include it. Some don't, and the symptom — everything correct but tiny — looks like a hosting problem and isn't.

The loop

1. Publish it to a private link. One file, one drop, one address. If it's a folder with images or CSS beside it, upload the folder as a ZIP instead — relative paths only survive if the files that satisfy them travel together, and a single self-contained file has nothing to resolve in the first place.
2. Get the link onto the phone without typing it. A QR code is the least annoying route — point the camera, tap the banner. Typing a random string on a phone keyboard is how you end up debugging a 404 that was a typo.
3. Look at it as a stranger would. Scroll to the bottom and back up. Tap every button with a thumb, not a fingernail. Rotate it. Turn Wi-Fi off for a second if the page pulls anything external — that tells you what someone on a train will see.
4. Fix, replace the file at the same address, re-check. The address stays; what sits in it changes. This matters more than it sounds during a loop, because a fresh URL per attempt means a fresh QR code per attempt.

The caveat that eats the most time

Your phone caches. You replace the file, re-scan the same code, see the identical broken layout, and start hunting for a bug you already fixed.

Pull to refresh. If it still looks stale, open the link in a private tab — that skips the cached copy entirely. It costs two seconds and it is worth doing reflexively after every replace, because the failure mode is indistinguishable from "my fix didn't work."

When to reach for something else

If you are editing the page line by line and want it to update on the phone as you type, publish-and-recheck is the wrong shape and you will feel it by the third round. What you want is a live connection to the file on your machine: a framework dev server exposed on your local network, or a tunnel — ngrok or Cloudflare Tunnel — pointed at localhost. Both give you hot reload on the phone, which is genuinely better for that job.

The reason publish-and-recheck fits most AI-built pages is that they are not edited so much as regenerated. You go back to the model, ask for the fix, and get a whole new file. There is no live edit to reload — there is a new file to put in the same slot. When that is the shape of the work, a tunnel is a server you have to keep running for no benefit.

And one thing no host can do for you: if the layout breaks because of how the page is written, that is in your file, not in where it lives. A preview tells you that it broke and where — it cannot un-break it. The fix goes back to whatever made the page.

The short version

The page is not finished when it looks right on your monitor. It is finished when it looks right on the device it will actually be opened on, and the only way to know that is to open it there.

Give the file an address that nobody can find, put it on your phone, and be your own first recipient. It takes about a minute, and it moves the moment you discover the wrapped heading from after you sent it to before.