How to read console errors like a pro: a 2026 DevTools field guide

To read console errors well, you need three things: a working mental model of what each error class actually means, the habit of following the stack trace back to the offending source line, and the DevTools settings that turn a noisy log into a readable signal. Most of the time a single message — a TypeError, a CORS block, a Refused to load from CSP — already tells you 80% of the diagnosis. The remaining 20% lives in the stack trace, the network panel, and the source map. This guide walks through the error classes you will actually encounter, what each one usually means, and the workflow that turns "red text in the console" into a fix.

TL;DR

• The browser's console reports six message levels — error, warning, info, log, debug, and verbose — and each maps to a different urgency.
• The five JavaScript exception types you will see most are TypeError, ReferenceError, SyntaxError, RangeError, and unhandled promise rejections logged as Uncaught (in promise).
• Network failures, CORS rejections, and CSP violations are browser-emitted errors, not JavaScript exceptions — they will not be caught by try/catch.
• Source maps let you debug minified production code as if it were unbundled. Without them, stack traces point to main.min.js:1:45823 and tell you nothing.
• DevTools filtering, grouping, and console.trace exist specifically to cut the noise — most developers under-use all three.

---

What the DevTools console actually shows you

The browser console is a live log of three independent streams interleaved into one view: JavaScript runtime exceptions, network-layer failures, and security-policy violations. They all show up as red text, but the resolution path for each is different — and confusing them is the most common reason a debug session stalls.

Open it with F12 or Ctrl+Shift+I on Windows and Linux, or Cmd+Option+I on macOS. To jump straight to the Console panel, use Ctrl+Shift+J (Windows) or Cmd+Option+J (Mac). The "Default levels" dropdown exposes six severity buckets — Verbose, Info, Warnings, Errors, plus side-channel logs from extensions and other frames. Hide everything except Errors and Warnings while you triage; turn the rest back on when you need context.

One habit pays off immediately: open DevTools before reproducing the bug. DevTools' own streams — network requests, performance traces, source-map fetches — only start recording from the moment the panel opens. Opening late is the most common reason a "missing" error appears on the second reproduction.

---

The six console message levels

An Error always deserves investigation; a Warning often does. Chrome's deprecation warnings now ship with a removal milestone — read it. If you see "removed in M138" in May 2026, the clock is short.

---

The JavaScript exceptions you will see most

Every uncaught JavaScript exception inherits from the built-in Error constructor and is logged with its class name plus a stack trace. ECMAScript defines seven standard error classes — Error, RangeError, ReferenceError, SyntaxError, TypeError, URIError, and the rare EvalError. Four of them account for the overwhelming majority of bugs you will debug.

TypeError

A TypeError means the runtime tried to use a value in a way its type does not support. The classic 2026 example:

Uncaught TypeError: Cannot read properties of undefined (reading 'name')
    at renderProfile (Profile.tsx:42:18)
    at App.tsx:88:5

This almost always means the data you expected is not there yet — an API response that arrived as undefined, a prop a parent forgot to pass, an array find() that returned nothing. Fix it at the access site with optional chaining (user?.name) or a render guard. The sibling Cannot read properties of null usually means state was cleared before a re-render finished.

ReferenceError

A ReferenceError means the runtime tried to use a name that does not exist in any reachable scope. The message is almost always X is not defined. Three usual suspects: a script tag failed to load (check the Network tab for a 404 on the JS file), a module's named export was renamed without updating the importer, or code is running before DOM globals are ready. Cannot access 'foo' before initialization is a special ReferenceError from accessing a let or const binding before its declaration runs.

SyntaxError

SyntaxError is a parse-time error — the engine could not read the code well enough to start running it. In browser-authored JavaScript this is rare in production because bundlers catch it. The two places it still bites: JSON.parse() on a malformed payload (Unexpected token < in JSON at position 0 almost always means an HTML error page came back where JSON was expected), and eval or new Function() running user-supplied code. A SyntaxError firing on your own bundle means the build pipeline shipped something broken — check the transpiler config and the target browser support matrix.

RangeError

RangeError shows up when a number falls outside the legal range for an operation. The two you will actually see: Maximum call stack size exceeded from infinite recursion (often a useEffect dependency loop), and Invalid array length from a non-integer or negative array constructor argument. For the first, the stack trace itself is the diagnosis — scroll up, find the function calling itself, and look for the missing base case.

Unhandled promise rejection — Uncaught (in promise)

Not a new error class — it is whatever the promise rejected with, prefixed with Uncaught (in promise). A TypeError inside an async function that nothing handles surfaces as Uncaught (in promise) TypeError: .... The browser fires an unhandledrejection event on the window before logging it, so Sentry, Datadog, and most error trackers wire into this event automatically.

