Last updated 2026-10-11

WebKit limits and data sources

An app on iOS inspects its own web view through public WebKit APIs and a runtime it injects into the page. That is a different vantage point from a desktop browser’s built-in inspector, which sits inside the engine. Some things are simply not exposed to apps. Debrowser’s rule is to say so rather than to fill the gap with a plausible number.

The labels

Every inspected value is stored with its source and a confidence level. The interface renders them like this:

Label	Shown as	Meaning
exact	the value	Read directly from WebKit, the request pipeline or the page’s own APIs.
filtered	the value, with a count	A complete mechanism that WebKit trims, for example a subset of headers.
approximate	`≈` before the value	A good estimate from a related source, such as a size from `Content-Length`.
inferred	italics, with the label	Derived from other data, such as an initiator matched from resource timing.
unavailable	`—` and a reason	Not exposed by WebKit, blocked by the page, or not captured for this request.

Page-reported data, meaning anything that came from script running inside the page rather than from the native side, carries a “reported by page script” note.

What WebKit does not expose

Outgoing cookie headers. The Cookie request header is absent from the request events apps receive. Set-Cookie on responses is visible.
Remote addresses, TLS details and redirect chains for subresources.
Cross-origin timing. Resource Timing zeroes most phases for cross-origin requests without Timing-Allow-Origin.
Cross-origin stylesheets cannot be read from script; Debrowser re-fetches them and labels the result.
A debugger or profiler. There is no public way to attach one to an app’s own web view, so there are no breakpoints or CPU profiles.
Worker console output and the initial context of some navigating iframes.
Device pixel ratio, touch and hover emulation. Responsive mode changes the viewport, not the hardware.
The engine’s accessibility tree. The Accessibility panel derives its view from DOM and CSS.

Where values come from

Network combines the bundled request-observation runtime (statuses, filtered headers, sizes where reported) with the page’s resource timing. Bodies and timing phases appear only when they were captured.
Elements and Styles read the live DOM and the CSS object model through the injected runtime, with native frame targeting so cross-origin frames are inspected as themselves.
Console captures the page’s console methods and uncaught errors, and evaluates input natively in the page world or in the isolated world you choose.
Storage reads cookies natively and web storage, IndexedDB and caches through the runtime.

Pages that fight back

A strict Content Security Policy, Trusted Types or a sandboxed, script-disabled frame can reduce what the runtime can see or do. The inspector shows those frames as opaque instead of pretending they are empty. A pristine mode reloads the page with nothing injected, so you can check whether the inspector itself changed anything.