Every browser ships with developer tools, and they are the fastest way to answer "what is this element, where does this style come from, and what did the server actually send". You can inspect any page you can see, including sites you did not build — which is how most developers learned their craft.
How do you open them?
Right-click anywhere on a page and choose Inspect, or press F12, or use the keyboard shortcut Ctrl + Shift + I on Windows and Linux and Cmd + Option + I on macOS. The tools dock to the right or the bottom, and you can undock them into a separate window if that helps.
Elements the live DOM tree, and the CSS that applies to the selected node
Console run JavaScript against the page you are looking at
Network every request the page made, with size, time and status
Sources the actual files, with breakpoints for JavaScript
Four panels cover almost everything a beginner needs. The others — performance, memory, application — come later.
What can I do in the elements panel?
The elements panel shows the live document tree, not the source you sent. That distinction matters: any change your JavaScript makes to the DOM appears here immediately, which is often how you find out that a script rebuilt an element and broke your layout.
1. Click the inspect icon in the top-left of the panel
2. Hover over an element on the page — it highlights
3. Click it — the tree selects the matching node
With a node selected, the styles panel on the right shows every rule that applies, in cascade order, with the winning declaration crossed out where a later rule overrides it. The top box is the final computed value, which is the one that actually renders. When a rule does not seem to apply, this panel tells you why: a crossed-out declaration, an invalid value, or a selector that does not match.
What is the console for?
The console runs JavaScript in the context of the page you are looking at. It is a scratchpad and a debugger at once, and the $ family of shortcuts make it genuinely fast to work.
// inspect the live page
document.title
document.querySelectorAll('a').length
document.querySelector('h1').textContent
// $0 is the element you last selected in the elements panel
$0.tagName
$0.className
$0.getBoundingClientRect().width
// a quick log of anything
console.table([{ name: 'Ada', role: 'engineer' }, { name: 'Grace', role: 'admiral' }])
Two features are worth learning early. The console keeps the last result in $_, so you can inspect it, and right-clicking an object in the output gives you a shortcut to copy its path. And because the console is live, you can fix a broken style as you look at it: select a node, change a value in the styles panel, and watch the page update. That is the fastest feedback loop in web development, and it is how you learn what a property actually does.
Can I copy the CSS from a site I like?
Yes, and it is a normal part of learning. Select an element, right-click the rule in the styles panel and copy it, or use the "Copy declaration" / "Copy rule" options. What you get is the rule exactly as the site writes it — which is often a starting point rather than an answer, because it may rely on custom properties, a framework, or a cascade you cannot see in one rule.
what you see in the styles panel
.site-header { display: flex; align-items: center; }
what the site actually uses
.site-header { display: flex; align-items: center; gap: var(--gap-3); }
where --gap-3 is defined in :root { --gap-3: 1rem; }
Use what you find as a starting point and rebuild it yourself. The point of inspecting other people's pages is to understand the technique, and copying a rule without understanding the technique teaches you nothing and can pull in a broken dependency.
What does the network panel tell me?
Every request the page made, in order, with the status code, the transferred size and the time. Two questions come up constantly: which request is slow, and which one failed. Sorting by size usually points at images, and a 404 or a 500 in the list is a bug you can fix immediately.
Status Meaning
200 the response body is in this row
304 the browser already had a fresh copy
301/308 moved permanently — the browser followed it
404 the server could not find that file
500 the server failed while producing the page
Which panel should you open first?
When a page looks wrong, the fastest route is usually the Elements panel: click the offending element, read the markup, and look at the Computed pane to see the final value of every property the cascade settled on. That tells you what the browser decided, which is the fact you were guessing at.
When a page feels slow, the Network panel is the one to open. It lists every request the page made, how long each took, how large it was and where the time went. The waterfall view is where the story usually is: a blocking stylesheet in the head, an image that is far larger than the space it occupies, a script that had to wait for a font.
The Console is the third stop. It shows errors the page threw, warnings a developer left behind, and it lets you evaluate expressions against the live page. It is also where you can check a hypothesis directly - type a value in the console and look at what the page does.
<!-- run this in the console to see how wide the viewport really is -->
window.innerWidth