One of the interesting things about web development is the number of different layers involved. On a low-down technical level, there are bits clogging the tubes, higher up you have TCP/IP then HTTP. A little further up still and you have the HTML of the page and eventually, on the top, there's what it looks like when it arrives on the user's screen. A lot of debugging can be done at the source code level but there is a level between that and the way it looks - the Document Object Model (DOM). This is web page as it appears in the 'mind of the browser' and some of the most useful debugging tools allow you to look directly at it.

All the main browser platforms have tools either built-in or available as easy-to-install add-ons which allow you to play with the DOM, add elements to it, take them away, change behaviours or styles on-the-fly and generally feel like a brain surgeon sitting with an electrode in one hand and a nice, squishy brain in the other. Playing with your pages at this level is an extremely useful way to get a good feel for the structure of a page and how the browser 'thinks'.

Some of these DOM analysis tools allow access to another behind-the-scenes level of the process - network traffic. Every file - HTML, JavaScript, image, CSS, XML, etc - starts at the server at one end and finishes at the browser. Using a network analysis tool is like standing at the front door of a party watching everyone come in. You can see where they came from and what they looked like when they arrived so that if they look different later on, you can tell they've had a few too many trips to the punch bowl. Or something. I think the analogy went a bit wrong somewhere. You know what I mean.

There's a good in-depth but understandable article of how browsers actually work on the HTML5 Rocks site.