Flawsnap
Free trial

Browser console logs, explained for bug reports

What the console is, how to read the errors you will see most often, and how to include them in a report.

Console logs are messages a web page writes to the browser's developer console: errors, warnings, and information added by developers. When something breaks, the console often shows the cause, such as a JavaScript error or a blocked request. Including the red error lines in a bug report usually points a developer straight to the failing code.

What the console is

Every modern browser has developer tools, and the console is one panel in them. Two things write to it: the page's own code, through calls like console.log() and console.error(), and the browser itself, which reports uncaught errors, failed resource loads, security blocks and deprecation warnings.

You do not need to understand the code to use it. For a bug report, the job is to notice the red lines that appeared when the problem happened and copy them.

Log levels and what they mean

LevelHow it looksWhat it usually means
ErrorRed, often with a stack traceSomething failed. Most relevant to a bug report.
WarningYellowSomething may be wrong or is deprecated. Sometimes relevant.
Info / logPlain textMessages developers added. Context, rarely the cause.
Debug / verboseHidden by defaultDetailed tracing for developers.

Common errors, decoded

  • `TypeError: Cannot read properties of undefined (reading 'x')`: the code expected some data that was not there, often because an API returned something unexpected. Check the network log for that moment.
  • `Uncaught (in promise)`: an asynchronous operation, usually a request, failed and nothing handled the failure. Often the visible symptom is a button that does nothing.
  • `Failed to load resource: the server responded with a status of 404`: a file or API address does not exist. A 500 instead means the server failed.
  • `Access to fetch ... has been blocked by CORS policy`: the browser refused a request to another domain because the server did not allow it. This is a server configuration issue, not something the user did.
  • `ReferenceError: x is not defined`: the code used something that does not exist, often because a script failed to load or loaded in the wrong order.
  • `Refused to load the script ... Content Security Policy`: the site's security policy blocked a script. Common after adding a new third-party tool.
  • `ResizeObserver loop` or similar warnings: usually harmless noise. Mention them only if nothing else appears.

How to open the console

  • Chrome, Edge and Brave: press F12, or Ctrl+Shift+J on Windows and Linux, Cmd+Option+J on a Mac.
  • Firefox: press F12, or Ctrl+Shift+K on Windows and Linux, Cmd+Option+K on a Mac.
  • Safari: first turn on the developer features in Safari's Advanced settings, then press Cmd+Option+C.
  • On a phone, the console is only reachable by connecting the phone to a computer, which is why automatic capture matters for mobile reports.

Capturing the right lines

  1. 1

    Open the console before reproducing

    Some messages only appear once. Open DevTools first, then repeat the steps.

  2. 2

    Clear old messages

    Use the clear button so only messages from your attempt remain.

  3. 3

    Keep the log across page loads

    If the bug involves a redirect or a form submission, tick "Preserve log" in Chrome or "Persist Logs" in Firefox.

  4. 4

    Reproduce the bug

    Note which messages appear at the moment it goes wrong.

  5. 5

    Copy as text

    Right-click the console and save or copy the messages. Text is searchable; a screenshot of the console is not.

  6. 6

    Check the Network panel too

    Failed requests show in red there, with the status code. The console tells you what broke; the network panel often tells you why.

Before you paste logs anywhere

Console messages can contain email addresses, tokens or other personal data if developers logged them. Read the lines before sharing them outside your team, and remove anything that looks like a key or a password.

Capturing logs automatically

Most people reporting a bug will never open DevTools. A bug reporting script that runs in the page can collect the same information in the background. Flawsnap's widget attaches the last 100 console messages and uncaught errors, plus the last 100 fetch and XHR requests with method, URL, status and duration, to every report on both plans. It never captures request or response bodies. To catch messages from the very start of the page, load the script in the <head>. See console and network logs.

Questions

Is it safe to open the browser console?
Opening and reading it is safe. Be careful about typing or pasting anything into it, especially code someone else sent you, because code run in the console acts as you on that site.
Why is the console full of errors on a site that works fine?
Many sites log harmless warnings, blocked trackers and errors from third-party scripts. What matters for a bug report is which messages appear at the moment the problem happens, which is why you clear the console first.
What is the difference between the console and the network tab?
The console shows messages and errors from the page's code and the browser. The network tab lists every request the page made, with its status and timing. A failed request often causes a console error, so the two are best read together.
Do mobile apps have a console?
Apps write logs too, but there is no console on the phone itself. Developers read them by connecting the device to a computer, or an in-app reporting SDK collects recent log lines and attaches them to each report.

Try it on your own site

7-day free trial, then $9 a month for Starter or $19 for Pro, per organization, with unlimited team members.

Start free trial Try the live demo

Related

Updated