console.log Debugging: 12 Techniques Beyond console.log()

console.log() is most developers' first debugging tool and, for a lot of bugs, their last. That's a shame, because the Console API that ships in every browser — documented on MDN and standardized by the WHATWG Console Standard — has more than a dozen methods built specifically for the situations plain logging handles badly: counting how many times a line runs, timing a slow operation, pausing execution to inspect live scope, or telling at a glance which of ten near-identical objects you're looking at. And beyond the console entirely, DevTools breakpoints and the Node inspector answer questions a log physically cannot. None of this requires a library or a build step. This is a working reference, grouped by what problem each tool solves.

The first failure mode of console.log() is visual: dump ten objects in a loop and you get ten collapsed triangles you have to click open one at a time, in a console that's already scrolled past the useful part. Three methods fix this directly.

1. console.table() renders an array of objects — or a single object — as an actual table, one row per item and one column per property. Pass a second array argument and, per MDN, the table includes only the columns whose property names you list, so you can compare values across rows instead of expanding them individually.

2. console.group() / console.groupEnd() / console.groupCollapsed() visually nest related logs under a collapsible header. Per MDN, everything logged after console.group() is indented an extra level until console.groupEnd(), so a multi-step flow — validating an order, then checking payment, then confirming shipping — reads as one indented block instead of nine flat lines you have to mentally reassemble. 3. The %c format specifier applies CSS to a log message, which is enough to make one critical line jump out of a busy console instead of blending into the scroll.

4. console.count(label) counts how many times a line executes under a given label and prints the running total — a one-line way to catch a component re-rendering three times when you expected one, or a handler firing twice because it got attached to the same element in two places. Call console.countReset(label) to zero it out between test runs. 5. console.time(label) / console.timeEnd(label) measure elapsed wall-clock time between two points without you writing const start = Date.now() and subtracting it back out later — and console.timeLog(label) prints an intermediate reading without stopping the clock, useful inside a multi-step job.

6. console.assert(condition, message) is the inverse of a normal log: it only prints when condition is false. That means you can scatter invariant checks through your code — a price should never be negative, a required argument should never be undefined — and leave them there permanently. They're silent when everything's fine and loud the moment an assumption breaks, which is a better trade than either deleting the check or littering the console with "OK" messages. 7. console.trace() prints a full call stack at any arbitrary point in your code, not just when something throws. Per MDN, some browsers also show the asynchronous sequence of calls leading to the trace — the direct answer to "who is calling this function, and from where" when a value changes but you can't tell which of five call sites did it.

8. The debugger; statement is the most powerful item so far precisely because it isn't a console method at all — it's a JavaScript statement that, with DevTools open, pauses execution at that exact line. A log gives you one snapshot of one value at one moment; a breakpoint gives you the entire live scope. You can inspect every local variable, walk the full call stack, step forward one line at a time, and even edit a value in the console and resume execution with the new value in place. Drop it inside a loop or a conditional branch that only sometimes misbehaves, and you get to watch the misbehavior happen instead of guessing at it after the fact.

9. console.dir() fixes a specific and common annoyance: console.log(domElement) renders the element as HTML markup, which is useless if what you actually want is its JavaScript-side properties. console.dir(domElement) instead prints a fully expandable JS object view — style, dataset, classList, event listeners — the same way it would show any other object. 10. The %o and %O format specifiers let you force that same object formatting inline inside a message string, when you want the label and the object view together instead of a separate console.dir() call. 11. Passing a labeled object — console.log({ user, response }) instead of console.log(user, response) — is a small habit that fixes a real problem: wrapping values in an object literal makes DevTools show the variable's name next to its value, so you never have to guess which unlabeled blob was which three scrolls later.

Every technique above still means editing a file, saving, and re-running — and then remembering to strip it back out. The Sources panel in Chrome and Edge DevTools removes that whole loop. 12. Logpoints (log-line-of-code breakpoints) are the drop-in replacement for a scattered console.log: right-click a line number and choose "Add logpoint", then type an expression. Per Chrome's breakpoints guide, a logpoint logs messages to the Console without pausing execution and without cluttering your code with console.log() calls. Because it lives in DevTools, not your source, there is nothing to accidentally commit, and it survives a page refresh in a way an unsaved inline log doesn't.

Conditional breakpoints solve the loop-that-fires-hundreds-of-times problem. Right-click a line number, choose "Add conditional breakpoint", and enter an expression like item.price < 0; execution pauses only on the iteration where that's true, instead of you clicking "resume" 200 times to reach the one bad record. Watch expressions — added in the Watch pane — evaluate any valid JavaScript expression continuously as you step, so you can keep an eye on cart.total or user.permissions.length without re-typing it into the console at each pause. And when execution is paused, the Call Stack pane lets you click up the stack, inspect variables in each frame's Scope, and even edit their values in place.

A surprising number of "the data is wrong" bugs aren't JavaScript bugs at all — they're a request that returned a 500, a payload that shipped the wrong field name, or a CORS preflight that never completed. No amount of console.log inside your handler will show you that, because the problem happened on the wire before your code ran. The Network panel logs every request the page makes, one row per resource, with its status code, timing waterfall, request and response headers, and the full response body. When a value is missing on screen, checking the actual response there — before you touch the rendering code — is often a two-minute fix instead of an afternoon of logging your way down the call chain.

On the server, console.log hits a wall fast: log a deep object and Node prints [Object] or [Array] past a certain depth, because console.log quietly calls util.inspect(), which — per the Node docs — defaults to a depth of 2. Call util.inspect() yourself with { depth: null } to recurse all the way down, plus colors: true for readable terminal output. Better still, skip printing entirely: node --inspect starts the V8 Inspector (default port 9229) so you can attach full Chrome DevTools — breakpoints, watch, call stack — to a server process via chrome://inspect. Use --inspect-brk to break on the first line so nothing runs before you attach.

Each tool trades convenience for depth, and depth for reach. A raw console.log is fast to type but blind to anyone else's session; a breakpoint sees everything but only while you're paused at the keyboard. Here's how the four map onto the questions you actually ask while debugging.

These techniques are for development. Shipping them is a different question. Left-in logs create console noise — the one message you need buried under hundreds you don't — and they cost performance: serializing a large object on a hot path is real work, and holding a reference to it in a log can keep it from being garbage-collected. web.dev's guidance on debugging performance in the field leans on structured tools like PerformanceObserver rather than ad-hoc logging precisely because production needs signal, not spew. The sharper risk is data leakage: console.log(response) can dump auth tokens, PII, or a full API body into a place users, browser extensions, and support screenshots can all read. Strip debug logs from production builds, and if you must log in the field, log narrow, redacted values — never whole objects.