Network tab

Four capture paths feed one list:

WebSocket connections and server-sent event streams share the same list. It holds the 1,000 most recent requests and, apart from them, the 1,000 most recent sockets. Older ones fall off the end. Request and response bodies are kept in full, never truncated, unless redaction rewrites them first.

Toolbar

Filters panel

Every filter combines with the search. Invert negates all of them together except the two Hide switches, which stay absolute. Inverting those would bring back the exact noise they suppress. A filter an entry has no figure for excludes it: a socket has no size or status code, and a request in flight has no duration yet. A type, status or Only overridden or blocked filter leaves sockets out for the same reason.

Settings panel

Throttle profiles

Applied to your app's own requests and to wired-up WebView pages.

Custom starts at 750 kbps down, 375 kbps up and 500 ms.

Picking Custom under User agent reveals a free-text field for the whole UA string. Every captured request records the conditions it ran under, so the detail sheet can show them later.

Overview strip

Shown when Show overview is on, and only once at least one request is captured.

• 36 buckets spanning the oldest to the newest captured request; bar height is request count.
• A bucket containing a failed request is drawn in the error colour.
• Tap a bucket to narrow the list to that slice of time; tap it again to clear.
• The row underneath shows the first timestamp, the total span (or the selected range), and the last timestamp.

A request row

The row menu: Try in sandbox, then Copy URL, Copy as cURL, Copy as fetch, Copy as fetch (Node.js), then Copy request payload and Copy response when those exist, Share response body when there is a body at all (the only way to get an image or a PDF out), then Block this URL and Override response…. The sheet's own menu is the same list without Override response…, since that editor opens from the list.

A socket row

A WebSocket is a row in the same list, so the search, the grouping and the sort all reach it. It is not a request, and the row says so.

Tapping one opens the message log rather than the request sheet: the URL, badges for status, frame count, negotiated subprotocols and close code or reason, then one row per frame. A socket keeps its last 1,000 frames, and the log shows all of them. Each frame shows its direction (▲ sent, ▼ received), its payload, BIN for a binary frame, and the time. It keeps filling while you read it, because the socket is still open.

Turn socket capture off with network: { websocket: false }.

Overrides

Two items on a row's ⋮ menu answer a request instead of the network.

The editor is seeded from what was actually captured, so overriding a response means editing the real one rather than retyping it. Reopening it on a URL that already has a rule loads that rule instead. A status that is not a number between 100 and 599 is saved as 200.

Rules are keyed by the whole URL, never a pattern: a rule that matched more than you meant is a request you cannot explain, and the row a rule is made from always knows its exact URL. A row a rule answered is badged Blocked here or Overridden here in the list, so it can never be mistaken for one of the server's own replies, and the filter panel's Only overridden or blocked narrows to exactly those.

Rules live in memory for the session. There is no config option for them and nothing is persisted.

Detail sheet

Tapping a row opens a sheet of tabs. It always opens on Headers. Payload is only offered when the request had a body, Initiator only when a call stack was captured, and a stream swaps Preview and Response for Events.

On Payload, Preview (for text) and Response, a search box sits above the body, with the same match case, whole word and regex switches as the list's. A body over 50,000 characters is too large to search, and the sheet says so.

Headers

The other seven

• Payload: the request body. JSON is an explorable tree, with View source to see the raw text; anything else is shown as text. A form upload lists each field, and each file by name, type and size. Hidden entirely when the request had no body.
• Preview: the response rendered: pretty-printed and syntax-coloured JSON, a real image for image responses, HTML as HTML, XML as a collapsible tree. Falls back to No preview available.
• Response: the raw response body, in full, with a copy button.
• Events: a server-sent event stream's dispatched events, newest first, each with its type, its id when the stream sent one, the time, and the data pretty-printed under its own copy button. The last 200 are rendered and the count says so. It sits where Response and Preview do for an ordinary request, since a stream's events are its body.
• Timing: below.
• Cookies: below.
• Initiator: the call stack that made the request. Symbolicated on open rather than at capture, because it is a round trip to the dev server and only the request you actually opened is worth spending one on. Library frames are dimmed, and the failing source line is shown above the frames when the dev server returned it. Without a dev server the frames stay as bundle positions and the tab says so.

Timing

Started At, then one of two things.

When the platform's own networking stack reported on this request, a waterfall: a Total track with each measured phase laid out inside it.

Badges above it name which stack measured it (URLSession on iOS, OkHttp on Android, or the page's own engine for WebView traffic), the protocol that was negotiated, and whether the connection was reused. A Total marked app clock came from the patches instead, because the platform sent no total of its own.

Otherwise, Time to headers, Body download and Duration ((pending) while in flight), measured from JavaScript, with a note saying whether phases were unavailable for this one request or unavailable in this build at all.

Cookies

Every cookie this request sent, every cookie the response set, each with its attributes (Domain, Path, Expires, Max-Age, SameSite, Secure, HttpOnly). For a wired-up WebView there is a third list, what the page itself could read, which is not the same set: a page cannot see an HttpOnly cookie.

Read from this request's own Cookie and Set-Cookie headers and nothing else. A cookie the platform's own jar attached, without it appearing in those headers, is invisible here, and the tab says so rather than implying the list is complete.

Sandbox

Opens the request as something editable, seeded from what was captured: URL, method, query parameters, headers, cookies, auth and body all split into their own fields.

Authentication offers none, bearer (a Token field) and apikey (a Name field for the header, for example x-api-key, and a Value field). Query parameters, headers and cookies are key/value tables that grow a blank row as you fill the last one. Cookies are recombined into one Cookie header on send. Network Conditions holds the same throttling and user agent pickers as the settings panel, and they are shared with the whole app, not just this request. Code Snippet is the request as a cURL command, kept in step with the fields.

Sandbox requests go out through the same patched fetch, so they appear in the log like any other request.