🔥 This is not console.log()
Seriously.
Every junior dev learns console.log() on day one. And then they never learn anything else.
That's like learning to use a hammer and ignoring the entire toolbox.
The browser console is one of the most powerful debugging environments in existence. And 95% of developers only use it to print strings.
Let's fix that.
🎯 1) console.table() — Display data as a real table
Stop printing arrays as [object Object],[object Object].
const users = [
{ name: "Ada", role: "Engineer", level: 5 },
{ name: "Linus", role: "Architect", level: 8 },
{ name: "Grace", role: "Lead", level: 7 },
];
// ❌ Old way
console.log(users);
// [{...}, {...}, {...}] — useless
// ✅ New way
console.table(users);
This prints a clean, sortable table right in your console. With columns. And row numbers.
🧠 What's actually happening?
console.table() takes an array of objects (or an object) and renders it as a formatted table. Each object property becomes a column. Each array item becomes a row.
You can also pick which columns to show:
// Only show name and level
console.table(users, ["name", "level"]);
Works with plain objects too:
console.table({ a: 1, b: 2, c: 3 });
// Shows index | key | value
Use it when: inspecting API responses, checking arrays of data, comparing config objects, debugging state.
⚡ 2) console.group() and console.groupCollapsed() — Organize your logs
Your console looks like a mess? That's because you haven't grouped anything.
console.group("🔄 User Login Flow");
console.log("1. Validating input...");
console.log("2. Sending API request...");
console.log("3. Response received:", { status: 200 });
console.groupEnd();
This creates a collapsible group in the console. Click to expand/collapse.
console.groupCollapsed() does the same thing but starts collapsed:
console.groupCollapsed("📦 Loading user preferences");
console.log("Theme: dark");
console.log("Language: en");
console.log("Notifications: enabled");
console.groupEnd();
🍕 Real-world example:
function processOrder(order) {
console.group("🛒 Processing order #" + order.id);
console.group("💰 Payment");
console.log("Method:", order.paymentMethod);
console.log("Amount:", order.total);
console.groupEnd();
console.group("📦 Items");
order.items.forEach(item => {
console.log("- " + item.name + " x" + item.qty);
});
console.groupEnd();
console.groupEnd();
}
Nested groups. Clean hierarchy. Your console reads like documentation instead of a wall of noise.
🎨 3) console.log() with CSS styling
Yes. You can style console output. Most people don't know this.
console.log(
"%c Success! %c User created successfully",
"background: #00b894; color: white; padding: 4px 8px; border-radius: 4px; font-weight: bold;",
"color: #00b894; font-size: 14px;"
);
The %c placeholder applies the CSS string that follows it.
🧲 More examples:
// Error style
console.log(
"%c ERROR ",
"background: #d63031; color: white; padding: 4px 8px; border-radius: 4px;",
"Something went wrong"
);
// Warning style
console.log(
"%c WARN ",
"background: #fdcb6e; color: black; padding: 4px 8px; border-radius: 4px;",
"Deprecated API used"
);
// Big title
console.log(
"%c MyApp v2.0",
"color: #6c5ce7; font-size: 24px; font-weight: bold;"
);
Use it when: building CLI-style debugging output, branding your app's console, making errors stand out from noise.
🔍 4) console.trace() — See exactly where things are called
When you're deep in nested function calls and don't know WHERE something is being triggered:
function handleClick() {
validateForm();
}
function validateForm() {
checkEmail();
}
function checkEmail() {
console.trace("Email validation called from:");
// Shows the full call stack
}
Output:
Email validation called from:
checkEmail @ app.js:42
validateForm @ app.js:30
handleClick @ app.js:15
(anonymous) @ app.js:5
No more guessing. You see the exact path from root to current call.
Use it when: debugging event handlers, tracing callback chains, finding which code path triggered a function, understanding complex flows.
⏱️ 5) console.time() — Measure how long things take
Stop guessing if your code is slow. Measure it.
console.time("API Call");
fetch("/api/users")
.then(res => res.json())
.then(data => {
console.timeEnd("API Call");
// API Call: 234.56ms
});
🧠 With labels for multiple timers:
console.time("Total");
console.time("Database");
// ... database query ...
console.timeEnd("Database");
// Database: 45.23ms
console.time("Render");
// ... rendering ...
console.timeEnd("Render");
// Render: 12.87ms
console.timeEnd("Total");
// Total: 58.10ms
You can run multiple timers simultaneously with different labels. No libraries. No performance.now() boilerplate.
Use it when: comparing algorithm speeds, measuring API latency, profiling render times, benchmarking loops.
🛡️ 6) console.assert() — Log only when something is wrong
This one is criminally underused.
const user = { name: "Ada", age: -5 };
// Only prints if the condition is FALSE
console.assert(user.age > 0, "Age must be positive! Got:", user.age);
// Output: Assertion failed: Age must be positive! Got: -5
console.assert(user.name, "Name is missing!");
// Nothing — assertion passed
🤔 Why this matters
Instead of:
if (!condition) {
console.log("something is wrong");
}
You write:
console.assert(condition, "something is wrong");
One line. Same behavior. Cleaner code.
Use it when: validating data shapes, checking preconditions, defensive programming, sanity checks during development.
🧹 7) console.count() — Count how many times something runs
function handleRequest(req) {
console.count("Request received");
// ... process ...
}
// After running 5 times:
// Request received: 1
// Request received: 2
// Request received: 3
// Request received: 4
// Request received: 5
Reset the counter:
console.countReset("Request received");
🍕 Real-world example:
// How many times is this re-render happening?
function MyComponent() {
console.count("MyComponent render");
return <div>Hello</div>;
}
// If you see the count climbing fast, you have a re-render problem.
Use it when: detecting infinite loops, counting re-renders, tracking function calls, finding performance bottlenecks.
💀 8) console.warn() and console.error() — Different severity levels
Stop using console.log() for everything.
// Informational
console.log("User logged in");
// Something might be wrong
console.warn("API response took 3000ms — consider caching");
// Something IS wrong
console.error("Failed to fetch user:", error);
🧠 Why this matters
-
console.warn()shows a yellow icon and stack trace -
console.error()shows a red icon, stack trace, AND breaks on error if DevTools is set to "Pause on exceptions" - You can filter by level in DevTools (show only errors, hide info, etc.)
Your logs become searchable and filterable instead of a wall of identical white text.
// In the DevTools console filter:
// -error → hides all errors
// warn → shows only warnings
// -log → hides all regular logs
🪄 9) console.dir() — Inspect DOM elements as objects
When you console.log() a DOM element, you get the HTML tree. Sometimes you want the JavaScript object instead.
const button = document.querySelector("#submit");
// Shows HTML representation
console.log(button);
// <button id="submit">Submit</button>
// Shows the JS object with all properties
console.dir(button);
// ▶ HTMLButtonElement
// - id: "submit"
// - className: "btn-primary"
// - dataset: DOMStringMap { ... }
// - style: CSSStyleDeclaration { ... }
// - ... hundreds more properties
Use it when: inspecting DOM properties, checking dataset values, debugging element state, exploring event listeners.
🧪 10) The $ shortcuts in DevTools
These aren't console methods — they're DevTools built-in shortcuts that most people never learn.
// Last console result
$0 // Currently selected element in Elements panel
$1 // Previously selected element
$2 // Two selections ago
$3
$4
// jQuery-like selectors (native, no jQuery needed)
$$("div") // Returns array of all divs
$("div.container") // Returns first match (like querySelector)
$x("//button") // XPath selector
// Quick access
$_ // Last expression result
🧊 The power combo:
// 1. Click an element in the Elements panel
// 2. In console, type:
$0.style.outline = "3px solid red"
// → That element now has a red outline
// 3. Get all buttons on the page
$$("button").map(b => b.textContent)
// → ["Save", "Cancel", "Delete", "Edit"]
// 4. Find all images with no alt text
$$("img").filter(img => !img.alt)
// → Shows accessibility violations
No more writing document.querySelectorAll() every single time.
🧠 TL;DR Cheat Sheet
| Method | What it does | Use when |
|---|---|---|
console.table() |
Display as table | Inspecting arrays/objects |
console.group() |
Collapsible groups | Organizing complex logs |
console.log("%c...", css) |
Styled output | Making logs readable |
console.trace() |
Print call stack | Finding where code runs |
console.time() |
Measure duration | Benchmarking performance |
console.assert() |
Log on failure | Validation checks |
console.count() |
Count executions | Detecting loops/re-renders |
console.warn() / error()
|
Severity levels | Filtering important logs |
console.dir() |
Inspect as object | DOM element debugging |
$0, $$(), $_
|
DevTools shortcuts | Quick element access |
🏁 Your console is a debugger, not a notepad
The next time you're about to type console.log(something) — stop.
Ask yourself:
- Is this an array? →
console.table() - Is this a performance issue? →
console.time() - Is this a conditional check? →
console.assert() - Is this a complex flow? →
console.group() - Do I need to find where this is called? →
console.trace()
Your console can do so much more than print strings. Start using it properly.
Top comments (0)