Browser DevTools and evidence-based debugging

Why this matters

Yesterday you started a server and watched a browser talk to it. Today you see inside that conversation. DevTools turns the browser from a black box into an instrument: the page's live structure, the errors it is already reporting, and every request it makes with the status that came back. This is the day guessing stops. From here on, "it's broken" is not a report — the URL, the method, and the status code are.

The DOM: what the page really is

The server sends the browser HTML, a text file describing the page. The browser parses it and builds a live in-memory tree of objects called the DOM (Document Object Model). Every heading, paragraph, and button is a node in that tree.

The crucial point: the DOM is what is on screen now; the HTML file is only what arrived. Once JavaScript adds and changes nodes, the two drift apart. View Source shows the file; DevTools shows the DOM. When they disagree, the DOM is the truth.

Opening DevTools, and the four panels

F12 opens DevTools in any major browser; on macOS Chrome, Cmd+Option+I. Right-click anything and choose Inspect to jump straight to that element. (Firefox names the first panel Inspector; Safari needs the Develop menu enabled in Settings → Advanced.)

Four panels carry today's work:

• Elements — the live DOM tree, plus a Styles pane showing every CSS rule matching the selected node.
• Console — messages the page printed and every error it hit. You can also type JavaScript here and run it against the live page.
• Sources — the files the browser downloaded, where you can pause execution on a line.
• Network — every request the page made, with method, status, size, and timing.

Today's work lives in Elements, Console, and Network. Week 4 uses Sources properly.

Console errors are the cheapest evidence you will ever get

An error in the Console is not noise; it is a precise report the browser wrote for you, free, before you asked. Beginners scroll past them. A real one:

Uncaught TypeError: Cannot read properties of null (reading 'value')

Three facts in one line. TypeError — you used a value in a way its type does not allow. null — the thing you reached into was empty, usually because an element you looked for was not found. 'value' — the property you tried to read. The right of the row shows the file and line number. That is the whole diagnosis before you have changed a character.

Uncaught means nothing in the code handled it, so the browser abandoned that work. A page can look "half loaded" for exactly this reason.

Network: methods and status codes

Every request in the Network panel has a method and comes back with a status code.

The method is the verb — what the client wants done. GET fetches, POST sends new data, PUT and PATCH update, DELETE removes. Loading a page is a GET.

The status code is a three-digit number the server sends back, and its first digit is the whole summary:

Range	Meaning	Examples
2xx	Success	200 OK, 201 Created
3xx	Redirect — look elsewhere	301 Moved Permanently
4xx	Your request was wrong	400 Bad Request, 404 Not Found
5xx	The server failed	500 Internal Server Error, 502 Bad Gateway

That 4xx/5xx split decides where you go looking. A 404 means the client asked for something not there — check the URL. A 500 means the server crashed handling a request it accepted — check the server logs. Blaming the wrong side wastes hours.

Walkthrough: inspect a real page

Open https://example.com — a tiny real page — and press F12.

1. Inspect an element. Right-click the heading "Example Domain" and choose Inspect. The Elements panel highlights the matching node:

<h1>Example Domain</h1>

Double-click the text, type Probed live, and press Enter. The page updates instantly — you changed the DOM in your own browser's memory, not the server, not anyone else's view.

2. Change a style locally. With the <h1> still selected, find the Styles pane. In the element.style { } block, click inside the braces, type color: red, press Enter. The heading turns red.

3. Read the Console. Switch to the Console tab and type:

document.title

'Example Domain'

Now deliberately break something:

document.querySelector("#nope").value

Uncaught TypeError: Cannot read properties of null (reading 'value')

No element has id nope, so querySelector returned null, and reading .value off null is the type error. You produced and diagnosed a real error on purpose.

4. Watch the network. Open the Network tab, then reload with Cmd+R / Ctrl+R — the panel records only while open. A row appears for the document. Click it and read the Headers tab:

Request URL:     https://example.com/
Request Method:  GET
Status Code:     200 OK

5. See a failure. With Network still open, go to https://example.com/does-not-exist. The document row now shows status 404: the server answered, it just had nothing at that path.

Using AI today: reviewer mode

Today's mode is reviewer — you bring work you already did and ask the AI to attack it. A useful review produces specific, actionable findings backed by evidence: concrete defects, risks, missing checks, unverified assumptions. General praise is worthless, and a full rewrite is worse — it replaces the thing you were trying to understand.

Your turn

1. Pick a public page you use — a news site, a shop, a docs page.
2. Inspect one element and record its tag and text.
3. Change one style on it in the Styles pane; note exactly what you changed.
4. Reload and confirm the change is gone. That is the proof it was local.
5. Open the Network tab, reload, and pick one request. Record its URL, method, and status code from the Headers tab.
6. Record any Console error already present. If it is clean, create one with the document.querySelector("#nope").value trick and record that.
7. Write devtools-notes.md with the request URL, method, status, what you changed locally, and one sentence on what the status code told you about who is responsible.

Common pitfalls

• Opening Network after the page loaded. It records only while open. Open it, then reload.
• Expecting DevTools edits to persist. They vanish on reload. To keep a change, edit the source file.
• Reading HTML source and calling it the page. After JavaScript runs, only the DOM is accurate.
• Treating every red line as fatal. Sites log warnings and blocked-tracker errors unrelated to your problem. Read the message; ask whether it names something you care about.

Verify it yourself

Open today's reference, MDN's Overview of HTTP, and find its section on status codes and request methods.

1. This lesson claimed 4xx means the client's request was wrong and 5xx means the server failed. Find MDN's wording and check that it agrees.
2. Find one method MDN lists that this lesson did not mention and write what it is for in devtools-notes.md — from the docs, in your own words.