If you made it through Part 1, you’ve already “hacked” Wikipedia, poked around the DOM, and maybe changed a button color or two. Good. You’re getting comfortable being curious.
Now we’re going deeper.
The Console tab is where things start to feel a little like magic. And also where debugging goes from “why is nothing working and I want to cry” to “…oh. OH. I see it now.”
This is Part 2 of a 4-part series:
- Meet Your Browser’s Toolbox
- Your New Best Friend: The Console (you are here! 👋)
- What’s Actually Happening: Network & Application
- Level Up: Sources, Performance & Your Playground
Let’s get into it.
what even is the console?
The Console is a live JavaScript environment running directly on whatever page you have open. You can write code, run it instantly, and see what happens without touching your actual codebase.
Think of it like a scratchpad for your browser. A place to test ideas, poke at things, and get real-time feedback on what’s happening inside your page.
Here’s the thing: most developers open the Console when something breaks. But some of the best developers open it before things break.
opening the console
You might already have it open from Part 1. If not:
Chrome / Edge / Brave:
- Mac:
Cmd + Option + iorCmd + Option + j - Windows/Linux:
F12orCtrl + Shift + i
Firefox:
- Mac:
Cmd + Option + i - Windows/Linux:
F12orCtrl + Shift + i
Safari:
- First, you need to enable the Developer menu: Go to Preferences > Advanced and check “Show Develop menu in menu bar”
- Then:
Cmd + Option + i
You’ll see a blank panel with a > prompt. That’s your playground.
6 things you can do right now
These are the demos I ran during my Parsity.io Tech Talk. Try each one on any page you have open.
1. target and change content
document.querySelector('h1').textContent = 'I own this now 😈';
This grabs the first h1 on the page and replaces its text. Change 'h1' to any CSS selector: a class, an ID, a button. This is how you test content changes before touching your code.
2. style on the fly
document.body.style.backgroundColor = 'hotpink';
Instant hotpink. You’re welcome. Swap in any CSS property (camelCase) and any value. This is faster than toggling between your editor and browser when you’re trying to nail a style.
3. log for debugging
console.log('hello from the console 👋');
Okay, this one looks simple, and it is. But console.log is the most underused debugging tool I see new devs skip over. When something isn’t working, log everything. Log your variables, log your API responses, log your function outputs. The Console will tell you exactly what your code is seeing, which is usually different from what you think it’s seeing.
Also worth knowing: console.warn() and console.error() give you yellow and red styling respectively which is handy when you want certain logs to stand out.
4. explore page context
window.location;
This returns an object with everything about the current URL like the full href, the hostname, the pathname, query params, and more. It’s incredibly useful when debugging routing issues or building something that depends on URL structure.
Try window.location.pathname to get just the current path. Or window.location.search to see query string parameters.
5. make the entire page editable
document.body.contentEditable = true;
Yes, really.
Run this and then click anywhere on the page. You can type, delete, edit. The whole page becomes a document! Refresh to undo. This is fun for testing copy changes or doing a quick “how does this look with shorter text?” gut check.
6. list all images on a page
This grabs every img element on the page and logs its source URL. Useful for auditing what images are loading, debugging missing images, or just being nosy about where a site’s assets live.
document.querySelectorAll('img').forEach((img) => console.log(img.src));
the bigger picture
These six demos barely scratch the surface of what the Console can do. But they illustrate the core idea: the Console lets you interact with a live page as if you wrote the code yourself.
It’s the fastest way to:
- Test a function before adding it to your codebase
- Figure out why a variable isn’t what you expect
- Check what data an API is actually returning
- Prototype a small interaction without spinning up a dev environment
Next time you’re debugging, try this: before you change anything in your code, open the Console and log the thing that’s confusing you. Nine times out of ten, that log will tell you exactly what’s wrong.
your catz4life challenge 🐱
Remember the Catz4Life Adopshun Centre from Part 1? There’s a broken “Adopt Me!” button that’s supposed to do something when you click it…but it doesn’t.
Open the project in your browser, open the Console, and see if you can figure out what’s happening. (Hint: check for any errors that show up automatically when the page loads. The Console is already watching.)
If you want some guidance, set HINTS = true in script.js to turn on hint mode.
what’s next
In Part 3, we’re going to the Network tab where you can watch every single request your browser makes in real time. API calls, failed requests, CORS errors, HTTP status codes. It’s where the really juicy debugging happens.
Until then: open the Console on every site you visit. Run a console.log. Change a color. Make something editable. Get weird with it.
The Console doesn’t bite. 💖
Did something click for you? I’d love to hear about it!
← Part 1: Meet Your Browser’s Toolbox | Part 3: What’s Actually Happening →
// comments
Loading comments…
leave a comment