Debugging in the Browser
The page is broken. A button does nothing, the data won't load, a section is the wrong color - and you're
staring at the screen with no idea where to even look. Most people respond by scattering console.log
everywhere and refreshing, hoping a clue falls out. There's a calmer way: the browser already ships a full
debugging toolkit (the DevTools), and three of its panels answer almost every "why is this broken?" you'll
ever have.
This guide isn't a button tour of one browser. It teaches the four panels you actually use - Console, Sources, Network, Elements - as a way of thinking, so the moves carry over whether you're in Chrome, Edge, Firefox, or Safari.
How to read this
- New to DevTools? Read in order. Phase 1 gives you the map and the Console; Phase 2 teaches real breakpoints and the Network tab; Phase 3 walks a full investigation start to finish.
- Already comfortable in the Console? Skip to Phase 2 - that's where breakpoints beat scattered logging.
The phases
- The DevTools Map and the Console - the mental model: DevTools is a window into the running page. Open it, read errors, log and live-evaluate in the Console.
- Breakpoints and the Network Tab - pause your JavaScript with breakpoints (step over / into, watch expressions, the call stack) instead of scattering logs, and use the Network tab to find the request that failed.
- A Real Investigation - walk one "why is this broken?" bug end to end across Console, Network, Sources, and Elements, plus the gotchas that send people chasing ghosts.
Related reading: Reading a Stack Trace and What an Error Message Tells You - the Console throws both at you, and they're far less scary once you can read them.