Fix at the source — every async function or promise chain needs a .catch() or a try/catch around the await. A single .catch() at the end of a chain catches rejections from any preceding .then(). For a safety net, add a listener and call event.preventDefault() to suppress the default console output when you have handled it elsewhere; the MDN reference on unhandledrejection covers the exact contract.

---

Network, CORS, and CSP — the errors that bypass JavaScript entirely

Three of the most common red lines in the console are not JavaScript exceptions at all. They come from the network stack and the browser's security engine, and they will never be caught by a try/catch. Treat them as a separate diagnostic category.

HTTP status errors — 4xx and 5xx

GET https://api.example.com/users 404 (Not Found) is the network panel telling you the server responded — just not the way the code expected. fetch() does not throw on these by default; it resolves with response.ok === false. That is why they often slip past .catch() blocks and surface later as a TypeError when the code tries to read a property on undefined.

A 401 or 403 means auth (token expired or scope missing). A 404 means a route or asset is gone — check URL casing and trailing slashes. A 5xx means the server crashed handling the request, so server-side logs are the next stop. Always copy the full request URL, method, and timestamp into the bug report.

net::ERR_* and Failed to fetch

net::ERR_NAME_NOT_RESOLVED, ERR_CONNECTION_REFUSED, and ERR_NETWORK_CHANGED are the browser saying the request never completed a round trip. TypeError: Failed to fetch is the JavaScript-side shadow — fetch() rejects with that message when the network layer failed before any response came back. Common causes: DNS failure, an ad blocker or corporate proxy intercepting the request, a downed service, or a mixed-content block (HTTP from an HTTPS page).

CORS — blocked by CORS policy

Access to fetch at 'https://api.example.com' from origin 'https://app.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present is one of the most common 2026 console errors in apps that hit third-party APIs. CORS is not a frontend bug — it is the server refusing to grant a cross-origin caller permission. The fix is server-side: add the calling origin to Access-Control-Allow-Origin, allow the right methods in Access-Control-Allow-Methods, and respond to the OPTIONS preflight.

Read the exact message carefully. "Response to preflight request doesn't pass access control check" means the OPTIONS request failed, not the real one. "Request header field x-custom-thing is not allowed by Access-Control-Allow-Headers" means the preflight succeeded but rejected a custom header. Each variant has a different server-side fix.

CSP violations — Refused to load

Content Security Policy violations look like Refused to load the script 'https://cdn.example.com/a.js' because it violates the following Content Security Policy directive: "script-src 'self'". Per MDN's CSP violation reference, the message always names the blocking directive — script-src, style-src, img-src, connect-src, frame-src, and so on.

The "Refused to execute inline script" variant is its own category. Inline scripts and event handlers (onclick="...") are blocked unless the policy includes 'unsafe-inline', a nonce, or a SHA hash of the script body. Current advice — including the OWASP CSP cheat sheet — is a nonce-based "strict CSP" rather than hash allow-listing, because a single whitespace change invalidates a hash. Two practical notes: Content-Security-Policy-Report-Only runs the policy in observation mode (violations log but resources load), and browsers fire a securitypolicyviolation event on every block you can wire into telemetry.

---

Stack traces, console.trace, and source maps

A stack trace is the path of function calls that led to the error. The first line is the throw site; every line below is "who called the function that threw," ending at an event handler or framework entry point.

Two undervalued tools sit alongside the auto-generated trace. console.trace() prints the current call stack from any line you insert it on — perfect for "where is this function being called from?" without a debugger. console.assert(condition, message) prints a stack trace only when the condition is false, which is how you scatter cheap invariants through code without flooding the log.

In production, none of this helps unless you have source maps wired correctly. A source map is a JSON file the bundler produces alongside the minified output; it maps positions in main.min.js:1:45823 back to lines in your original TypeScript or JSX. Chrome DevTools picks them up automatically from a //# sourceMappingURL= comment or a SourceMap: response header — Chrome's source-maps documentation covers both paths.

The trap most teams fall into: shipping source maps publicly (anyone can reconstruct the codebase from the production bundle) or skipping them entirely (error trackers show useless stack traces). The hardened 2026 pattern is to generate maps in CI, upload them to Sentry, Datadog, or your own error tracker, and then either omit the sourceMappingURL comment from the deployed bundle or restrict the map URL to an internal-network endpoint. Developers debugging through DevTools get mapped traces; the public bundle does not leak source. If a trace looks wrong — line numbers off by a few, function names showing as Object.<anonymous> — the map is loading but mis-aligned. Check the devtool setting in webpack or the sourcemap flag in Vite. Inline source maps belong in development only.

---

Filtering, grouping, and the Issues panel

The console becomes unreadable above about 50 lines. A few features cut that immediately.

