Inspect Element on iPhone & Android: Web Inspector

To debug mobile web pages, use the web inspector built into Trace Eagle: connect an iPhone, iPad or Android device to your computer with a cable, pick a page and click Inspect, and full developer tools open in your desktop browser — Elements, Console, Sources, Network and Storage, attached to the real page on the device, which re-renders the moment you change a value. Browser tabs and in-app WebView / H5 pages both work, with no certificate, no proxy, and no need to modify or rebuild the app.

Web inspector debugging an Android page: the live phone screen on the left, the Elements panel with computed styles on the right

How is the web inspector different from packet capture?

You want both, but they answer different questions:

	Packet capture	Web Inspector
Answers	What went over the network	What the page did
Shows	Requests / responses, headers, bodies (decrypted)	DOM tree, computed styles, console errors, call stacks, cookies and storage
Typical question	What did this endpoint return, are the parameters right	Which line of JavaScript sent this request, why didn’t that style apply

Capture shows you the request but never the caller; the inspector lets you set a breakpoint in Sources and step back to the line that sent it. Both live in the same tool, so moving between them costs nothing. To read the API traffic itself in plaintext, see how to decrypt HTTPS.

What do I need to set up first?

The three blocks below are alternatives — do the one that matches your target, and only once.

Which switch do I turn on for iPhone / iPad?

Plug in the cable, keep the device unlocked, and turn on the Web Inspector switch:

Safari: Settings → Safari → Advanced → Web Inspector
Chrome: Chrome Settings → Content Settings → Web Inspector

This switch is the step people miss most often on iOS. Without it the device is detected, but the page list comes back empty.

It’s the same switch Apple’s own Safari Web Inspector uses — no jailbreak involved.

What do I enable on an Android phone?

Plug in the cable and enable USB debugging in Developer options. Android emulators are usually picked up without a cable. It’s the same switch Chrome’s official Android remote debugging asks for.

How do I attach a browser on this computer?

Start Chrome or Edge with --remote-debugging-port=9222, then hit Refresh in the page list:

# macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --remote-debugging-port=9222

# Windows
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222

Can I debug a WebView inside an app?

Yes. Skip this section if browser tabs are all you need.

For your own app, switch it on once in code (for Android, see Chrome’s guide to debugging WebViews):

// Android: call once when the Application or Activity starts
WebView.setWebContentsDebuggingEnabled(true);

// iOS 16.4 and later: make the WKWebView inspectable
webView.isInspectable = true

For someone else’s app, or when changing code isn’t an option: tick “Also include pages inside apps” in the dialog and the pages running inside currently-open apps join the list. Untick it and you’re back to browser tabs only.

	Requirement	Notes
Android	A rooted device	Enables WebView debugging on running apps, with no repackaging
iOS	Dev-signed apps only	A system limit — apps installed from the App Store can’t be included

Either way, you never rebuild the app, sign anything, or install a helper on the device. When the session ends, the device is back to how it was.

How do I start a debugging session?

With setup done, every session is just this:

New capture → target (This computer / iOS / Android) → method “Web inspector” → Refresh → pick the page → Inspect

New-capture dialog with Android selected and the Web inspector method, listing debuggable pages after ticking “Also include pages inside apps”

Pages are listed grouped by the app that owns them, so an in-app page is easy to tell from a browser tab.
Click Inspect and full developer tools open in your desktop browser, attached to that page on that device.
Open as many as you like — one window per page, all live at once.

Which panels do I get?

The same panels you use on the desktop every day, pointed at the page on the phone.

Panel	What it does
Elements	The page’s live DOM tree with computed styles, inheritance and the box model. Change a value and the device re-renders on the spot — the fastest way to pin down a mobile layout bug
Console	Every error and log the page produced, plus a prompt that runs your JavaScript inside that page on that device
Sources	Browse the scripts and stylesheets the page loaded, set breakpoints, walk the call stack and inspect variables at the moment things go wrong
Network	Every request the page made, in a waterfall: status, type, initiator, size, timing and cache state, with totals for requests, bytes, DOMContentLoaded and full load time
Storage	Cookies grouped by domain with expiry, Secure, HttpOnly and SameSite, next to localStorage and sessionStorage — the fastest way to unpick a login-state bug

Storage panel of the web inspector: the cookie table for a page open on an iPhone, with value, domain, expiry, Secure, HttpOnly and SameSite

On Android, the live device screen is mirrored beside the panels and you can click and scroll it with the mouse — inspect and operate on one screen instead of juggling phone and keyboard.

Which devices and pages are supported?

	This computer	iOS	Android
Browser tabs	✓	✓	✓
Pages inside apps (WebView / WKWebView / H5)	✓	✓	✓
Emulator / simulator	—	✓	✓
Inspect and edit elements & styles live	✓	✓	✓
Console, breakpoints and step-through	✓	✓	✓
Network waterfall for the page	✓	✓	✓
Cookies / localStorage / sessionStorage	✓	✓	✓
Live device screen beside the panels	—	—	✓
No certificate and no proxy to set up	✓	✓	✓

Why is the page list empty?

Symptom	Usually	What to do
Device detected, page list empty	The iOS Web Inspector switch is off, or the screen locked	See setup; turn it on, keep the device unlocked, then Refresh
Android shows no in-app pages	That WebView never had debugging enabled	Your own app: add `setWebContentsDebuggingEnabled(true)`. Someone else’s: tick “Also include pages inside apps” (rooted device)
One iOS app never appears	A system limit	App Store builds can’t be included — only dev-signed apps can
The local browser lists no pages	It was started without the debugging port	Restart Chrome / Edge with `--remote-debugging-port=9222` and Refresh
Inspect does nothing	An unsupported browser	Android and local sessions need Chrome, Edge or Brave

When should I reach for the web inspector?

The page breaks only on the phone: layout, hit areas, font rendering.
An H5 page is blank or broken and you need console errors and a call stack.
You want to know which script sent a request — capture alone won’t tell you.
You’re chasing a login or cache problem and need to see what’s really in cookies and storage.
You’re debugging H5 embedded in an app, where ordinary tooling gives you nothing.

FAQ

How is this different from chrome://inspect?

The browser’s built-in remote debugging page only sees Chromium targets on Android. The web inspector puts iOS, Android and the local browser in one picker, groups pages by app, and adds in-app H5 with one checkbox — right next to capture that can decrypt the same app’s HTTPS traffic.

Do I need to jailbreak an iPhone to debug its pages?

No. Plug in, unlock, and turn on the Web Inspector switch; in-app pages are limited to dev-signed apps. Capturing the iPhone’s API traffic is jailbreak-free too — see how to capture iOS traffic.

Does the web inspector cost anything?

No. Like every other Trace Eagle feature it is completely free, on macOS, Windows and Linux.

Does debugging leave anything on the phone?

No. Nothing is installed on the device and the app is never rebuilt or re-signed; when the session ends, the device is back to how it was.

Back to Getting started · Related: Inspect & decode · iOS capture · Android capture