Browser Developer Tools

Every web page is a conversation. Your browser asks for things—HTML, images, data from APIs—and servers respond. Developer tools let you read both sides of that conversation.

This isn't abstract knowledge. When a page won't load, when a form submission fails silently, when an API returns mysterious errors—the answer is in that conversation. You just need to know how to read it.

Opening the Window

Every modern browser has developer tools built in. No installation required.

The universal shortcut: Press F12 on any page. That's it.

Alternatives if F12 doesn't work:

• Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (macOS)
• Right-click anywhere → "Inspect" or "Inspect Element"

Safari requires one extra step: Safari → Preferences → Advanced → Enable "Show Develop menu in menu bar." Then Cmd+Option+I works.

The Network Tab: Reading the Conversation

Click the Network tab, then refresh the page. Every line that appears is one request-response pair—one exchange in the conversation.

A simple page might show 20 requests. A complex web app might show 200. Each row tells you:

• Name: What was requested (a file, an API endpoint)
• Status: Did it work? (200 = yes, 404 = not found, 500 = server error)
• Type: What kind of thing (document, script, image, xhr/fetch for API calls)
• Size: How much data came back
• Time: How long it took

The waterfall column on the right shows timing visually—when each request started, how long it waited, when it finished. Patterns emerge. You can see which request is blocking everything else. You can see which server is slow.

Filtering the Noise

A page load generates dozens of requests for CSS, JavaScript, images, fonts. When you're debugging an API problem, that's noise.

Click Fetch/XHR to show only API calls. Suddenly 150 requests become 5. The problem becomes visible.

Other filters: JS for scripts, CSS for stylesheets, Img for images, WS for WebSocket connections.

Inspecting a Single Request

Click any request to see the full conversation.

Headers tab shows what was said:

• The exact URL that was requested
• The HTTP method (GET, POST, PUT, DELETE)
• Every header the browser sent (including authentication tokens)
• Every header the server sent back
• For POST requests: the exact data that was submitted

Response tab shows what came back—the raw data, exactly as the server sent it.

Preview tab shows the same data, but formatted. JSON becomes readable. HTML becomes navigable.

Timing tab breaks down where time was spent:

• DNS lookup (translating domain to IP)
• Connection (establishing TCP/TLS)
• Waiting (server processing—often the biggest chunk)
• Download (receiving the response)

When something is slow, this tab tells you whether it's the network or the server.

The Magic of "Copy as cURL"

Right-click any request → Copy → Copy as cURL.

This generates a command that reproduces the exact request:

curl 'https://api.example.com/users' \
  -H 'Authorization: Bearer eyJhbGc...' \
  -H 'Content-Type: application/json' \
  --data-raw '{"name":"John","email":"john@example.com"}'

Every header, every cookie, every byte of the request body—captured in a single command you can run anywhere.

This is genuinely powerful:

• Share the exact failing request with a backend developer
• Test the same request from a different machine
• Modify one parameter and see what changes
• Build API documentation from real requests

Similar options exist for Copy as fetch (JavaScript), Copy as PowerShell, and other formats.

Debugging Common Problems

The Request That Returns 404

You expect data. You get "Not Found."

1. Find the request in the Network tab (it'll be red or show 404 status)
2. Click it, check the Headers tab
3. Look at the Request URL—is it what you expected?

Often it's a typo, a missing slash, or an environment mismatch (hitting production when you meant staging).

The Request That Returns 401 or 403

Authentication failed.

1. Find the request, check Headers tab
2. Look for the Authorization header in Request Headers
3. Is it present? Is the token expired? Is it the right format?

If there's no Authorization header at all, your code isn't sending credentials. If the token looks wrong, trace back to where it's stored.

The Request That Returns 500

The server crashed trying to handle your request.

1. Check the Response tab—servers often include error details
2. Check your Request Payload—is the data malformed?
3. Copy as cURL and run it—does the same thing happen?

The Page That Loads Slowly

1. Look at the waterfall. Which requests take longest?
2. For slow requests, check the Timing tab
3. Is "Waiting" high? The server is slow.
4. Is "Download" high? The response is too large.
5. Are many requests waterfall-blocked (waiting for others to finish)? You have a dependency chain problem.

CORS Errors

The console screams about cross-origin requests. The Network tab reveals the truth:

1. Look for an OPTIONS request (the preflight)
2. Check its response headers—is Access-Control-Allow-Origin present?
3. Does it match your origin?

CORS errors are always server configuration problems. The Network tab shows exactly which header is missing.

Essential Debugging Settings

Preserve log: Check this box to keep requests when navigating between pages. Essential for debugging login flows, redirects, and multi-step processes.

Disable cache: Check this to always fetch fresh content. When you're testing changes and nothing seems different, cached resources are often the culprit.

Throttling: The dropdown that says "No throttling" lets you simulate slow connections (3G, slow 3G) or offline mode. See how your application handles real-world network conditions.

Beyond Basic Requests

WebSocket Connections

Filter to WS to see WebSocket connections. Click one, then check the Messages tab to see every message sent and received in real-time. Essential for debugging chat, notifications, or any live-updating feature.

Replaying Requests

Right-click a request → Replay XHR sends it again. Useful for testing if a problem is reproducible or if a fix worked.

Blocking Requests

Right-click → Block request URL simulates that resource failing. Test how your application handles missing dependencies.

Exporting Everything: HAR Files

Right-click in the Network tab → Save all as HAR with content.

This exports every request and response to a JSON file. You can:

• Share exact network behavior with support teams
• Import into tools like Postman for further analysis
• Compare behavior between working and broken states
• Archive network activity for later investigation

The Application Tab: Storage Inspection

The Application tab (called Storage in Firefox) shows what's stored in your browser:

• Cookies: Authentication tokens, session IDs, preferences
• Local Storage: Persistent key-value data
• Session Storage: Data that disappears when the tab closes
• IndexedDB: Structured database storage

When authentication mysteriously fails, check if the expected cookie exists. When cached data seems stale, clear the relevant storage.

Mobile Device Simulation

Press Ctrl+Shift+M (Windows/Linux) or Cmd+Shift+M (macOS) to toggle device simulation.

This changes:

• Screen dimensions to match phones and tablets
• User-Agent string (servers may respond differently)
• Touch event handling

Combine with network throttling to test real mobile conditions.

What You've Gained

You now have a professional-grade HTTP debugger that:

• Shows every request your browser makes
• Reveals exact headers, payloads, and responses
• Times each phase of every request
• Exports any request as executable code
• Simulates slow networks and mobile devices
• Stores network activity for sharing and analysis

No installation. No configuration. Already on your computer.

The next time something breaks—a form that won't submit, an API that returns nonsense, a page that loads forever—open that Network tab. The conversation between browser and server holds the answer. Now you can read it.