• Filter by text or regex. The filter bar accepts a substring or a regex (/Network/i). Negative filters work too — -Warning hides anything matching the word. This is how you find the one CORS error among 80 framework deprecation warnings.
• Hide messages by URL. Right-click any message and choose "Hide messages from <url>" to mute noisy third-party scripts — analytics, chat widgets, marketing pixels — without losing your own logs.
• Console groups. console.group(label) indents every subsequent log until console.groupEnd(); console.groupCollapsed() starts collapsed. The biggest win for code paths that log more than two lines per call — auth flows, complex effects, request/response pairs.
• The console sidebar. Settings → Preferences → Console → "Show the console sidebar" exposes a tree view grouping every message by URL and source location. On a noisy app this turns the firehose into a navigable index.
• Preserve log across navigations. "Preserve log" in the same settings stops the console from clearing on reload. Essential for redirects, 401-then-refresh flows, and OAuth bounces.
• The Issues panel. Chrome surfaces CORS, CSP, mixed content, deprecated APIs, and cookie problems in a separate Issues tab next to Console, usually with a one-line "How to fix" hint. Read it before scrolling through console output.

---

A repeatable triage workflow

When a bug is open in front of you, run this loop:

1. Open DevTools first, reproduce second. Cmd+Option+J (Mac) or Ctrl+Shift+J (Windows) lands directly in the Console.
2. Clear the console with Ctrl+L, then turn on "Preserve log" so nothing disappears on reload.
3. Filter to Errors and Warnings only. Hide third-party noise from extensions and analytics.
4. Trigger the bug and watch what lands in real time.
5. Read the top of the stack first, then the bottom. The top is where it threw; the bottom is the entry point that called the path.
6. Cross-check the Network tab for any fetch failure — full request, headers, and response body.
7. Cross-check the Issues tab for CORS, CSP, and deprecation problems with their suggested fix.
8. Capture before you close. Right-click any message and choose "Save as…" to export the full log, or screenshot with the stack trace expanded.

That last step is where most bug reports break down. The console is ephemeral — close the tab and it is gone. A reproducible bug report needs the console snapshot, the network log around the failure, and the steps that led to it, captured together.

---

FAQ

What is the difference between console.log and console.error?

Both print to the console, but console.error writes to stderr (in Node) and stylises the message as red in browsers — and it always includes a stack trace by default, where console.log does not. Error-tracking SDKs typically capture console.error calls and ignore console.log. Use console.error for things you want surfaced; use console.log for development-only traces.

Why does my try/catch not catch a network error?

Because most network failures are not exceptions. fetch() only rejects on a network-layer failure; an HTTP 404 or 500 resolves successfully with response.ok === false. Wrap fetches in a helper that throws on !response.ok, and use try/catch around the whole call. CORS and CSP errors are emitted by the browser before JavaScript ever runs — they cannot be caught at all, only logged via the securitypolicyviolation event.

Can I read production console errors without DevTools access?

Yes — that is what error-tracking platforms (Sentry, Datadog, Highlight, LogRocket) and visual bug-reporting extensions are for. They capture the same data the console shows — stack trace, network log, console output — and ship it to a backend the team can search. The Chrome DevTools performance auditing guide covers the local-debugging side; for shipping it from a user's machine, a capture tool does the work.

How accurate are stack traces from minified bundles?

Not at all, without source maps. A minified stack trace looks like at a (main.min.js:1:45823) — useless. With source maps loaded into DevTools or uploaded to your error tracker, the same line resolves to at renderProfile (src/components/Profile.tsx:42:18). Source maps are non-negotiable for production debugging.

What does "Uncaught (in promise)" actually mean?

The promise rejected and nothing called .catch() on it. Whatever value the promise rejected with — usually an Error subclass — is logged with the Uncaught (in promise) prefix. Add .catch() to the chain, or wrap the await in try/catch, or install a global unhandledrejection handler for telemetry.

---

Read the console, ship better bug reports

Reading the console well is a compounding skill. Every error class you recognise on sight is a debug session that ends in minutes instead of hours, and every CORS or CSP message you can name without looking it up is friction removed from a team handoff. The DevTools console has not changed dramatically in five years; what has changed is how much of a modern app's behaviour depends on cross-origin requests, async flows, and minified production code — all of which are exactly where the console earns its keep.

The Crosscheck team builds a free Chrome extension for exactly this hand-off point. When a tester or PM hits a bug, Crosscheck captures the console log, the network requests, the screenshot, and the browser environment in one click — then files it straight to Jira, Linear, ClickUp, GitHub, or Slack with the stack traces already attached. No more "what did the console say?" round-trips. For more on writing the report itself, see the perfect bug report template, and for picking the right capture tool the best bug reporting tools comparison covers the broader landscape.

Try Crosscheck free