Overview
If a website works on a phone but not on a work computer, first determine whether the phone is using the same network. A phone using cellular data proves that the website is available from the internet, but it does not prove that the office network, DNS, browser, proxy, endpoint security, or web-filtering path is working correctly.
Why this happens
The work computer may have stale browser data, a failing extension, incorrect DNS, a proxy or VPN setting, an expired certificate path, a web-filtering policy, or a device-specific security restriction. The phone may also be bypassing the office network entirely by using cellular data.
Before you begin
- Record the exact website address and browser error.
- Check whether the phone is using cellular data or the same office Wi-Fi.
- Do not bypass company web filtering or certificate warnings.
- If the site handles sensitive data, do not test with personal accounts or unapproved devices.
Click-by-click troubleshooting
Step 1: Reproduce the failure with the exact URL
Action: On the work computer, copy or type the exact website address into the browser address bar. Record the full error message and whether the page partially loads.
Why this matters: A typo, old bookmark, redirected address, certificate error, DNS error, or access-denied page points to different causes.
What to look for: Look for messages such as site cannot be reached, DNS name not resolved, connection timed out, certificate warning, access denied, or blocked by policy.
Expected result: You should have the exact failure type before changing browser or network settings.
Step 2: Test the phone on the same office Wi-Fi
Action: If permitted, connect the phone to the same office Wi-Fi used by the computer and open the same URL. Then compare with cellular data.
Why this matters: If the site works on cellular but fails on office Wi-Fi, the problem is more likely related to the office network, DNS, web filtering, or upstream provider path.
What to look for: Note whether the result changes when the phone switches between office Wi-Fi and cellular.
Expected result: You should know whether the failure follows the office network or only the work computer.
Step 3: Test another approved browser on the work computer
Action: Open a second installed browser, such as Microsoft Edge or Google Chrome, and test the exact same URL.
Why this matters: If another browser works, the network path is probably healthy and the problem is isolated to the original browser profile, cache, extension, or policy.
What to look for: Compare the exact page behavior and error message in both browsers.
Expected result: Either both browsers fail, which keeps the network or device path in scope, or only one fails, which narrows the problem to that browser.
Step 4: Use a private browser window as a controlled test
Action: In Edge select Settings and more > New InPrivate window. In Chrome select More > New Incognito window. Open the site without signing into unrelated accounts.
Why this matters: Private browsing reduces the effect of cached sessions and many stored cookies without deleting the user's normal browser data.
What to look for: If the site works privately but not in the normal window, stale cookies, cache, sign-in state, or an extension is more likely.
Expected result: The comparison should tell you whether normal browser state contributes to the failure.
Step 5: Check name resolution from the work computer
Action: Open Command Prompt and run nslookup followed by the site's hostname, for example nslookup example.com.
Why this matters: A website cannot load by name if the work computer cannot resolve the hostname to an IP address.
What to look for: Look for returned addresses, timeout messages, or a failed DNS response.
Expected result: The hostname should resolve successfully. If it does not, treat the issue as DNS or network-path related rather than clearing browser data repeatedly.
Step 6: Check proxy, VPN, and managed security state
Action: Open Settings > Network & internet > Proxy and confirm only approved settings are active. Check whether an approved VPN is connected. If a browser or endpoint security product displays a block page, capture the page instead of bypassing it.
Why this matters: Work computers often use security controls that personal phones do not. A block can therefore be intentional rather than a malfunction.
What to look for: Look for policy messages, category blocks, certificate inspection errors, or an unexpected proxy or VPN state.
Expected result: You should know whether the work computer is being intentionally filtered or is misconfigured.
What to look for
- Phone works only on cellular: investigate the office network or filtering path.
- Second browser works: investigate the original browser profile, cache, or extensions.
- Private window works: stored browser state is likely involved.
- DNS lookup fails: investigate DNS rather than the website application.
- A managed block page or certificate warning should be escalated, not bypassed.
When to stop
When to contact IT
Contact IT when the site fails only on the office network, DNS does not resolve, a policy or certificate block appears, or multiple managed computers show the same behavior. Provide the URL, browser error, phone Wi-Fi versus cellular result, browser comparison, and DNS test result.
Need help with this issue?
J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.
Contact J3 Systems GroupAuthoritative references
Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.