To test website on mobile device while the site still runs on localhost, you need a route from the phone to your dev server. The right route depends on whether the phone sits on your network, needs USB debugging, or needs a public HTTPS link.
Browser device mode catches layout issues, but it does not replace a real phone. A real device exposes tap target problems, viewport quirks, slow mobile network paths, installed browser behavior, and payment or identity flows that need an actual browser session.
Test website on mobile device from localhost
Start with the lowest-friction path that matches your review context.
| Method | Best for | Main limit |
|---|---|---|
| Browser device mode | Fast layout checks | Desktop browser engine and input model |
| LAN IP address | Same WiFi testing | Breaks across networks and firewalls |
| USB remote debugging | Android Chrome debugging | USB setup and device settings |
| Device farm | Broad device coverage | Account, cost, and slower iteration |
| Temporary public link | Real phone review from any network | Exposes a scoped public route |
For most local development checks, you want either LAN access or a temporary public link. Use LAN when the phone and laptop share the same trusted network. Use a public link when you need to test on cellular, share with a teammate, or send a link to a reviewer outside your office.
Method 1: Use your LAN IP
Run your dev server on a host that accepts network traffic. Many dev servers bind to localhost by default, which means only your machine can reach them. Bind to all interfaces when you want another device on the same WiFi network to connect.
For Vite:
npm run dev -- --host 0.0.0.0Find your local IP on macOS:
ipconfig getifaddr en0If your app runs on port 3000 and your IP is 192.168.1.24, open this on the phone:
http://192.168.1.24:3000This path works for quick checks. It can fail when the network blocks device-to-device traffic, when your phone uses cellular, or when your app needs HTTPS for cookies, geolocation, service workers, camera access, or payment redirects.
Method 2: Use Chrome USB debugging for Android
Chrome DevTools supports remote debugging Android devices over USB. Google’s docs describe a workflow that starts with enabling Developer Options and USB Debugging on the phone, then opening chrome://inspect/#devices on the development machine.
This gives you a strong debugging surface. You can inspect elements, view console output, and open a screencast of the Android tab from your desktop DevTools window.
Chrome DevTools also supports USB port forwarding. You map a port on the Android device to a host and port on your development machine. After the mapping, the Android browser can load a local server through localhost on the device.
Use this when you need to debug Android Chrome itself. Use a tunnel when you need to send a link to someone else or test on a phone that is not plugged into your machine.
Method 3: Use a temporary review link
A tunnel gives your local server a public URL. The tunnel client opens an outbound connection to a relay, and the relay forwards browser requests back to your local port. For the architecture details, read how wiremaven works.
With wiremaven, start a 30 minute review window for a server on port 3000:
npx wiremaven-cli 3000 --expires 30m --name mobile-testOpen the generated HTTPS link on your phone. You can test on WiFi or cellular without changing router settings. During beta, wiremaven does not require an account for this flow.
The useful part comes after the link opens. wiremaven shows viewer joins, request outcomes, and failure signals while the session runs. If the mobile browser fails to load /checkout or a font request returns 404, you can see that while you still have the phone in hand.
Review windows support TTL options such as 15, 30, or 60 minutes. That matters because mobile test links should end after the check, not stay public because you forgot to tear down a tunnel.
What to test on the phone
Do more than resize a page. Touch the product as a user would.
- Open the main flows from a fresh tab.
- Tap every navigation item with a thumb.
- Test sticky headers, drawers, menus, and modals.
- Rotate the device once.
- Try form fields that summon the keyboard.
- Check auth, checkout, file upload, and camera flows.
- Watch for horizontal scroll and clipped text.
- Confirm that the viewport meta tag exists.
MDN’s responsive design guidance still points to the basics that catch most bugs: fluid layouts, media queries, responsive media, and the viewport meta tag. Real-device testing proves those choices under actual mobile constraints.
When BrowserStack or a device farm fits better
Use BrowserStack, Sauce Labs, or another device farm when you need broad device coverage across operating systems, browser versions, screen sizes, and regional network conditions. That is a test matrix problem.
Use your own phone when you need fast feedback on the local branch you are editing now. A device farm can be too much when the real question is, “Does this menu work on my iPhone before I send the review link?”
wiremaven fits the second case. It gives you a temporary encrypted public link and live review signals without deploying the branch or setting up a permanent test environment.
Mobile testing checklist
- Dev server binds to a reachable host when using LAN access.
- The app works over HTTPS when the flow requires secure browser APIs.
- Navigation and forms work with touch input.
- No content overflows horizontally.
- Request failures are visible during the test.
- The link expires after the review window.
FAQ
Can I test localhost on iPhone?
Yes. If your iPhone and laptop are on the same network, bind the dev server to your LAN IP and open http://your-ip:port. If that fails or you need HTTPS, use a temporary public link.
Is Chrome device mode enough for mobile testing?
No. Device mode helps with layout work, but a real device catches touch, keyboard, browser, network, and viewport behavior that emulation can miss.
Does a tunnel expose my whole computer?
No. A localhost tunnel forwards a chosen local service, such as port 3000, through a public relay. wiremaven uses an outbound WebSocket and a time-boxed link for that session.
Should I test on WiFi or cellular?
Test both when the flow matters. WiFi catches layout and browser behavior. Cellular catches network, latency, and public-route assumptions.
Start with one real phone
Create a temporary mobile test link:
npx wiremaven-cli 3000 --expires 30m --name mobile-testRead the wiremaven docs for setup options, then compare this workflow with what a localhost tunnel is and ngrok alternatives.
Related: What Is a Localhost Tunnel? | ngrok vs. localtunnel vs. wiremaven