Browser DevTools Tour

Modern web development happens in two environments: your editor (VS Code) and your browser (Chrome, the modern industry default). This guide is a tour of the browser’s developer tools — affectionately called DevTools — which let you inspect any web page running anywhere, including the apps you’re about to build.

By the end of this guide (about an hour, including hands-on practice) you’ll be able to: inspect any element on any page, read network traffic to and from a server, run JavaScript in real time, debug paused JavaScript line by line, and see where the browser is storing your cookies and other data. These are the skills that turn “the page is broken, what do I do” panic into “let me see what’s happening” diagnosis.

We use Google Chrome as the cohort default because it has the most polished DevTools, but Firefox and Safari have nearly identical equivalents.

1. Opening DevTools

On any web page, three ways to open them:

• Cmd + Option + I (the keyboard shortcut you’ll memorize)
• Right-click anywhere on the page → “Inspect”
• View menu → Developer → Developer Tools

A panel opens — usually docked to the bottom or right of your browser window. The top of that panel has a row of tabs:

Elements  Console  Sources  Network  Performance  Memory  Application  ...

We’ll cover the five you’ll use most: Elements, Console, Network, Application, Sources.

You can dock the DevTools panel on the right (more horizontal screen space for tall pages) or pop it out into a separate window (the three-dots menu at the top right of DevTools → “Dock side”).

2. The Elements panel — inspect anything you can see

Open DevTools on any web page (try human-angle.com once it’s live, or any site for now). The Elements panel shows the page’s HTML tree, with the matching CSS in the Styles pane on the right.

Try this:

1. Right-click any visible element on the page → “Inspect.”
2. The Elements panel jumps to that element in the tree and highlights the matching code.
3. Hover over any line in the HTML tree — the matching part of the page lights up.
4. Click any HTML element to select it. The Styles pane on the right shows every CSS rule applied to it.

Live editing:

5. Double-click any text in the HTML — type something else. The page updates immediately. (This is just for your local view; refresh the page to revert.)
6. In the Styles pane, click any property value to edit it. Try changing color: red to color: hotpink. The page updates as you type.
7. Click any unchecked checkbox next to a CSS property to disable that rule. Useful for debugging “what’s making this look weird.”

Why this matters: when something on a page looks wrong — wrong color, wrong size, missing — the Elements panel tells you exactly which CSS rule is responsible. You can experiment with fixes live before going back to your code to make them permanent.

3. The Console — JavaScript on demand

The Console is a live JavaScript REPL. Anything you can write in JavaScript, you can run here against the current page.

Try this in the Console of any page:

// Just type any JavaScript and press Enter:
1 + 1                           // 2
"hello".toUpperCase()           // "HELLO"
document.title                  // The current page's title
window.location.href            // The current URL

// Modify the page in real time:
document.body.style.background = "lightyellow"

// Inspect any element:
document.querySelectorAll("a").length  // count the links

// Try the JavaScript features from the modern-JS tutorial:
[1, 2, 3, 4, 5].filter(n => n % 2 === 0)

Where Console messages come from:

• Anything you type
• Any console.log("…") your code calls
• Errors thrown by code on the page (red)
• Warnings (yellow)

Tips:

• Pressing up arrow walks back through your previous console commands (just like the terminal).
• Console output that looks like an object — {a: 1, b: 2} — is clickable. Click it to expand and explore.
• The 🚫 button at the top-left clears the Console.
• The “Preserve log” checkbox keeps Console history across page reloads.

Why this matters: when your React app misbehaves, your first three steps will be: open the Console, look for red errors, look at any console.log output you’ve added. Most bugs in React apps reveal themselves here within seconds.

4. The Network panel — see every request

Web apps are conversations between your browser (the client) and one or more servers. The Network panel shows every conversation.

Try this:

1. Open DevTools → Network panel.
2. Click “Disable cache” (so you see fresh requests).
3. Reload the page.
4. Watch dozens of rows appear — each is one request.

Each row shows:

• Name — the URL or filename
• Status — HTTP status code (200 = OK, 404 = not found, 500 = server error)
• Type — what kind of resource (document, fetch, script, image, stylesheet, etc.)
• Size — how big it was
• Time — how long it took

Click any row to see the full request and response details:

• Headers tab — what the browser sent and what the server returned (URLs, methods, status codes, all the metadata)
• Payload — what data went in the request body (for POST/PUT)
• Response — what the server sent back (often JSON for APIs)
• Preview — pretty-printed version of the response

Filter buttons at the top: Fetch/XHR is what you’ll click most often. It hides everything except API calls. When you’re debugging “why isn’t the data showing up?”, look here first.

Try this on a real app:

1. Visit any site that loads data (e.g., a search engine).
2. Open DevTools → Network → Fetch/XHR filter.
3. Type a search query. Watch the API call happen in real time.
4. Click the request, look at the Payload (what your input sent) and the Response (what came back).

Why this matters: when “the data didn’t load,” it’s almost always one of: (a) the request was never made, (b) the request was made but got an error status, (c) the request succeeded but the response shape isn’t what your code expected. The Network panel tells you which, in seconds.

5. The Application panel — where state lives

