How to use Safari Developer Tools on a Mac in 2026

Safari buries its web developer features behind a settings toggle. Always has. On a Mac in 2026 the whole setup takes about five minutes: flip one switch in Safari’s preferences, open Web Inspector, then inspect a page, test responsive layouts or debug web content running on an iPhone or iPad. Apple Support is direct about it — Safari won’t show the Develop menu until web developer features are turned on. Apple’s developer documentation covers the full toolset for inspecting and debugging content in Safari, other apps and connected devices.

No extensions. No third-party utilities. Just the tools Apple already ships with Safari.

Before you start

You need a Mac running a recent version of Safari. If the job involves inspecting a site on an iPhone or iPad, keep that device nearby and signed in to the same Apple Account. Have a page open in Safari before flipping the toggle — you want something to inspect right away.

First pass takes about five minutes. After that, opening Web Inspector becomes muscle memory.

1. Turn on Safari’s developer features

Open Safari. In the menu bar, choose Safari > Settings, then the Advanced tab. Near the bottom, switch on Show features for web developers.

Safari locks Web Inspector, responsive design mode and remote inspection behind that single toggle. Miss it and the Develop menu stays invisible. Apple’s own support page confirms: if the menu is missing, open Safari settings, go to Advanced and enable web developer features. That solves it almost every time.

Flick the switch and a Develop item appears in the Mac menu bar — that is the hub for Safari’s debugging and inspection tools. If it does not show immediately, close the Settings window and look again. It usually lands between Bookmarks and Window.

2. Open Web Inspector on the page you want to check

Load the page you want to inspect. Pick Develop > Show Web Inspector.

Safari docks the inspection panel to the browser window. Most of the real work lives here: scanning HTML structure, reviewing CSS, watching console output and confirming what the browser is actually doing with the page.

Begin with exploration, not edits. Click around before modifying anything. The goal is orientation — recognise the panel layout, verify the tool is responding, then make one small change you can see on screen.

Grab a specific element: a button that looks misaligned, a heading with odd spacing, a nav link that breaks at narrow widths. Small, isolated targets teach you more than a whole page of nested containers.

3. Inspect an element and test a quick style change

With Web Inspector open, select an element and review the HTML and CSS attached to it.

This workflow answers front-end questions faster than hunting through source files. Which class is active? Where did that extra margin come from? Is a colour declaration being overridden further down the cascade? Why does this block jump at 768 pixels wide? The inspector shows the computed result, not just the authored rule.

Try one visible edit. Push a margin up. Uncheck a CSS property. Adjust a font size by a few pixels. Watch the page update in place, then undo it.

That feedback loop is the payoff. Once you see Safari render a live edit, the tool stops feeling foreign. It becomes a browser inspector — Apple’s version of it, with its own menu layout and its own quirks, but fundamentally the same idea.

4. Use the Develop menu for the tools you need most

Web Inspector grabs attention because it opens a panel, but the Develop menu itself is broader. Apple’s Safari tools overview organises the developer features around three jobs: inspection, debugging and testing.

Three paths cover most day-to-day work:

1. Open Web Inspector when the question is about page structure or styling.
2. Responsive Design Mode when the problem depends on viewport width.
3. Device inspection when the bug only reproduces on an iPhone or iPad.

Skip the urge to memorise every menu entry. Match the tool to the task. Layout glitch? Inspector. Mobile breakpoint? Responsive mode. iOS-only failure? Remote device inspection.

5. Test responsive layouts without leaving Safari

When the trouble is layout rather than markup, switch from inspecting individual elements to testing at different widths.

Enter Safari’s responsive view from the Develop menu. The UI shifts slightly between Safari versions, but the function does not change: preview the page at device-sized widths without opening another browser.

Work through the obvious break points:

• Does the navigation collapse without dropping links?
• Do headings wrap mid-word or too early?
• Does a call-to-action button disappear below the fold?
• Do images or embedded widgets shove the layout sideways on narrow screens?

Move deliberately. Resize, inspect, resize again. A single careful pass catches more issues than racing through a dozen preset device widths.

Found something broken? Jump straight back into Web Inspector and patch it live. That tight loop — spot the bug, inspect the element, rewrite the rule, confirm the fix — is why the built-in tools earn their place in a daily workflow.

6. Inspect web content on an iPhone or iPad when desktop testing is not enough

Certain bugs never show up on a Mac. Touch interactions. Mobile Safari rendering decisions. Web views embedded inside apps. These behave differently from a desktop tab and there is no reliable way to simulate them.

Cross-device inspection closes that gap. Apple’s documentation states the same developer tools can attach to content running on a connected iPhone or iPad, not just pages open on the Mac.

The sequence:

1. Enable the Develop menu on the Mac.
2. Open the page or web content on the iPhone or iPad.
3. From the Mac’s Develop menu, locate the connected device and pick the page to inspect.
4. Web Inspector opens against the live mobile session.

Reach for this when a page works on desktop but fails on iOS, or when an in-app browser renders things differently from standalone Safari. It anchors the debugging session inside Apple’s own browser stack instead of guessing from Chrome’s engine.

7. Use Safari Developer Tools as a daily check, not a last resort

The most common mistake is treating Web Inspector like a fire extinguisher — break glass in case of emergency. It works better as a quick daily tool.

Open it when:

• a CSS rule seems to have no effect;
• a layout cracks at a narrower width;
• a page acts differently on an Apple mobile device;
• you need to confirm whether the problem is markup, styling or browser behaviour.

Short sessions compound. Inspect, answer one question, close the panel. That rhythm builds fluency much faster than saving the inspector for a marathon debugging session every few weeks.

Teams that default to Chrome should still keep Safari in the testing rotation. It gives Mac and iOS developers a direct read on how Apple’s rendering engine handles the page — which is what matters when a client reports that the bug only happens in Safari.

Troubleshooting if the tools do not appear

Missing Develop menu? Return to Safari > Settings > Advanced and confirm Show features for web developers is still switched on. Start here. It is the fix roughly every time.

Blank Web Inspector? Reload the page and try Develop > Show Web Inspector again. Some pages inspect more cleanly after a fresh load.

Device not showing for remote inspection? Strip the process to its essentials: Mac first, Develop menu on, target page already open on the iPhone or iPad, then reconnect through the Mac’s Develop menu.

And if Safari’s tooling feels pared-down next to Chrome’s — that is accurate, not a malfunction. Safari’s developer features are capable but understated. The learning curve is less about hidden depth than hidden doors.

What to do next

With the Develop menu enabled, repetition is the most useful next step. Open Web Inspector on a live page, test one CSS edit, then try the same page in responsive mode. If your work touches mobile Safari, run through the same page on an iPhone or iPad and inspect it from the Mac.

That sequence covers the core of Safari Developer Tools in 2026: enable the menu, inspect the page, test across widths, then move to device-level debugging only when the browser on your desk stops being enough.