The short version: do not start every browser ticket by nuking all history, passwords, and cookies. First scope the problem: one site or every site, one browser or all browsers, one user or everyone, normal window or private window. Then clear only the right cache/site data, check extensions, verify sign-in, test DNS/network clues, and write down what actually fixed it.
Browser tickets look easy until they eat half a morning. A user says “the website is broken,” but the real issue could be stale JavaScript, bad cookies, an expired SSO session, an extension blocking scripts, cached DNS, a proxy/VPN problem, a service outage, or an ancient bookmark.
Use this checklist for normal help desk browser issues: stale web apps, login loops, blank pages, dead buttons, old pages, cookie/session errors, browser-specific failures, and “works for everyone except me” tickets. If multiple users are down in the same app, escalate instead of clearing one person’s cache forever.
The browser cache troubleshooting checklist
| Step | What to check | Why it matters |
|---|---|---|
| 1 | Capture the exact URL, browser, error, and user impact | Stops vague “website broken” troubleshooting |
| 2 | Test private/incognito and another browser | Separates cache/cookies/extensions from app outages |
| 3 | Clear site-specific data before full history | Fixes the issue without destroying useful browser state |
| 4 | Check sign-in, SSO, MFA, and password changes | Login loops are often identity problems |
| 5 | Disable extensions and content blockers | Extensions break business apps more often than users admit |
| 6 | Compare device, network, DNS, and VPN behavior | Avoids blaming the browser for a network issue |
| 7 | Verify the fix and document exactly what changed | Prevents repeat tickets and mystery fixes |
1. Get the ticket out of “the internet is broken” mode
Ask for:
- Exact URL, not just “the portal”
- Browser name and version if available
- Screenshot or copied error text
- Whether it happens in one browser or multiple browsers
- Whether other users can access the same site
- Whether it started after a password change, browser update, device replacement, VPN change, or app update
- Whether the issue is login, loading, display, file upload, download, printing, or a specific button
That last detail matters. “Can’t access the site” can mean the page will not load, SSO loops back to login, a button is grayed out, the user lands in the wrong tenant, or the browser auto-filled the wrong saved password.
A good first note looks like this:
User cannot submit timesheet at
https://example.company.com/time. Chrome shows page but Submit button does nothing. Edge works on same laptop. Other websites load normally. Issue started this morning after app update banner.
Now you have a browser-specific app problem, not a general outage.
2. Test private window and another browser before clearing everything
Before deleting data, run two quick tests:
- Open the same URL in a private/incognito window.
- Open the same URL in another supported browser.
Use the results like this:
| Result | Likely direction | Next move |
|---|---|---|
| Works in private window | Cache, cookies, session, extension, or saved data | Clear site data and check extensions |
| Works in another browser | Browser profile, extension, setting, or cached app files | Compare browser-specific settings |
| Fails everywhere on one device | Device, DNS, VPN, proxy, endpoint security, or account | Check network and identity clues |
| Fails for multiple users | App outage, tenant change, SSO problem, or service issue | Escalate with evidence |
Private windows usually bypass existing cookies and extensions. They are not magic: policies still apply, sign-in requirements still exist, and some enterprise extensions still run. Treat the result as a signal.
If several people are affected, stop treating it like one user’s cache. Check service health, app owner notices, change windows, and monitoring.
3. Clear site-specific data first
Clearing all browsing data sometimes works. It also signs the user out of everything, removes useful saved state, and makes the fix harder to explain.
Prefer site-specific cleanup:
- Clear cache and cookies for the affected site only.
- Remove stored site permissions if they are clearly wrong.
- Close all tabs for that app and reopen the browser.
- Have the user sign in fresh.
- Test the exact action that failed.
In Chrome or Edge, the practical path is usually the lock/tune icon near the address bar, site settings, then cookies/site data for that domain. In Firefox, use site information or settings to remove cookies and site data for the specific domain.
Use full browser data clearing only when site-specific cleanup fails or policy requires it. Warn the user first, especially if saved passwords or active sessions may be affected.
4. Watch for stale app files after updates
Modern web apps ship JavaScript, CSS, service workers, and cached assets. After an app update, the browser can hold a stale file while the server expects a new one. That is how you get blank panels, dead buttons, or errors that disappear after a hard refresh.
Try the low-risk fixes first:
- Hard refresh the page.
- Close all tabs for the app and reopen it.
- Sign out and sign back in.
- Clear site-specific cache/data.
- If the app uses an installed PWA or desktop wrapper, restart that app too.
For internal apps, collect the console error only if your support process expects it. A concise note is better than a wall of developer console noise:
Chrome showed blank dashboard after vendor update. Edge loaded normally. Cleared site data for vendor domain, restarted Chrome, user signed back in, dashboard loaded and report export worked.
5. Treat login loops as identity problems until proven otherwise
A login loop may be a cookie problem, but it may also be stale credentials, expired sessions, blocked third-party cookies, SSO misconfiguration, conditional access, MFA, or the wrong account.
Check:
- Is the user signing into the correct work account?
- Did the password change recently?
- Is MFA enrollment current?
- Does the same account work from another browser or device?
- Is the app opening an old bookmark with the wrong tenant or redirect URL?
- Are third-party cookies or pop-ups required for this app’s SSO flow?
- Is the account locked, disabled, expired, or missing a license/group?
If the issue started after a password change or repeated prompts, compare it with the account lockout troubleshooting checklist. If the failure is specifically MFA enrollment or device prompt weirdness, use the MFA reset checklist instead of pretending cookies explain everything.
Do not reset passwords just because the browser is looping. Verify the account state first. Random password resets can make stale credential problems worse elsewhere.
6. Check extensions, blockers, and browser policies
Extensions are a classic “works in Edge, fails in Chrome” culprit.
Look for:
- Ad blockers or privacy blockers
- Password managers injecting forms
- PDF viewers or download managers
- Security plugins
- Old vendor extensions
- Translation tools
- Shopping/coupon extensions that should not be on a work device anyway
Disable extensions temporarily or test with a clean browser profile if policy allows it. If the app works, re-enable extensions one at a time until the failure returns.
For managed devices, also check browser policies. If a business app requires pop-ups, downloads, microphone/camera access, or third-party cookies, record the exact permission needed and escalate through the correct browser management process.
If the issue is caused by a newly installed tool or extension, connect it back to the software install request checklist. Random extensions are software too.
7. Separate browser problems from DNS, VPN, and network problems
Not every browser error is a browser issue.
Common clues:
| Symptom | Possible cause | Better next step |
|---|---|---|
| Site name does not resolve | DNS issue | Test nslookup and compare networks |
| Works on phone hotspot, fails on office network | Network, proxy, filtering, DNS, or firewall | Check network path and security tools |
| Internal app works only on VPN | Expected private access or VPN split-tunnel issue | Verify VPN status and routes |
| Certificate warning appears | SSL inspection, wrong site, expired cert, captive portal | Do not tell user to click through blindly |
| Only file downloads fail | Browser setting, endpoint security, DLP, or app permission | Check download policy and security logs |
For name-resolution weirdness, use the DNS troubleshooting guide instead of repeatedly clearing browser cache.
Also watch for captive portals. Hotel Wi-Fi, guest networks, and airport networks can redirect the first browser request to a login page. Test another plain website and confirm the network is actually usable.
Copy-paste ticket checklist
Scope:
[ ] Exact URL, browser, and error text captured
[ ] Confirmed one site vs all sites
[ ] Confirmed one browser vs multiple browsers
[ ] Confirmed one user/device vs multiple users
[ ] Checked recent password, MFA, browser, app, VPN, or device changes
Testing:
[ ] Tested private/incognito window
[ ] Tested another supported browser
[ ] Tested same site from another network or device if needed
[ ] Checked service/app status if multiple users affected
Fixes tried:
[ ] Hard refresh/restarted browser
[ ] Cleared site-specific cache/cookies/data
[ ] Verified correct account/tenant/SSO path
[ ] Checked extensions, blockers, and browser permissions
[ ] Checked DNS/VPN/proxy clues if page does not load
[ ] User tested the original failed action successfully
Ticket notes:
[ ] Root cause or best evidence recorded
[ ] Exact cleanup performed documented
[ ] User impact and final verification recorded
[ ] Escalation details included if not resolvedExample ticket note
User could open payroll site in Edge but Chrome looped back to SSO login after password change. Confirmed account active and MFA working. Private Chrome window loaded correctly, so issue was isolated to existing Chrome site data. Cleared cookies/site data for payroll vendor domain only, closed Chrome, user signed in again, and approved timesheet successfully. No password reset performed.
That note says what failed, what comparison proved, what was cleared, and how the user confirmed the fix. For broader wording examples, use the help desk ticket notes examples.
FAQ
Should help desk clear browser cache first?
Usually no. Test private/incognito and another browser first, then clear site-specific data for the affected domain. Full cache/history clearing should be a later step, not the default opener.
What is the difference between cache and cookies?
Cache stores site files like images, scripts, and styles so pages load faster. Cookies store session and site data, including login state. Stale cache can break page display; bad cookies often cause login loops or wrong-session behavior.
Why does a site work in private mode but not normal browsing?
Private mode usually starts without the user’s existing cookies, cached site data, and many extensions. If the site works there, suspect site data, an extension, or saved sign-in state before blaming the web app.
Bottom line
Browser troubleshooting is mostly about not overreacting. Scope the issue, compare private mode and another browser, clear only the affected site’s data, check identity and extensions, and watch for network clues. If multiple users are affected, escalate like an outage. If one browser profile is stale, fix that profile and write down exactly what changed.
The goal is not a cache-clearing ritual. The goal is to prove whether the problem is browser state, account state, network path, app outage, or user confusion.