How to Inspect Element on iPhone and iPad, and What to Do Without a Mac

The short answer is the one nobody wants: you cannot do it on the phone. There is no Inspect Element in mobile Safari, no long-press that opens developer tools, and no setting that adds one.

What exists instead is Web Inspector, which runs on a Mac and attaches to the phone over a cable. It is the real thing - the same panels you get on the desktop, showing the page as the phone is actually rendering it - and it needs hardware most people asking this question do not have in front of them.

With a Mac, which is the proper way

Three steps, and the first two are settings you only do once.

On the iPhone or iPad. Open Settings, then Apps → Safari → Advanced, and turn on Web Inspector. On iOS 17 and earlier the path is Settings → Safari → Advanced, without the Apps level.

On the Mac. Open Safari → Settings → Advanced and tick Show features for web developers, which puts a Develop menu in the menu bar. On older versions the checkbox says “Show Develop menu in menu bar”. It is the same switch you need for inspecting anything on the Mac itself.

Then connect them. Plug the phone into the Mac with a cable and unlock it. If it asks whether to trust the computer, say yes. Open the page on the phone, then on the Mac open Develop, find the device by name in the list, and choose the page. Web Inspector opens on the Mac and is driving the phone: hover an element on the Mac and it highlights on the handset.

Two things that go wrong at this point. If the device does not appear, the phone is locked, the cable is charge-only, or Web Inspector was never switched on. And you can only inspect Safari this way - Chrome and Firefox on iOS are not inspectable from the Develop menu, though it matters less than it sounds, because every browser on iOS renders with the same WebKit engine underneath.

On an iPad, it is the same procedure

Identical, including the settings paths. The one difference worth knowing is that an iPad in Stage Manager or split view reports a viewport that is not the full screen width, so a layout bug you are chasing may depend on the arrangement rather than on the device.

Without a Mac

Three options, in descending order of how much they actually tell you.

A remote debugging service. Several companies rent real iPhones with Web Inspector attached, in a browser tab. They cost money and they work, and for a team that ships to iOS and owns no Macs, this is the honest answer.

A console shipped inside your own page. If you control the site, a small in-page console library gives you a readable log on the device itself. It is the only route that needs no second machine, and it is for development builds rather than production, because you are shipping a debugging surface to everybody.

Desktop device simulation, which is not the same thing. Chrome’s device toolbar changes the viewport, the user agent and the touch behaviour, and it is genuinely useful for checking a responsive layout. It does not change the engine: you are still looking at Blink pretending to be a phone. A bug that only appears on iOS is usually a WebKit bug, and WebKit is exactly the part the simulation is not simulating. (This is the one place Android is easier: its Chrome is the same engine as your desktop Chrome, so device mode is a reasonable first guess there.)

That last distinction is the one that costs teams a day: “it looks fine in the phone view” and “it works on the phone” are different claims.

When the person with the phone is not you

Most of the time this question is not really about tooling. Somebody reported that your site is broken on their iPhone, they are not sitting next to you, they do not own a Mac, and asking them to enable Web Inspector and find a cable is not a request you can reasonably make.

What you can ask for, and what is worth having:

• The exact iOS version and browser. Settings → General → About gives the version. “iPhone” is not an answer; iOS 26.1 in Safari is.
• A screen recording. The iPhone makes this easy from Control Centre, and it captures the behaviour, the timing, and what they tapped, which is most of what you would have watched for anyway.
• The exact wording of anything on screen, photographed if necessary. An error string is searchable in your code; a description of an error string is not.
• Whether it happens in a private tab. That one question separates a bug in your page from something an extension, a cached asset or a stale service worker is doing.

Those four go in the same place as everything else you would ask for, and our bug report guide has the rest of the shape.

We should be straight about our own limits here, since this is a page about mobile. Our extension is a desktop Chrome extension: it captures the console and the network log on a computer, not on a phone. If your visitor presses a report button on an iPhone, what they get is an explanation and a link to carry to a desktop browser - useful for getting the report filed, and not a substitute for the console output you would have had on a Mac.

For desktop bugs it removes this whole problem, because the technical half is captured by the person pressing one button. For a bug that only happens on somebody’s iPhone, a screen recording and an exact version number are still the best you are going to get without a cable.

If you are debugging your own phone

Worth stating plainly, because the long answer above is for the common case. If it is your device, your Mac and your page, connect the cable and use Web Inspector. Everything else on this page is a workaround for not being able to.

Quick reference

• iPhone/iPad: Settings → Apps → Safari → Advanced → Web Inspector on. (Settings → Safari → Advanced on iOS 17 and earlier.)
• Mac: Safari → Settings → Advanced → Show features for web developers.
• Connect by cable, unlock, trust, then Develop → device → page.
• Safari only. Every iOS browser uses WebKit regardless of its name.
• Desktop “device mode” tests the layout, not the engine.