The Application panel shows where the browser is storing things on behalf of the page: cookies, localStorage, sessionStorage, IndexedDB, service workers.

You’ll mostly look at three things:

Cookies — small key-value pairs the server set in your browser. Auth sessions usually live here.

localStorage — bigger key-value storage that persists across tabs and reloads. Some apps store user preferences here.

sessionStorage — same as localStorage but cleared when the tab closes.

Try this:

1. Open the Application panel on any logged-in site.
2. Expand “Cookies” in the left sidebar → click the site’s domain.
3. See every cookie the site has set on your browser.

You can edit, delete, and add cookies right here. Useful for testing “what happens if I log out” or “what happens with a missing session token.”

Why this matters: auth, session persistence, and user preferences all live somewhere in browser storage. When auth misbehaves, this is the first place to look.

6. The Sources panel — the JavaScript debugger

This is the most powerful thing in DevTools and the one most beginners avoid because it looks complicated. It’s worth twenty minutes of attention.

Sources lets you set breakpoints in any JavaScript running on the page, then step through the code line by line — inspecting every variable’s value at every step.

Try this:

1. Open DevTools → Sources panel.
2. In the file tree on the left, find any .js file the page is running.
3. Click any line of code in the editor pane to set a breakpoint (a blue line marker appears).
4. Reload the page or trigger whatever action runs that code.
5. The page pauses when execution hits your breakpoint. The current line is highlighted yellow.
6. The right pane shows every variable currently in scope, with its value.
7. The toolbar at the top has step buttons:
   • ▶️ Resume — keep running until the next breakpoint
   • ⤵️ Step over — run the current line and pause on the next
   • ⤴️ Step into — if the current line calls a function, dive into it
   • ⤴️ Step out — finish the current function and pause when it returns

While paused, you can type into the Console and inspect anything: print variables, evaluate expressions, even call functions. The Console always operates in the current paused scope, so all your variables are reachable.

Why this matters: the debugger replaces dozens of console.log statements with a single workflow: pause at the moment of interest, look at everything. Once you adopt it, your debugging speed roughly doubles.

VS Code has the same debugger built in (we covered it in the VS Code Essentials guide) — you’ll use one or the other depending on whether your code is server-side (VS Code) or browser-side (DevTools).

7. Other panels you’ll meet later

• Performance — record a few seconds of activity and see where time was spent. Used Week 8 when we run Lighthouse and tune Web Vitals.
• Memory — find memory leaks. You won’t need this in this program but it exists.
• Lighthouse — built-in audit for performance, accessibility, SEO, best practices. Run it in Week 8.
• Recorder — capture and replay user interactions. Useful for E2E testing setup.

8. The mobile-device emulator

Your capstone web app should look reasonable on a phone (judges scan from Demo Day audience seats). To preview how it looks and behaves on a phone-sized screen:

1. Open DevTools.
2. Click the device-toggle icon (📱) at the top-left of the DevTools panel — or Cmd + Shift + M.
3. Pick a device from the dropdown (“iPhone 14 Pro” / “Pixel 8” / etc.).
4. The page reflows to that screen size.

This is how you’ll check responsive design in seconds without picking up your phone. You can rotate, change device, simulate slow networks, and even simulate “no internet.”

9. Hands-on: the practice sequence

Visit any site you like — your favorite news site, search engine, or a Wikipedia page.

1. Inspect — Right-click any element on the page → “Inspect.” Read the HTML and the matching CSS.
2. Console — Open the Console. Type document.title. Press Enter. Type window.location.href. Press Enter.
3. Edit live — In Elements, double-click any visible text and change it. Refresh the page to revert.
4. Network — Open the Network panel. Filter to Fetch/XHR. Reload the page. Click any request and look at the Headers and Response tabs.
5. Mobile preview — Toggle device emulation (📱 icon). Pick “iPhone 14 Pro.” Notice how the layout changes. Switch back.
6. Cookies — Open Application → Cookies. See what the site stored on your browser.

Take a screenshot of any one of those panels in use and post it in #wins on Discord with “Module 0.9 complete.”

10. The cheat sheet

11. Going deeper — official docs and a video walkthrough

If you prefer a video alongside this written guide, the freeCodeCamp Chrome DevTools Crash Course (1 hour) covers the same surface area — handy if you’d rather watch someone click through the panels live before doing it yourself.

When you want to dig deeper on any specific panel, Google’s official Chrome DevTools documentation is the canonical reference. Each panel has its own “Get started” guide with step-by-step exercises — far more detail than this tour, but well-organized when you have a specific question (“how do I set a conditional breakpoint?”, “how do I throttle the network?”).

You don’t need either of these to complete Module 0.9 — this handout plus the hands-on practice is enough. They’re for the curious and for future reference.

What’s next

You’ve now seen all five environments where Day 1 of the program will happen: terminal, VS Code, browser, Discord, and GitHub. The remaining Get Started modules are the mandatory reading materials (JS reference, TypeScript reference, HTML/CSS course) and a tiny coding exercise — the Day-1 Readiness Check — that proves you can put the pieces together.

When you’ve completed all the Get Started modules and posted in #wins, you’re ready for Saturday June 13. See you there.