Somebody has probably asked you to “open inspect element and tell me what the console says”. Here is how, on a Mac, in both browsers - and Safari needs one setting switched on first, which is why this question gets asked twice.

Chrome

Three ways, and the first is the one to remember.

  • Right-click the thing that looks wrong, then choose Inspect. The panel opens with that element already selected, which is the whole point: you asked about this button, not the page.
  • ⌥⌘I opens the panel wherever you are.
  • ⌥⌘J opens it directly on the Console tab, which is what somebody usually wants when they say “check for errors”.

The panel opens beside or below the page. Drag its edge if it is too narrow, and use the three-dot menu at its top right to move it to the bottom, which is easier on a laptop screen.

Safari

Safari hides all of this until you ask for it, and this is the step people miss.

  1. Open Safari → Settings (⌘ comma).
  2. Choose the Advanced tab.
  3. Tick Show features for web developers.

A Develop menu appears in the menu bar, and only then does the rest work:

  • Right-click → Inspect Element on any part of the page.
  • ⌥⌘I opens the Web Inspector.
  • ⌥⌘C opens it focused on the Console.

On older versions of macOS the checkbox reads “Show Develop menu in menu bar” instead, in the same place. If you cannot find either, you are looking at Settings for a different application - Safari must be the frontmost window.

Reading the Console, which is what you were probably asked for

The Console is the tab that answers “is anything broken”. It holds messages the page wrote while you were using it, and they come in three kinds worth telling apart.

Not usually the problem
Warnings in yellow, and messages from analytics, chat widgets, ad scripts or browser extensions. Long, noisy, and mostly somebody else's
Worth reporting
Errors in red, and especially the first one. An error mentioning a file from the site's own address is far more likely to be the bug than the twelve that name a third party

Two practical notes. Errors are often already there before you do anything, left over from loading, so reload the page and then do the thing that fails - the error you want is the one that appears at the moment it breaks. And the Console has a filter box: typing part of a word cuts a hundred lines down to the one you need.

To send an error on, right-click the red line and copy it, or select it and press ⌘C. A screenshot of it works too, as long as the whole line is visible.

The Network tab, for when nothing loads

If the page looks empty rather than wrong, the Console may say nothing and the Network tab will say everything. Open it, reload, and look at the Status column: numbers in the 400s and 500s are requests that failed, and the URL beside them says what the page was trying to fetch. That is the difference between “the site is broken” and “one request to one address came back 503”.

Inspecting a page that is on your iPhone

Not on the phone. Safari’s Web Inspector runs on the Mac and attaches to the phone over a cable: enable Web Inspector on the phone under Settings → Apps → Safari → Advanced, connect it, and the device appears in the Mac’s Develop menu. The full procedure, and what to do without a Mac, is its own article.

It is the right tool for a mobile-only bug and the wrong one for a person who is not sitting next to a Mac, which is most people who have just hit a mobile-only bug.

Session Replay

Free Chrome extension. One click on the page that is misbehaving captures the screenshot, the console and the network log, and hands you a link to paste into the ticket.

Get the extension

If you are the one asking somebody else to do this

Worth saying plainly, because this article exists mostly because that request gets made.

Asking a colleague, a tester or a customer to open developer tools, find the right tab, judge which red lines matter and copy them accurately is asking for several skills at once. Most people will send the first red line they see, which is usually an analytics warning, and the exchange costs two messages and a day.

The instruction that works, if you are going to ask at all: reload, do the thing that breaks, open the Console with ⌥⌘J, and send me everything red. Precise, and it puts the judgement on you rather than on them.

The alternative is not asking. If the technical half of a report can be captured by the person pressing one button, then knowing where the Console lives stops being a prerequisite for reporting a bug - and the bug report arrives with what happened, what was expected, and the console and network logs already attached.

Quick reference

  • Chrome: right-click → Inspect, or ⌥⌘I, or ⌥⌘J for the Console.
  • Safari: Settings → Advanced → Show features for web developers, then ⌥⌘I or ⌥⌘C.
  • Reload before reproducing, so the errors you see belong to the failure.
  • Red lines mentioning the site’s own address matter most; the first one matters more than the rest.