Understanding Browser Console Errors: The 20 Most Common Ones Explained
The browser console is one of the most information-dense tools a developer has — and one of the most intimidating for anyone who hasn't learned to read it fluently. A wall of red error messages can feel overwhelming, but most of what you'll encounter in day-to-day web development falls into a predictable set of patterns.
This guide covers the 20 most common browser console errors: what each one means, what typically causes it, and how to fix it. Whether you're a developer debugging your own code or a QA engineer trying to understand what a failing test is telling you, this is the reference you'll come back to.
JavaScript Errors
1. TypeError: Cannot read properties of undefined (reading 'x')
What it means: You're trying to access a property on a value that is undefined. The JavaScript runtime expected an object at that point, but found nothing.
Common cause: Attempting to read a nested property before confirming the parent exists. For example, user.profile.name will throw this error if user.profile is undefined. It also commonly appears when an async operation hasn't completed yet and the data isn't populated.
How to fix it: Use optional chaining (user?.profile?.name) to safely traverse nested objects. For async data, make sure you're waiting for the fetch to complete before accessing the result, or guard with a conditional check (if (user && user.profile)).
2. TypeError: x is not a function
What it means: You're trying to call something as a function, but the value at that variable is not callable — it might be undefined, null, a string, or a plain object.
Common cause: A callback was not passed correctly, a method name was misspelled, or a module export doesn't match what you're importing. Another common scenario is calling an async function without await, then trying to call a method on the resulting Promise object.
How to fix it: Log the value before calling it (console.log(typeof myFunction)) to confirm what it actually is. Double-check spelling, verify your imports, and confirm function signatures match how you're calling them.
3. ReferenceError: x is not defined
What it means: You're referencing a variable or identifier that doesn't exist in the current scope. JavaScript looked for it and found nothing.
Common cause: A typo in a variable name, using a variable before it's been declared, or referencing a variable that was declared inside a block (like an if statement or for loop) from outside that block. Also commonly happens when a script that defines a global variable fails to load.
How to fix it: Check spelling carefully. Make sure the variable is declared in a scope accessible to the code using it. If you're referencing a third-party global (like gtag or Stripe), confirm the script that defines it loaded successfully by checking the Network tab.
4. SyntaxError: Unexpected token
What it means: The JavaScript parser encountered a character or keyword it didn't expect at that point in the code. The file cannot be parsed or executed at all.
Common cause: A missing closing bracket, brace, or parenthesis. Using a reserved keyword as a variable name. Malformed JSON being passed to JSON.parse(). Trailing commas in older environments that don't support them. Arrow function syntax used in an environment that doesn't support ES6.
How to fix it: The line number in the error message is your starting point, but the actual problem is often on a previous line (a missing closing character can push the error far from its source). Use your editor's bracket matching to find unclosed pairs. For JSON parsing errors, validate the JSON string with a tool like jsonlint.com before parsing.
5. RangeError: Maximum call stack size exceeded
What it means: A function has called itself (directly or indirectly) so many times that the browser's call stack ran out of space. This is a stack overflow error.
Common cause: Unintentional infinite recursion — a function that calls itself without a proper base case that stops the recursion. Also common in frameworks when a state update triggers a re-render that triggers the same state update in a loop, or when two event handlers call each other.
How to fix it: Find the recursive call chain in the stack trace printed with the error. Identify where the recursion never terminates and add or fix the base case. In React, look for useEffect hooks with missing or incorrect dependency arrays that trigger infinite re-render cycles.
6. TypeError: Cannot set properties of null (setting 'x')
What it means: You're trying to assign a property to a value that is null. Unlike undefined, null is intentionally set — which often means a DOM query returned no match.
Common cause: document.getElementById('someId') returns null when no element with that ID exists. Assigning to a property on that null reference causes this error. Timing issues — running DOM manipulation code before the DOM has fully loaded — are another frequent cause.
How to fix it: Always check that DOM query results are non-null before interacting with them. Move scripts to the bottom of the <body> or use DOMContentLoaded to ensure the DOM is ready. Verify that element IDs in your JavaScript match the actual IDs in your HTML.
7. Uncaught (in promise) Error
What it means: A Promise rejected, and there was no .catch() handler or try/catch block to handle it. The error was swallowed silently from the application's perspective, but the console surfaces it.
Common cause: Missing error handling on fetch() calls, third-party SDK methods that return Promises, or async functions called without await and without a rejection handler. Also common when using Promise.all() and one of the constituent promises rejects.
How to fix it: Add .catch() to every Promise chain, or use try/catch around await expressions. For Promise.all(), consider Promise.allSettled() if you want to handle partial failures rather than having one rejection cancel everything.
8. TypeError: Failed to fetch
What it means: A fetch() call couldn't complete. This is a network-level failure — the browser couldn't establish a connection or the request was blocked before it reached the server.
Common cause: The server is down or unreachable, the URL is malformed, a CORS policy blocked the request, the user is offline, or an ad blocker or browser extension intercepted the request. This error appears before any HTTP response, so there's no status code to inspect.
How to fix it: Check the Network tab to see if the request appears at all and what its status is. If CORS is the issue, you'll also see a CORS error in the console. Confirm the target URL is correct and the server is running. Test with curl or Postman to rule out server availability.
Network and HTTP Errors
9. 404 Not Found
What it means: The server received the request but found no resource at the specified URL. The endpoint, file, or page doesn't exist at that path.
Common cause: A typo in the URL, a deleted or moved resource with no redirect in place, a route that wasn't configured in the server or frontend router, or a dynamic segment (like a user ID) that references a record that doesn't exist in the database.
How to fix it: In the Network tab, click the failing request and check the exact URL that was requested. Verify the route exists on the server. For API calls, check that dynamic segments are being populated correctly — undefined values in template literals silently produce invalid URLs like /users/undefined.
10. 500 Internal Server Error
What it means: The server encountered an unexpected condition and couldn't complete the request. It's a catch-all for unhandled server-side failures.
Common cause: An unhandled exception in backend code, a database query failure, a misconfigured environment variable, or a dependency that crashed. The frontend has no visibility into what went wrong on the server — the error is entirely server-side.
How to fix it: Check the server logs. The response body of the 500 may include an error message in development environments (and should not in production). In the Network tab, look at the Response tab of the failing request — some APIs return structured error bodies even with 500 status codes. Report the full request details (URL, method, payload, timestamp) to the backend team.
11. 401 Unauthorized
What it means: The request requires authentication credentials that weren't provided, or the credentials provided are invalid or expired.
Common cause: A missing or malformed Authorization header, an expired JWT or session token, or a token that was revoked server-side. The distinction between 401 and 403 is important: 401 means "I don't know who you are," while 403 means "I know who you are, and you're not allowed."
How to fix it: In the Network tab, check the request headers for the Authorization header. Verify the token format matches what the server expects (e.g., Bearer <token>). Check whether the token has expired by decoding it at jwt.io. Implement token refresh logic if JWTs expire during active sessions.
12. 403 Forbidden
What it means: The server understood the request and knows who the user is, but the authenticated user doesn't have permission to access the requested resource.
Common cause: A user without admin privileges attempting to access an admin endpoint, a resource that belongs to a different user, a missing API scope or role assignment, or an IP allowlist blocking the request.
How to fix it: Verify that the authenticated user has the appropriate role or permission for the action. Check whether the correct API key or OAuth scope is being sent. If this happens in a specific environment (staging, production) but not others, compare the user's assigned roles across environments.
CORS and Security Errors
13. CORS Policy: No 'Access-Control-Allow-Origin' Header
What it means: The browser made a cross-origin request (to a different domain, port, or protocol), and the server's response didn't include the Access-Control-Allow-Origin header that authorizes cross-origin access. The browser blocked the response as a security measure.
Common cause: The backend hasn't configured CORS headers for the requesting origin, the API expects requests from a specific origin that's different from where the frontend is running (e.g., production API called from localhost), or a proxy misconfiguration strips CORS headers.
How to fix it: CORS is always a server-side fix. The server needs to include Access-Control-Allow-Origin: <origin> (or * for public APIs) in its responses. For preflight requests (OPTIONS), the server also needs to respond to Access-Control-Allow-Methods and Access-Control-Allow-Headers. During local development, a local proxy can avoid cross-origin requests entirely.
14. CORS Preflight Request Did Not Succeed
What it means: Before making a non-simple cross-origin request (like a POST with a JSON body or a request with custom headers), the browser sends an OPTIONS preflight request to check if the server allows it. The preflight failed — either the server returned an error or didn't include the required headers.
Common cause: The server doesn't handle OPTIONS requests, a firewall or WAF is blocking OPTIONS, the allowed methods or headers don't include what the actual request uses, or the preflight response doesn't include Access-Control-Max-Age.
How to fix it: In the Network tab, find the OPTIONS request that preceded the failing request. Check its response status and headers. Ensure the backend explicitly handles OPTIONS requests and returns the necessary Access-Control-Allow-* headers. Many backend frameworks have CORS middleware that handles this automatically when configured correctly.
15. Content Security Policy (CSP) Violation
What it means: The page's Content Security Policy — a set of rules defined in a response header or <meta> tag — blocked a resource from loading or a script from executing. CSP is a security layer that restricts where content can be loaded from and what kinds of dynamic code can run.
Common cause: An inline <script> or <style> that's not covered by a nonce or hash, a resource loading from a CDN or domain not listed in the policy, eval() being called in code when the policy prohibits it, or a third-party widget trying to inject content from an unlisted source.
How to fix it: The console error will specify which directive was violated and which resource was blocked. If the resource is legitimate, add its origin to the appropriate CSP directive (e.g., script-src 'self' https://cdn.example.com). Avoid using unsafe-inline or unsafe-eval in production policies — instead, use nonces or hashes for inline scripts.
16. Mixed Content: The Page Was Loaded Over HTTPS But Requested an Insecure Resource
What it means: A page served over HTTPS is trying to load a resource (image, script, stylesheet, API call) over HTTP. Browsers block or warn about this because it undermines the security of the HTTPS connection.
Common cause: Hardcoded http:// URLs in image src attributes, CSS url() calls, or JavaScript fetch calls. Legacy content from a CMS that wasn't updated when the site moved to HTTPS. Third-party embeds or widgets that still use HTTP URLs.
How to fix it: Update all resource URLs to use https:// or protocol-relative URLs (//example.com/resource). Search your codebase and database content for http:// references. For resources you control, ensure HTTPS is enabled on the origin server. Use the upgrade-insecure-requests CSP directive as a catch-all to force browsers to upgrade HTTP requests to HTTPS automatically.
DOM and Resource Errors
17. Failed to Load Resource: net::ERR_BLOCKED_BY_CLIENT
What it means: A browser extension (typically an ad blocker or privacy tool) intercepted and blocked a network request before it reached the server.
Common cause: Ad blockers identifying analytics scripts, tracking pixels, or advertising networks and blocking them. This frequently affects tools like Google Analytics, Segment, Hotjar, Facebook Pixel, and similar third-party scripts.
How to fix it: This is expected behavior from a user's installed extensions and is generally not a bug in your code. For analytics and tracking scripts, consider proxying them through your own domain to avoid block lists. For essential functionality that's being blocked, investigate which extension is responsible (disable extensions one by one) and whether the blocked resource is truly necessary for the feature to work.
18. Uncaught DOMException: The operation is insecure
What it means: JavaScript tried to perform an operation that the browser's security model prohibits. This often involves cross-origin iframe access, clipboard operations without user gesture, or accessing storage in a sandboxed context.
Common cause: Attempting to read contentDocument or contentWindow of an iframe from a different origin, trying to access localStorage in a sandboxed iframe, calling document.execCommand('copy') outside of a user-initiated event handler, or accessing cookies in a context that disallows it.
How to fix it: The fix depends on the specific operation. For iframe cross-origin access, use the postMessage API to communicate between frames safely. For clipboard access, use the Permissions API and the modern navigator.clipboard API, triggered from a user gesture (click event). For sandboxed iframes, review the sandbox attribute and add only the permissions the iframe actually needs.
19. Deprecation Warning: [Feature] is deprecated and will be removed
What it means: Your code (or a dependency) is using a browser API or feature that the browser vendor has marked for removal. It still works now, but it will stop working in a future browser version.
Common cause: Using document.write(), synchronous XMLHttpRequest, old Web Crypto APIs, event.path instead of event.composedPath(), or legacy Web Platform features that have been superseded by newer standards. Often introduced by outdated third-party libraries.
How to fix it: Look up the modern replacement for the deprecated API — the console message usually names it. Update the relevant code in your own codebase. For deprecations in third-party libraries, check whether a newer version of the library has already resolved it and upgrade. Subscribe to browser release notes (especially Chrome's "Intent to Deprecate and Remove" posts) to stay ahead of removals.
20. Warning: Each Child in a List Should Have a Unique 'key' Prop (React)
What it means: React requires that elements rendered in a list (using .map() or similar) have a key prop with a unique, stable value. Without it, React can't efficiently determine which items changed between renders.
Common cause: Rendering an array of JSX elements without adding key props, or using the array index as the key when the list order can change. Array index keys are technically valid but cause subtle bugs when items are added, removed, or reordered.
How to fix it: Add a key prop to each element in the list using a stable, unique identifier — typically the item's database ID (key={item.id}). Avoid using the array index as a key for lists that can be reordered or filtered. If no natural ID exists, generate stable IDs when the data is created rather than at render time.
Reading Console Errors More Effectively
A few habits that make working with console errors faster:
Read the full message before Googling. Console errors often tell you exactly what's wrong and where. The first line is the error type and message; the stack trace below it shows every function call that led to the error. Start at the top of the stack trace and work down — the first line from your own code (not from node_modules or browser internals) is almost always where to look first.
Use the link in the stack trace. Every stack trace entry is a clickable link that jumps to the exact line in the Sources panel. Click it rather than manually searching for the file.
Filter by level. The console has filter buttons for errors, warnings, and info. In a noisy application, filtering to Errors only cuts through the warnings from third-party libraries to show you what's actually broken.
Preserve the log. By default, the console clears on navigation. Enable Preserve log (right-click in the console or find it in console settings) when debugging flows that involve page navigation.
Check the Network tab alongside the console. Many console errors — CORS, failed fetches, 4xx and 5xx errors — are better diagnosed in the Network tab. The console tells you something failed; the Network tab tells you exactly what the server said.
Stop Losing Console Errors When You Need Them Most
The most frustrating aspect of console errors isn't understanding them — it's the fact that they disappear. A bug gets reported, but by the time a developer looks at it, the console has refreshed a dozen times and the original error is gone. Reproduction steps get lost. The exact state of the application at the moment of failure is impossible to reconstruct.
Crosscheck solves this automatically. When you capture a bug with Crosscheck, it records the full console log — every error, warning, and log message — at the exact moment the issue occurred, and bundles it with a screenshot, screen recording, and all network requests into a single shareable report.
No more "can you reproduce it and send me the console output?" The developer receives the original error, the full stack trace, and the complete network activity that preceded it — exactly as the browser saw it. What used to take multiple rounds of back-and-forth to reconstruct is immediately available in the bug report.
If you regularly work with console errors as part of debugging or QA, Crosscheck is the fastest way to capture them completely and share them in context.
