Browsers and DevTools

A web page isn't just the file you wrote. In the browser it becomes a living combination of DOM, computed CSS, executed JavaScript, loaded assets and session state.

That's why DevTools matter so much: they show the version the browser is actually using, not just the one you think you built in your project.

To begin with, knowing these panels well is enough:

• Elements: HTML structure, classes, attributes and applied CSS.
• Console: JavaScript errors, warnings and quick experiments.
• Sources: loaded files, breakpoints and step-by-step debugging.
• Network: loaded files, API requests, status codes and timings.
• Application: localStorage, sessionStorage, cookies, cache and service workers.
• Performance, Memory and Lighthouse: more targeted analysis of speed, memory and overall quality.

You don't need to open everything every time. You need to know which panel answers the question in your head.

The Elements panel is the starting point when something looks wrong: spacing, color, alignment, fonts, sizes, hover states, missing classes.

The most important thing to understand is this: you aren't looking at the original HTML file, but at the DOM after the browser and JavaScript have built it.

Use it to answer very concrete questions:

• does the element actually exist on the page?
• does it have the class I expect?
• which CSS rule is winning?
• is a property struck through because it was overridden?
• does the box model explain the odd margins, padding or sizes?

A good habit: inspect the element first, then temporarily tweak CSS and classes in DevTools. Once you've worked out the fix, carry it back into the real file.

The Console is where the browser talks to you most directly. When JavaScript breaks, the first serious clue is usually there.

Don't just read it as "red = panic". Look at three things: the message, the file involved and the line number. Together they are already a small map.

You can also use it for quick experiments:

document.querySelector("h1")
document.querySelector(".button-simple")?.textContent
localStorage.getItem("theme")

These experiments don't replace your project code, but they help you check whether a selector is right, whether an element exists, or whether a value really was stored.

When an error looks cryptic

Start from the type of error, not from the fear it triggers.

ReferenceError

you are using a name JavaScript doesn't know at that point.

TypeError

you are performing an operation on a value of the wrong type — often null or undefined.

SyntaxError

the code isn't written in a valid form: brackets, commas, quotes or structure.

When images, CSS, scripts or data don't arrive, the Network panel is often more useful than the Console.

Here you can see every request the page makes: static files, fonts, images, fetches to APIs, JSON responses, redirects and failures.

There are only a few checks that really matter:

• Status: 200 ok, 404 not found, 500 server error, 403 access denied.
• Type: tells you whether it is a document, script, stylesheet, image, fetch or something else.
• Preview/Response: shows you what actually came back.
• Headers: useful for the URL, method, content type, caching and authorization.

If an API call "doesn't work", first check whether it is even being sent. Then look at the URL, the status code and the response. Only after that does going back to the code make sense.

Some problems aren't in the code you just wrote, but in the state the browser is holding on to.

The Application panel helps you check:

• localStorage: data that survives closing the browser;
• sessionStorage: data that lasts only for the current session;
• cookies: often used for preferences, sessions and tracking;
• cache and service workers: they can serve stale files when misconfigured.

If a change seems to be ignored, try reloading without the cache, or check whether a service worker is still serving an earlier version.

These panels are very useful, but they aren't always the first place to open. Think of them as targeted tools, for when your question is more precise.

Sources

lets you see the files the browser loaded, set breakpoints, pause JavaScript and follow the code step by step.

Performance

is what you want when a page feels slow: it records loading, rendering, heavy scripts, layout work and the moments the main thread is busy.

Memory

becomes useful when you suspect abnormal consumption, leaks, or objects lingering in memory long after they should be gone.

Lighthouse

runs a quick audit on performance, accessibility, best practices and SEO. It is a compass, not a final verdict.

To start well, the priority is still understanding Elements, Console and Network. These panels then help you level up when the problem is no longer just "it doesn't work" but "why is it slow", "where does it hang" or "what can I improve".

When something is broken, one simple routine is worth more than ten random attempts.

1. Reproduce the problem with one precise step.
2. Open the Console and check for errors or warnings.
3. If it is a visual problem, inspect the element in Elements.
4. If data or assets are missing, move to Network.
5. If JavaScript is behaving oddly, use Sources with a breakpoint.
6. If the page is slow, look at Performance or Lighthouse.
7. If the problem seems "stuck in the past", check the cache, storage and service workers.
8. Make one small change, verify it, then move on to the next.

This method doesn't magically make bugs easy, but it stops you mixing too many problems together.

A quick checklist

• is the page loading the right CSS?
• does the JS selector actually find the element?
• is the API request sent, and does it get a response?
• is the asset URL correct online too?
• does a breakpoint in Sources confirm the expected flow?
• is Lighthouse flagging real problems or just polish?
• is the cache showing an old version?

DevTools become genuinely useful once you stop seeing them as a technical panel and start using them as a reading instrument.

Every time something doesn't add up, the browser already holds plenty of clues: the real HTML, computed CSS, errors, requests, timings, stored data, loaded files and metrics.

To consolidate the path, these guides fit together well:

• VS Code essentials: to connect debugging, terminal and local project.
• Deployment basics: to understand what changes once the page goes online.
• Git without panic: to save your progress and roll back when you need to.
• All tutorials: to follow the rest of the available content.

Here are the main diagnostic panels and when to use them:

Put your inspection skills into practice using your favourite browser: