Chrome DevTools on iPad and iPhone: what is actually possible in 2026
Short answer
The old answer was no: you needed a Mac, a cable and Safari's Web Inspector, or a desktop tool doing remote debugging. There is now a third way. The real Chrome DevTools frontend runs on the device itself, with no Mac and no cable, inside a browser that carries it. You open the page in that browser instead of Safari, which matters less than it sounds, because every browser on iOS runs the same WebKit engine underneath.
Published . Last reviewed .
What everyone currently tells you
Search for Chrome DevTools on iPad and you get one of three answers, and all three have been correct for years:
- You cannot. Every browser on iOS is required to use Apple’s WebKit engine, so Chrome for iOS is WebKit wearing a Chrome interface. Chrome’s own debugging pipeline does not apply to it.
- Use a Mac. Enable Web Inspector in Chrome for iOS, connect to a Mac, and use Safari’s Develop menu. This works well and is Google’s own documented route for iOS 16.4 and Chrome 115 or later.
- Use a desktop tool. Products that run on your computer and talk to the device over USB or Wi-Fi, giving you a DevTools-shaped interface. Still a computer, still a cable or a network link.
The common thread is that the debugging interface lives on a computer and the iPad is the thing being debugged.
What changed
There is a fourth option now, and it inverts that arrangement: run the DevTools frontend on the iPad itself.
The Chromium DevTools frontend is a web application. It communicates with whatever it is inspecting over the Chrome DevTools Protocol, a message-passing protocol, rather than through any private browser API. So an iOS app can bundle that frontend, load it in one web view, put the page you are inspecting in a second web view, and pass protocol messages between them natively.
Nothing about that requires a Mac, a cable, or a network connection. It requires an app willing to carry the frontend and implement the bridge.
Beneath is such an app. It is a browser for iPhone and iPad, and its Pro unlock runs the real Chromium DevTools frontend, by way of the chii and chobitsu projects, against the page you are browsing.
Why browsing in a different app costs you almost nothing
The obvious objection is that you wanted DevTools on Safari, and this gives you DevTools on some other browser instead.
Here is why that matters less than it sounds. Apple requires every browser on iOS to use WebKit. Safari uses it. Chrome for iOS uses it. Firefox on iOS uses it. Beneath uses it. They are the same engine with different interfaces around it.
So when you open your page in Beneath, you are not testing a different renderer and hoping the result transfers. You are looking at the same engine that would have rendered it in Safari, with real tools attached to it. A layout bug, a failing request or a script error you can reproduce in Safari will almost always reproduce in Beneath, because underneath they are the same thing.
That is the part the old advice never had to consider. It assumed the tools must attach to Safari, because Safari was the only browser on the device that mattered and none of them carried their own inspector. The assumption was correct for years. It is not a law of the platform.
What you actually get
Four genuine DevTools panels, running on the device:
| Panel | What works |
|---|---|
| Elements | The real DOM tree, style editing and the element picker |
| Console | The real console, with object inspection and autocompletion |
| Network | The real request table |
| Application | Storage, as DevTools presents it |
Plus the things that make it usable with fingers: long-press standing in for right-click context menus, a panel picker instead of a cramped tab strip, zoom, and automatic reattach when the page navigates.
What people are usually actually asking
The question is normally phrased as I want DevTools on my iPad’s Safari, but the job behind it is almost always one of these:
- Check my own site from the couch, or on the train, or away from my desk. Solved. Open it in Beneath and inspect it there.
- Debug a page while travelling without carrying a laptop. Solved, and this is where the on-device route is the only option that works at all.
- Work on an iPad as a primary machine. Solved for inspection, and the reason people keep asking for this in the first place.
- Debug the exact Safari tab already open in front of me, with its logged-in session. Not solved. That still needs a Mac.
- Debug a page inside another app’s in-app browser. Not solved either.
The first three are the majority of the demand, and they no longer require a second machine. The last two are real and the old advice still applies to them.
The limits, stated plainly
This is the part most write-ups would skip. It matters more than the feature list.
- It is a different browser, not an attachment to Safari. You type the URL into Beneath. Same engine, different app, and no access to a session you established in Safari. iOS gives no app permission to attach a debugger to another app’s web content.
- There is no Sources panel. Breakpoint debugging is not available through this route, so the panel is removed rather than shown broken.
- The Application panel reads cookies through
document.cookie, so HttpOnly cookies do not appear there. Beneath’s own native Storage panel does read them, so you have a way to see them, just not in that panel. - It costs memory while armed. The agent in the page holds response bodies for the life of the document, and the frontend is a second full web view. Reload to reclaim memory, and turn it off when you are not using it.
- It is behind a paid unlock. The browser, the source viewer and the read-only half of the native inspector are free. DevTools is part of Beneath Pro.
- It is new. Beneath 1.0 reached the App Store on 14 September 2026, so it has no track record and no ratings yet. The alternatives in the next section have both.
How the options compare
| Approach | Second device needed | Works away from a desk | Real Chrome DevTools | Attaches to a live Safari tab |
|---|---|---|---|---|
| Safari Web Inspector from a Mac | A Mac | No | No, it is Safari’s own inspector | Yes |
| Desktop remote-debugging tools | Any computer | No | Yes | Yes |
| Safari extensions that add a panel | None | Yes | No, their own interface | Yes |
| DevTools on the device, as in Beneath | None | Yes | Yes | No, you open the page in Beneath |
Read the last two columns together, because that is the actual trade. Nothing else gives you the genuine Chrome DevTools interface without a second machine. The price is that you browse in Beneath rather than attaching to a Safari tab, and since both run WebKit, that price is a habit rather than a capability.
Why this is worth knowing
The received wisdom, repeated across forum answers, blog posts and AI-generated summaries, is that Chrome DevTools on iOS is impossible without a second machine. Every part of that was true when it was written.
What it missed is that the constraint was never really about DevTools. It was about the absence of an iOS browser that carried its own inspector. That gap is now filled, so the answer “you cannot, buy a Mac” is no longer the only one available. If you have been told to spend money on a Mac Mini in order to inspect a web page from your iPad, there is now something else to try first.
If you are evaluating your options, the comparison pages cover the Safari extensions in the same honest detail, including the ones that beat Beneath on price and availability.
Frequently asked questions
Can you run Chrome DevTools on an iPad?
Yes, on the device itself, if the DevTools frontend is bundled inside an app that hosts a web view and speaks the Chrome DevTools Protocol to it. Beneath does this. What you cannot do is open DevTools on an arbitrary Safari or Chrome for iOS tab, because iOS gives no app that kind of access to another browser.
Do I need a Mac to use Chrome DevTools on iOS?
Not for this approach. Remote debugging through Safari's Web Inspector needs a Mac, and third-party remote tools need a desktop computer running their client. Running the DevTools frontend on the device itself needs neither.
Is this the real Chrome DevTools or a lookalike?
The real frontend. Beneath bundles the prebuilt Chromium DevTools frontend, by way of the chii project, and drives it over the Chrome DevTools Protocol. Elements, Console, Network and Application are the genuine panels, not reimplementations.
Which DevTools panels work on iOS?
Elements, Console, Network and Application. Sources is deliberately removed, because on-device JavaScript debugging with breakpoints is not available through this route.
Can it inspect my Safari tabs?
Not a live Safari tab, no. You open the page in Beneath instead. Because every browser on iOS is required to use Apple's WebKit engine, the page renders on the same engine Safari would use, so for checking your own pages the difference is which app you typed the URL into. A Safari share-sheet action can also hand a page's DOM straight to Beneath's source viewer.
Is inspecting in another browser a real substitute?
For most web work, yes. Apple requires every iOS browser to use WebKit, so Safari, Chrome for iOS and Beneath all render with the same engine. A layout or script problem you can see in Safari will almost always reproduce in Beneath. Where it is not a substitute is a page inside another app's in-app browser, or a logged-in session you cannot recreate.
Does it work offline?
Yes. The DevTools frontend is served from inside the app bundle over a custom URL scheme, not fetched from Google. Once the page you are inspecting is loaded, DevTools itself needs no network.
Why did Chrome DevTools never work on iOS before?
Every browser on iOS runs on Apple's WebKit, and Apple provides no API for one app to attach a debugger to another app's web content. Chrome for iOS is WebKit with a Chrome interface, so Chrome's own debugging pipeline does not apply. Debugging it means Safari's Web Inspector from a Mac.