The panels
WebDebugX does not reimplement DevTools. It bundles the genuine front ends and points them at a page running somewhere else:
| Target | Inspector |
|---|---|
| iOS / iPadOS pages | WebKit Web Inspector — the one Safari uses |
| Android and Chromium pages | Chrome DevTools |
The two differ in layout and panel names, because upstream differs. Everything below exists in both, under one name or the other.
Elements
Section titled “Elements”The live DOM of the page as it exists on the device, with computed styles and the box model. Edits apply immediately to the running page — change a rule and watch the handset in your hand redraw.
Use it for: layout that only breaks at one viewport, a style that is being overridden, an element that is not where you think it is.
Console
Section titled “Console”The page’s own log output, warnings and errors, plus expression evaluation in the page’s real context.
Use it for: the actual error text behind “it just doesn’t work”, and for poking at real
state — location.href, a global, the value your code thinks it has.
Sources
Section titled “Sources”The scripts the page actually loaded — after your bundler, after the CDN — with breakpoints, stepping, call stack and scope inspection. Source maps resolve as they do locally, provided they are reachable from the device.
Use it for: stepping through logic on the device where it misbehaves, instead of guessing from logs.
Network
Section titled “Network”Every request the page made, with headers, payload, status and timing.
This comes from inside the page, which has two consequences worth stating plainly:
- No certificate and no proxy. HTTPS is readable because you are looking at the page’s own view of its requests, not at intercepted traffic.
- It is the page’s traffic, not the device’s. Requests made by native code in the app, outside the web view, do not appear here. That is a packet-capture question, not a DevTools one.
Storage
Section titled “Storage”Cookies, localStorage and sessionStorage as they exist on the device.
Use it for: the stale token, the flag left over from a previous release, the value QA’s phone has and yours does not. This is invisible to packet capture, and it is very often the answer.
Performance and memory
Section titled “Performance and memory”Profiling on the hardware that is actually slow. A mid-range phone and a developer laptop do not share a performance profile, and optimising against the laptop optimises the wrong machine.
What is not here
Section titled “What is not here”WebDebugX inspects web pages. It does not capture device-wide network traffic, decrypt traffic outside the page, or inspect native (non-web) UI. If the thing you need to see never passes through a web view, this is the wrong instrument.