← WebPeek

Support

Enabling WebPeek, and the questions it raises most.

Enabling WebPeek

WebPeek is a Safari extension, so the app itself is mostly a set of instructions — everything happens inside Safari. This takes about 20 seconds.

  1. Open Safari and go to any regular web page.
  2. Tap the page menu in the address bar — the icon at the left of the address bar on iOS 26, or the AA button on iOS 17 — and choose Manage Extensions.
  3. Turn on WebPeek.
  4. Open the page menu again, tap WebPeek, and choose Always Allow…Always Allow on Every Website.
  5. Reload the page. A small floating </> button appears near the right edge. Tap it to open the inspector.

Step 2 must come before Settings. The row “Settings → Apps → Safari → Extensions” does not exist until an extension has been enabled once from Safari itself. If you go looking there first, you will not find it.

Frequently asked

The floating button disappeared

Reinstalling or updating the app switches the extension off again. Open Safari's page menu → Manage Extensions and turn WebPeek back on. You can also hide the button on purpose in the panel's Settings — reopen it from Safari's WebPeek toolbar button.

Console input says it cannot run here

That page's Content-Security-Policy has no 'unsafe-eval', so the browser refuses to evaluate any expression — including ours. Log capture, network, elements and storage all keep working; only the input line is blocked.

Some cookies are missing

HttpOnly cookies are invisible to every page script by design, and iOS Safari extensions have no cookies API to go around it. What you see is exactly what the page itself can see.

Static files show up without headers or a body

iOS Safari has no webRequest API. WebPeek hooks fetch, XHR, WebSocket, sendBeacon and EventSource directly, so those carry full details. Everything else — images, stylesheets, the document — is recovered from Resource Timing, which only reports metadata.

A cross-origin response shows only a few headers

The browser exposes just the CORS-safelisted headers plus whatever the server lists in Access-Control-Expose-Headers. WebPeek shows everything it is allowed to see and says so.

Requests made by a Service Worker are missing

A Service Worker runs in its own worker context that page hooks cannot reach. Its cached responses are still browsable under Storage → Cache.

Nothing happens inside an app's built-in browser

Safari extensions only run in Safari. In-app browsers (WKWebView) do not load them, so open the link in Safari itself.

Matched styles look incomplete

Cross-origin stylesheets cannot be read from a page context, and WebPeek does not resolve cascade order. It lists every rule whose selector matches, marks unreadable sheets, and leaves the final say to the computed values.

Editing the DOM did not stick

Edits apply to the live page only, exactly like a desktop inspector. Reloading throws them away, and a page that re-renders may overwrite them immediately. Deleting a node can be undone from the banner that appears right after.

Can I move the panel?

Yes. Settings → Panel position offers Auto, Bottom and Side. Auto uses a side column only on a wide, landscape screen and the bottom sheet otherwise. You can also set a different position for one specific site, and drag the side column's left edge to resize it.

Still stuck?

Email support@zihuahuang.com and include your iOS version and the site you were on, if you can share it.