How to read a console error as a non-developer

The browser console is where a website reports its own failures. You do not need to write code to use it. You need to know how to open it, how to tell a real error from routine noise, and which few lines are worth passing on.

That skill turns "the page is broken" into "the page logged this specific error", which is often the single most useful sentence in a bug report.

How do you open it?

The developer tools open with F12 on Windows and Linux, or Command + Option + I on a Mac. You can also right-click the page, choose Inspect, and select the Console tab.

Two habits make what you see far more useful:

Open it before reproducing the problem. The console only shows what happens while it is open, or since the page loaded. If you open it after the failure, you may be looking at an empty panel.

Reload the page with it open, then repeat the action. This captures both the loading errors and the errors caused by what you did.

The Network tab next to Console is worth a glance too: it shows requests the page made, and a red row there usually means the page asked the server for something and did not get it.

What is a real error and what is noise?

Most consoles contain messages on a working site. Colour is your first filter, and it is not perfect.

Red is an error — something failed. This is what you are looking for, though not every red line is related to your problem.

Yellow is a warning. Usually a deprecation notice or advice to a developer. Rarely the cause of a visible failure.

Grey or white is informational logging. Almost always irrelevant.

Beyond colour, judge by timing. An error that appears exactly when you perform the failing action is far more likely to be relevant than one that was already there when the page loaded. Perform the action while watching, and note what appears at that moment.

Common noise worth ignoring: messages mentioning browser extensions, blocked third-party trackers, favicon requests, and warnings about cookie policies from analytics scripts. These appear on healthy sites constantly.

What do the common errors mean?

You do not need to diagnose these. Recognising the family helps you describe what you saw.

TypeError: Cannot read properties of undefined (reading 'x') — the page expected some data and it was not there. Very often a symptom of a failed request earlier: the data never arrived, so the code that needed it broke.

404 on a request — the page asked for something that does not exist at that address. A missing image, script, or endpoint.

500 on a request — the request reached the server and the server failed. The cause is on the server, not in your browser. This is a strong, specific signal worth reporting.

403 or 401 — a permission or sign-in problem. Sometimes an expired session.

Failed to fetch or a network error — the request did not complete. Could be connectivity, could be the server being unreachable.

A CORS message — the page tried to reach a different domain that did not permit it. Usually a configuration issue rather than something you caused.

The general shape of an error is: the type, the message, and the location — a file name and a line number. All three are useful. The location is genuinely helpful to whoever investigates, even though it means nothing to you.

What should you copy, and what must you not?

Copy the first relevant red error in full, including the file and line reference. If several appeared together, the first is usually the origin and the rest are consequences.

If a request failed, note its method, path, and status — for example, POST /api/profile returned 500. The Network tab shows these directly. That single line frequently locates a problem faster than a long description.

Be careful about what else you copy. Console output and network details can contain private values:

• Never copy an authentication token, session identifier, or API key. These sometimes appear in request details, and they are credentials.
• Never copy request or response bodies containing personal data, card details, or customer records.
• Do not share cookie values.
• Check a screenshot of the console before sending it — the surrounding tabs and rows may contain more than the error itself.

If in doubt, send the error type, the message, the file and line, and the failed request's method, path, and status. That is almost always sufficient, and none of it is private.

How do you use this in a report?

Combine the console evidence with what you were doing. The error alone lacks context; your description alone lacks specificity.

A strong report reads something like:

I selected Save on the profile page and the page showed Something went wrong. The console showed TypeError: Cannot read properties of undefined (reading 'name') at profile.js:212, and the Network tab showed POST /api/profile returning 500.

That is three facts — an action, a logged error with a location, and a failed request — and it points at a specific place in specific code. Compare it with "saving doesn't work", which points nowhere.

If you find nothing in the console, say so. "No console errors appeared" is real information: it suggests the failure is silent or on the server, and it saves someone from checking the same thing.

Can this be collected automatically?

Yes, and for most visitors it should be. Asking every visitor to open developer tools is unrealistic, and the ones who try may send screenshots containing more than they intended.

IssueProbe collects this context when a visitor sends a report through its widget, available in English, Portuguese, and Spanish. Console evidence is limited to errors and warnings, kept to a bounded number of items, with token-like and email-like text redacted on both the client and the server. Failed or slow requests are recorded as a method, a path without query values, a status, a duration, and a time — never headers, bodies, credentials, query values, or fragments.

Browser state stays metadata only: a name, whether the item is present, and its size, with no value in any case. A screenshot is included only after a visible capture action, a preview, and explicit consent, and can be removed before sending.

Read what browser evidence helps investigate a website problem for how each category is used, and the widget privacy rules for the exact fields collected.