To inspect element on an Android device, connect the phone to a computer by USB, enable USB debugging in Developer options, then open chrome://inspect#devices in desktop Chrome and click inspect next to the tab you want. This opens the full Chrome DevTools for the page running on the phone, including live HTML and CSS editing.
Three other routes work when USB isn't an option:
All four are covered below, followed by a troubleshooting section for the most common failure: your device not appearing in chrome://inspect.
Inspect Element lets you read and change a page's HTML, CSS and JavaScript while it runs, which makes it the quickest way to understand how a webpage is actually built. It's usually associated with desktop browsers, but everything it does is available on Android, whether you're debugging a layout that only breaks on a phone, restyling a page temporarily to test an idea, or learning web development by taking sites apart.
Mobile is where a lot of these problems live. A page that behaves perfectly in a resized desktop window can still break on a real handset, because a phone brings its own browser engine version, touch behaviour, system fonts, and network conditions. Inspecting on the device itself is the only way to see what's genuinely happening rather than an approximation of it.
Inspect Element is a browser feature that shows a page's live HTML, CSS and JavaScript and lets you edit them in real time. Changes take effect instantly in your browser and disappear on reload, nothing is sent to the server and no other visitor sees them.
It gives you access to three layers of the page:
These are frequently confused and they show different things. View source returns the HTML the server originally sent. Inspect Element shows the DOM, the page as it exists right now, after JavaScript has added, removed and rearranged things.
On a modern site built with a framework, the two barely resemble each other: view source may return a near-empty shell while the inspector shows a complete page. This distinction matters when you pick a method below, because several tools that advertise element inspection on Android only ever show you the served source.
Desktop DevTools includes a device toolbar that resizes the viewport and spoofs a mobile user agent. That's useful for layout work, but it runs your desktop browser engine with desktop fonts and a mouse. A real handset differs in ways emulation cannot reproduce, which is why some bugs only ever appear on the device.
| Question you're answering | Use |
|---|---|
| Does this layout hold at a narrow width? | Desktop device toolbar — faster to iterate |
| Why does this break only on phones? | Real device, inspected remotely |
| Does it work across the handsets my users own? | Real devices at scale — emulation can't answer this |
This is the primary method and the only one that gives you the complete DevTools feature set. It requires a computer and, for the USB route, a data-capable cable. Under the hood it uses the Android Debug Bridge (ADB), but Chrome handles that for you — you don't need to install ADB or run any commands.
Menu paths vary by manufacturer. On Samsung devices, Build number sits under Settings → About phone → Software information. [VERIFY on a current handset — these paths move between Android releases and OEM skins.]
A DevTools window opens, mirroring the phone screen. Everything works as it does on desktop: the Elements panel for the live DOM, editable CSS, the Console, Network, Performance, and JavaScript breakpoints. Changes appear on the phone instantly and are discarded on reload.
Chrome also lists WebView contexts from installed apps, but only where the app was built with setWebContentsDebuggingEnabled(true). Release builds of third-party apps generally won't appear.
Android 11 introduced wireless debugging, which pairs the phone to your computer over the local network. Both devices must be on the same network. This method does require the ADB command-line tool, available in the Android SDK Platform Tools.
The pairing survives until you disable wireless debugging or the phone leaves the network. Ports change on reconnection, so expect to repeat step 4 rather than step 2.
Chrome for Android has no built-in developer tools, and neither does Firefox for Android. To inspect a page using only the phone, you inject a console into the page itself. Eruda and vConsole are the two established libraries for this.
You load one via a bookmarklet:
javascript:(function()%7Bvar%20s%3Ddocument.createElement('script')%3Bs.src%3D'https%3A%2F%2Fcdn.jsdelivr.net%2Fnpm%2Feruda'%3Bdocument.body.append(s)%3Bs.onload%3Dfunction()%7Beruda.init()%7D%7D)()%3B
What this gives you and what it doesn't. You get a genuine view of the live DOM with editable styles, on the device, with no computer involved. You don't get breakpoint debugging, performance profiling, or anything requiring the browser's own internals. For checking why a layout breaks on a specific handset, it's enough.
Two things worth knowing: sites with a strict Content-Security-Policy will block the injected script, and this only works on pages you load in a browser, not inside native apps.
Play Store apps such as VT View Source fetch a URL and display its returned source. That is view source, not inspect element — you see the HTML the server sent, not the live DOM after JavaScript has run. For a modern single-page application the two barely resemble each other. They're fine for a quick look at markup or metadata, and useless for debugging rendered behaviour.
Kiwi Browser, which used to be the standard recommendation here because it exposed Chromium DevTools on-device, was discontinued and its repository archived. [VERIFY current status before referencing it either way.]
Firefox for Android has no on-device inspector. It supports remote debugging from desktop Firefox instead:
You get the Firefox DevTools — Inspector, Console, Debugger, Network — against the page on the phone. Useful specifically when you're chasing a Gecko-only rendering difference; otherwise Chrome's route is less fiddly.
Work through these in order. The first three account for the large majority of cases.
Standard guides assume stock Android. Most of the world isn't running stock Android, and several manufacturer skins add requirements that aren't documented anywhere obvious. [VERIFY every row on a current handset before publishing.]
| Manufacturer / skin | Extra step required | Notes |
|---|---|---|
| Xiaomi — MIUI / HyperOS | Enable USB debugging (Security settings) in addition to standard USB debugging | The toggle stays greyed out until you sign in to a Mi account; many builds also require an inserted SIM card |
| Oppo / Realme — ColorOS | Unlock Developer options via Settings → About device → Version, then enable USB debugging and Install via USB | Build number sits under Version, not directly under About device |
| Vivo — Funtouch OS / OriginOS | Unlock via Settings → About phone → Software version, then enable USB debugging | Some builds add a second USB debugging (Security settings) toggle requiring a signed-in vivo account |
| Huawei / Honor — EMUI / MagicOS | Developer options sit under Settings → System & updates → Developer options; enable USB debugging and ADB debugging in charging mode | Devices shipping HarmonyOS NEXT may not expose standard ADB at all |
| Samsung — One UI | Turn off Auto Blocker, or its Block USB commands option, under Settings → Security and privacy → Auto Blocker | Auto Blocker is enabled by default on recent One UI versions and blocks ADB with no error message. Build number is under About phone → Software information |
Related: Android device testing and mobile testing challenges.
| Situation | Use |
|---|---|
| Full debugging, computer available | Chrome DevTools over USB |
| Computer available, no usable cable | Wireless debugging (Android 11+) |
| Phone only, no computer | Eruda or vConsole bookmarklet |
| Gecko-specific rendering issue | Firefox about:debugging |
| Just need to read the served HTML | View-source app or view-source: URL |
Yes, by injecting a console library such as Eruda or vConsole into the page with a bookmarklet. You get a live DOM view and editable styles on the device. You don't get breakpoint debugging or performance profiling, which require desktop DevTools.
No. Chrome for Android ships no on-device DevTools. Inspecting a page in it requires either remote debugging from a desktop or an injected console.
The concept is the same but the tooling differs. On iOS you enable Web Inspector in Safari's advanced settings on the phone, then connect to a Mac and use Safari's Develop menu. Chrome's chrome://inspect does not work with iOS devices.
No. Edits live only in the browser's current session and vanish on reload. Nothing reaches the server or affects other visitors.
WebView contexts are only inspectable when the app enabled it at build time via setWebContentsDebuggingEnabled(true). Release builds normally leave it off.
No. All four methods work on unmodified retail devices.
Remote debugging tells you what's happening on the handset in your hand. It doesn't tell you which of the thousands of Android device-and-OS combinations in your market break your page, and as the OEM table above shows, the manufacturers most likely to cause problems are often the ones missing from a local device lab.
Global App Testing is a crowdtesting platform that runs Android testing on real devices through a tester network spanning more than 190 countries and territories, on real consumer handsets and real mobile networks rather than emulators in a data centre.
Talk to us about Android device coverage.
Android Device Testing — Everything You Need To Know
Android mobile app testing checklist
10 QA mobile testing types you need to know about
Types of web application testing