How to open the Safari console

Safari's console is the Console tab of the Web Inspector. It is off until you turn on developer features. On a Mac: Safari, then Settings, then Advanced, then Show features for web developers. Then press Option-Command-C. Older Safari labels the checkbox Show Develop menu in menu bar.

Fixing the error you find there is how to fix JavaScript errors. Which tool to open for a layout bug or a failed request, in any browser, is website debugging tools.

Open the console on a Mac

The Develop menu does not appear until the checkbox above is on. That is the usual reason Option-Command-C seems to do nothing.

1. Open Safari. In the menu bar, choose Safari, then Settings (Command-Comma).
2. Open Advanced.
3. Turn on Show features for web developers. Older Safari calls this Show Develop menu in menu bar.
4. A Develop menu appears in the menu bar.
5. Choose Develop, then Show JavaScript Console. The Web Inspector opens with the Console tab selected. Develop, then Show Web Inspector, opens the inspector on its last tab. Click Console if that tab is not already showing.
6. You can also Control-click the page and choose Inspect Element. That opens the inspector and selects the element you clicked. The Console tab is next to it.

Reload the page after the console is open. Messages from before you opened it are not replayed, and a reload clears the console unless you preserve the log.

Keyboard shortcuts

These are the shortcuts Apple documents for the Web Inspector, and they match the items in the Develop menu. They apply after developer features are on.

Option-Command-I opens the inspector. If it opens on Elements or Network, click Console. Option-Command-C is the direct path to the console.

Safari on iPhone or iPad

Safari on the phone does not show a Web Inspector console for the page you have open. You inspect that page from Safari on a Mac. The phone has to allow it first.

1. On the iPhone or iPad, open Settings, then Apps, then Safari, then Advanced, and turn on Web Inspector. Older iOS puts the same switch at Settings, then Safari, then Advanced. The label change is the settings app grouping Safari under Apps. The switch is still named Web Inspector.
2. On the Mac, turn on Show features for web developers, as above, so the Develop menu exists.
3. Connect the device to the Mac with a cable. Unlock the device. If the device asks whether to trust the computer, tap Trust.
4. Open the page in Safari on the device and leave it in the foreground.
5. On the Mac, open the Develop menu. The device name is a submenu. Choose the page.

The Web Inspector opens on the Mac, attached to that page. Errors, warnings, and console.log output from the phone land in the Console tab. The Network tab is the request list for the same page.

If the device is missing from the Develop menu, check that Web Inspector is on, the cable is connected, the device is unlocked, and the page is open in Safari rather than in another app's in-app browser. A page inside an app that does not expose its web view will not be listed.

Reading the console

The console shows three kinds of lines you will act on.

• Errors stop the script that threw, or report a failed load. Read the message and the first stack frame that is your file.
• Warnings are the browser objecting without stopping the script. A warning can still explain a blank widget. It is not automatically the bug.
• Logs are console.log, console.info, and console.debug. They are whatever the page decided to print.

Use the filter at the top of the console if the log is long. Filter to errors when you only need the failure. If the console looks empty, check that the level filter is not hiding errors.

Turn on Preserve Log before you reload or follow a redirect. Without it, a form that navigates away takes the error with it. The Network tab has its own preserve control. Turn that on too when the failed request happens on the page you just left.

The Network tab is where a 404 or a 500 shows up. Select the red row and read the status, the URL, and the response. A script that then throws SyntaxError because it tried to parse an HTML error page is a consequence of that response. The request is the first fact.

Failures that show up in Safari and not in Chrome

These are differences you can check in this console. They are not a compatibility catalog. Confirm the message on the Safari version that failed before you change code for it.

A missing API. A method or constructor that exists in Chromium can be absent in the Safari version you have open. The console shows a ReferenceError (x is not defined) or a TypeError (x is not a function). Feature-detect before you call it, or ship a build that does not call it on that version. The console on that Safari is the evidence. A Chrome pass does not cover it.

Date parsing. Date accepts ISO 8601 strings reliably. Other shapes, such as 2026-11-05 00:00, can be Invalid Date in Safari when another browser parses them. Log Number.isNaN(date.getTime()) before you format the value. If it is invalid, parse an ISO string instead of asking each engine to guess.

Storage and cookies. Safari restricts third-party cookies and can partition storage that Chrome still accepts. A login that depends on a third-party cookie can succeed in Chrome and fail in Safari with an empty console. The Network tab shows whether the cookie was sent. A script that writes localStorage in a context Safari blocks will throw. Read that exception. Do not assume the Chrome path ran.

Layout differences, including viewport height and form controls, often produce no console error at all. For those, use the Elements tab of the same inspector. A wider checklist of what to compare across engines is in how to test a website on different browsers.

What Monito records instead

Monito runs desktop Chromium, usually at 1440×900. It does not run Safari, Firefox, or a phone, and it does not open Safari's console. A check will not reproduce a bug that exists only in Safari.

What a check records is the console of its own Chromium run, plus screenshots and network requests as method, URL, and status. The run ends Passed, Failed, or Error. Error means the check could not verify the scenario. It is not a Safari result, and it is not a verdict that the app is fine. What cannot verify means.

Use the Web Inspector when the bug is in Safari. Use a Monito check when you want the same Chromium scenario again, with the console and the requests from that run.

FAQ

How do I open the console in Safari?

In Safari, open Settings, then Advanced, and turn on Show features for web developers. Then choose Develop, then Show JavaScript Console, or press Option-Command-C. Older Safari calls that checkbox Show Develop menu in menu bar.

What is the Safari console shortcut?

Option-Command-C opens the console. Option-Command-I opens the Web Inspector. Both work after Show features for web developers is on. Until that checkbox is on, the shortcuts do nothing.

How do I see the console for Safari on iPhone?

On the iPhone, turn on Web Inspector under Settings, Apps, Safari, Advanced. Older iOS uses Settings, Safari, Advanced. Connect the phone to a Mac with a cable, open the page in Safari on the phone, and on the Mac choose Develop, then the phone's name, then the page. The console is the Console tab of that Web Inspector. Safari on the phone does not show this console itself.

Run a Chromium check

Run your first test, or use the check command. For a Safari-only failure, stay in the Web Inspector.