Debug the remote browser as if it were on your desk
Open the console, network and elements on a Chrome or Edge browser running on our machine — right next to it, in the same tab. See why a page breaks, not just that it broke.
Chrome and Edge embedded · Firefox in-session
> checkout.js:212 submitPayment()
Refused to load pay.js — blocked by tracking prevention
403 POST /api/pay · declined
>
“Checkout fails on Edge” is not a bug report
On a browser you don't own, the error is gone the moment the session closes. Open real DevTools on that browser and the report changes from “it broke” to why it broke: “the payment script was blocked — here is the error.”
- NameStatus
- GET/billing/plans200
- GET/user/preferences200
- POST/billing/subscribe403
- POST/analytics/pageview204
{
"error": "insufficient_scope",
"need": ["billing:write"],
"have": ["billing:read"],
"doc": "/err/scope-403"
}The real browser tools, not a cut-down version
Console
See errors, warnings and logs as they happen, and run commands against the page.
Network
Every request with its status, timing and headers. Sort by failures to find the one that returned 403.
Elements
The live page and its styles. Change a style and the remote page updates on screen.
Sources
The scripts the page loaded, with breakpoints — for bugs that only show up on a build you can't run locally.
The real browser, not a copy
The tools connect to the live browser, so you see what's happening now — not a snapshot from when the session started.
Right beside the session
The browser stays on screen while you debug, so you don't switch windows.
Live, not a picture of a panel
Change a style and the remote page updates. Open a request and it is the real one that was sent. The console is the page's own — because the tools connect straight to the browser, on the machine where the bug happens.
- <main>
- <ul.cart>
- <li.cart-item>
- <li.cart-item>
- </ul>
- </main>
.cart-item {
display: flex;
padding: 24px;was 12px
border-radius: 8px;
}
Reflowed live
Where you get it
Chrome and Edge — in your tab
The full tools open right in your tab, next to the browser — on both macOS and Windows.
Firefox — its own tools, in the session
You get Firefox's full developer tools, opened inside the session on the remote machine instead of in your tab.
Frequently asked questions
Yes. Chrome and Edge sessions carry an embedded DevTools panel attached to the remote browser over its own debugging protocol, with elements, console, network and sources. It renders beside the session in the same tab, so you can reproduce and inspect without switching windows.
Yes, but differently. Firefox opens its own developer tools inside the session rather than docking into your tab, because it exposes no remote debugging channel for the panel to attach to on Windows. You get the same toolset; it just runs on the remote machine.
No. Safari's automation protocol exposes neither console output nor network data, on macOS or iOS, and developer tools are not offered for Safari sessions. The practical approach is to confirm the behaviour in a Safari session and then switch the same session to Chrome to investigate the cause.
Real, and attached live. It speaks the browser's own debugging protocol, so editing a style changes the remote page, expanding a request shows what was actually sent, and the console is the page's own console rather than a log copied out of it.
No — this is for browsers. For an installed Android or iOS app, the app inspector reads the native view hierarchy instead, giving you element attributes and copyable locators. A web page inside an app's WebView is its own case and is not covered by either tool.
No — the panel's own state is not saved when the session closes, so it is a debugging tool rather than a recorder. To keep the evidence, screenshot the error or export a network log before you close — both attach to a bug filed from the session.
No. The panel is part of the session in your browser. There is no extension, no local proxy and no debugging build of the site required.
Chrome and Edge get the full embedded DevTools panel — elements, console, network and sources — docked right in your tab on both macOS and Windows. Firefox opens its own developer tools inside the remote session instead. Safari has no developer tools here, because the automation it supports exposes no console or network data on any platform.
Open a session and inspect something
Pick Chrome or Edge, load the page that misbehaves, and read the console on the machine where it breaks.