Treat “Error 20” as a signal type, not a final diagnosis. If it appears in a browser, an app, a proxy page, or a monitoring tool, first decide whether the failure came from the user’s browser or from the server path. Standard HTTP status codes group client errors as 4xx and server errors as 5xx, but “Error 20” is often a custom code from a browser, script, gateway, plugin, security layer, or application [source: MDN].

TLDR: Browser errors usually happen before the request is processed by your application, while server errors usually happen after the request reaches your infrastructure. For example, if 12 out of 100 users see “Error 20” only in Safari after a login update, suspect cookies, cache, browser policy, or client-side JavaScript first. If every browser fails and logs show matching 500 responses at the same minute, the server side is the stronger suspect. Start with timing, affected users, request logs, and one clean browser test.

What “Error 20” usually means

Error 20 is not a universal web standard. That is the part that wastes time. One platform may use it for a browser security failure. Another may use it for a blocked request, a timeout, a proxy rule, a failed extension call, or a payment gateway response.

So the right question is not, “What does Error 20 mean everywhere?” The better question is, “Which system generated this specific Error 20?”

That system may be:

• The browser, through JavaScript, privacy controls, cache, cookies, extensions, TLS, or DNS.
• A front-end script, such as a checkout widget, login SDK, tag manager, or single page app.
• A CDN or proxy, including a firewall, bot filter, or rate limit rule.
• The web server, such as Nginx, Apache, IIS, or a cloud load balancer.
• The application, including code, database calls, sessions, queues, or third-party APIs.

Browser errors: the failure starts on the user side

A browser-side error means the request failed before the application handled it, or the page broke while running in the user’s device. These errors can be maddening because your server logs may show nothing. Honestly, it feels like chasing smoke when the customer says “your site is down” but the origin server never received the request.

Common browser-side causes include:

• DNS failure: The browser cannot find the domain.
• TLS or certificate problems: The browser blocks the connection as unsafe.
• Blocked scripts: Privacy tools, ad blockers, or extensions stop required code.
• Cookie problems: Login or checkout breaks because session cookies are missing or rejected.
• Cache corruption: Old JavaScript files fight with new server responses.
• CORS failure: The browser blocks a cross-origin request before the app can use it.
• Service worker issues: A stale worker serves outdated files or traps requests.

A browser error often has a pattern. It may affect only Chrome on Android, only users with strict tracking protection, or only people who visited before a release. If the same account works in a private window but fails in the normal browser, suspect cache, cookies, extensions, or stored site data.

Server errors: the failure starts after the request arrives

A server-side error means the request reached part of your infrastructure and failed there. This may be the origin server, load balancer, CDN, application runtime, database, API dependency, or file storage layer.

Signs of a server-side issue include:

• Consistent failures across browsers: Chrome, Safari, Firefox, and Edge all fail.
• Matching log entries: Access logs, error logs, or traces show the failed request.
• HTTP 5xx responses: Typical examples include 500, 502, 503, and 504.
• Load-related timing: Errors rise during traffic spikes, deploys, or database pressure.
• Shared impact: Many users report the same page failing at the same time.

Server errors tend to be easier to prove, but not always easier to fix. A 500 might come from one broken line of code. A 504 might involve a slow upstream API. A 502 could point to a dead application process or a bad proxy configuration.

How to separate browser errors from server errors

Use a short, disciplined process. Do not guess from the error text alone.

1. Capture the exact message. “Error 20” is not enough. Save the full screen, URL, timestamp, browser, device, and account type.
2. Test in a clean browser. Use private mode with extensions off. If it works, the original browser state is suspect.
3. Check the network panel. In developer tools, look for blocked requests, CORS messages, TLS warnings, failed fetch calls, or HTTP status codes.
4. Compare users. Ask whether the issue affects one person, one browser group, one country, or everyone.
5. Check server logs by timestamp. If there is no matching request, the browser, network, DNS, CDN, or security layer may be stopping it earlier.
6. Review recent changes. Deploys, certificate renewals, firewall rules, cookie settings, and script updates are usual suspects.

The catch is that a server problem can look like a browser error. A bad API response may cause JavaScript to throw a vague client-side message. The reverse also happens. A browser blocks a script, then the user reports it as a “server error” because the page looks broken.

A practical example

Imagine a checkout page that normally loads in 1.3 seconds. After a release, 7% of users start seeing “Error 20” during payment. Server logs show successful page loads, but no payment request for many failed sessions.

That points away from the payment server. The browser is likely failing before the final request. The team checks developer tools and finds that a third-party payment script is blocked when strict privacy mode is enabled. The fix is not a bigger server. It is a safer integration path, better error handling, and a fallback message that tells the user what to do.

Now compare that with a second case. Every user sees Error 20 at login. Logs show failed authentication requests with a 500 response. The database connection pool is exhausted. That is server-side. Clearing browser cache will not help. Restarting the app might buy time, but the real fix is connection limits, query tuning, or scaling.

Why the distinction matters

Mislabeling the error costs hours. Support tells users to clear cache when the API is failing. Developers inspect application logs when the browser is blocking cookies. Operations restarts servers when a bad JavaScript bundle is the real culprit. It drives me crazy that a vague code can turn a five-minute check into a two-hour blame loop.

A clear split gives each team the right work:

• Support collects browser, device, timestamp, and screenshots.
• Developers inspect console errors, API calls, and release changes.
• Operations checks logs, health checks, load balancers, and uptime.
• Security teams review firewall, bot, and rate limit rules.

What to tell users when Error 20 appears

Use plain language. Do not blame the user. Say something like:

“We are checking whether this error is caused by the browser session or by our server path. Please try a private window once, and send us the time of the error, browser name, device, and the page URL.”

That message is calm and useful. It avoids false certainty. It also gets the data needed to solve the issue.

Bottom line

Error 20 should start an investigation, not end one. First identify where the code was generated. Browser-side clues include missing server logs, one-browser impact, console errors, blocked scripts, and cache or cookie fixes. Server-side clues include matching logs, 5xx responses, broad impact, and failures tied to deploys or traffic spikes.

The fastest path is simple: reproduce the error, check the browser network panel, match the timestamp against server logs, and compare affected users. Once you know which side failed, “unexpected web error” becomes a fixable incident instead of a vague complaint.