The browser devtools as an x-ray

Free instruments, already installed

Every browser ships a set of professional debugging tools. F12, or Ctrl+Shift+I, or Cmd+Option+I. Five panels matter.

Elements: what is actually on the page

The HTML as it exists right now, after JavaScript has finished with it, which is often not what is in your source file. Click any element and the right pane shows every CSS rule affecting it, with overridden ones struck through, and which file each came from.

The practical use: something is the wrong size and you cannot find why. Select it, read the computed styles, and the rule responsible is named with its source. This answers layout questions in seconds that would otherwise be twenty minutes of guessing.

You can also edit values live. Change a padding, see the result, then go and make the change in the real file. Nothing you type here is saved, which is exactly what makes it safe to experiment in.

Console: the errors nobody saw

Red lines here are JavaScript errors that already happened. A great many broken generated apps have an error sitting in the console that nobody looked at, because the page still rendered something.

Make this your first move whenever anything is odd. Reload with the console open, and read from the top: the first error usually causes the ones below it.

You can also run code here against the live page. Typing document.cookie or the name of a global variable and reading what comes back settles arguments about what state actually exists.

Network: what crossed the road

Every request, with method, status, size and timing. This panel answers questions no amount of code reading will.

• Did the request happen at all? A button that does nothing is usually a button that sends nothing.
• What did we send? The Payload or Request tab shows the exact body. Wrong field names show up instantly here.
• What came back? The Response tab shows the raw answer, before any of your display code touched it. When the screen shows nothing and the response contains the data, the bug is in rendering, not in fetching.
• What is the status code? 401 means not authenticated. 403, not allowed. 404, no such route, often a typo in the path. 500, your server crashed and the details are in your server logs, not here.
• How big and how slow? Sort by size. The 3 MB image somebody pasted in unresized will be at the top.

Tick Preserve log before testing anything that redirects, or the evidence disappears when the page changes.

Application: where data is stored on the device

Cookies, local storage, session storage. Two things to check here.

Is a session cookie marked HttpOnly and Secure? HttpOnly means JavaScript cannot read it, which is what stops a script on your page from stealing a login. A session token in local storage instead of an HttpOnly cookie is readable by any script that runs on your page.

And is anything sensitive being kept here? Generated apps sometimes cache a user object, including an email or a phone number, in local storage where it persists after logout on a shared computer.

Throttling: becoming a realistic user

In the Network panel, the speed dropdown offers Slow 4G and Offline. In Performance, a CPU slowdown multiplier.

Set Slow 4G and 4x CPU slowdown, then use your app. This is roughly a mid-range Android phone on a normal connection, which is what most of your users have. Every missing loading state, every layout that jumps as content arrives, and every double-submit becomes visible immediately.

Do this once before you show anybody your app. It takes two minutes and it is the closest thing to testing on real hardware you can get without owning it.

On a phone

Android Chrome connects to desktop devtools over USB via chrome://inspect. iPhone Safari connects to desktop Safari’s Develop menu. Both are free, both take five minutes to set up, and both are the only way to debug something that happens only on a real device.