How to Use the Chrome DevTools Debugger

To debug JavaScript in Chrome, open DevTools, go to Sources, set a breakpoint on the line you suspect, and reproduce the behavior. When execution pauses, inspect values in Scope or Watch, check the Call Stack, then step through the code to find where its behavior diverges from what you expect. Chrome DevTools is built into Chrome; you do not need a separate debugger product. The Chrome DevTools Debug JavaScript guide documents this workflow.

1. Open the Sources panel and find the code

1. Open the page where the problem occurs in Chrome.
2. Open DevTools and select Sources.
3. In the file tree, find the script associated with the page or feature. Use the editor to inspect likely event handlers, callbacks, or functions.
4. If the file is difficult to find, reproduce the action and inspect scripts loaded by the page. If the code is bundled or minified, see Debug bundled code with source maps.

The Sources panel includes a file tree, editor, and debugger controls. The arrangement of panes can change with the DevTools window width, so the same control may appear in a different place on a narrow window.

2. Set a breakpoint and reproduce the bug

Click a line number in the source editor to set a breakpoint. Then repeat the action that normally triggers the unexpected behavior. Chrome pauses when execution reaches that line.

Choose a line where the values or decision are meaningful: for example, just before a conditional, before a request is created, or at the start of a function that handles the interaction. A breakpoint that never pauses usually means the selected code did not run, the wrong script is open, or the breakpoint is in generated code that does not match the active page.

For a later line in the same function, use Continue to here from that line’s context menu to resume until that point. Remove a breakpoint by clicking its marker again. Disable or re-enable it from the Breakpoints list when you want to keep its location for later.

3. Inspect values while execution is paused

While paused, first read the highlighted statement and determine which branch or call is about to run. Then inspect the available state:

• Scope shows values available at the current frame, including local, closure, and global properties.
• Watch evaluates expressions you add and refreshes their values as you step. Add a variable or expression that helps distinguish the expected and actual paths.
• Console can evaluate JavaScript in the paused context. Use it to inspect an object property or test a small expression without adding a log statement.
• Call Stack shows the functions that led to the pause. Select another frame to inspect its context and call site.

For example, if a handler receives an unexpected value, inspect the handler’s arguments and relevant state in Scope, then add the expression you need to Watch. Avoid changing state from the Console unless you intend to alter the paused page: evaluation can affect what happens after resuming.

4. Step through the execution path

Use the debugger’s stepping controls to follow the logic from the current pause:

• Step over runs the current statement, including a function call, without entering that called function.
• Step into enters a function call so you can inspect its implementation.
• Step out runs to the end of the current function and returns to its caller.
• Resume continues normally until the next breakpoint or pause condition.

Step into calls that may contain the defect; step over calls whose internals are not relevant. Use the Call Stack to see how the current function was reached. Async stack frames may be available when the framework tags asynchronous work, but the amount of async history depends on that support.

5. Choose the breakpoint that matches the trigger

A line breakpoint is best when you know roughly which statement is involved. If you know what kind of event or change triggers the bug but not which code handles it, use a specialized breakpoint.

Breakpoint type	Use it when	Where to look
Line	You know a likely statement or function.	Click the editor’s line number.
Event listener	A browser or UI event, such as a click, starts the unexpected behavior.	Use the Event Listener Breakpoints controls and select the relevant event category.
DOM change	A particular node’s children or attributes change unexpectedly.	In the Elements panel, open the node’s context menu and select a subtree, attribute, or node-removal breakpoint that matches the change.
Exception	You want execution to stop when code throws an error.	Enable pause on exceptions; choose whether caught exceptions should also pause when that option is available.
Function	You want to stop whenever an in-scope function is called.	In the Console, call debug(functionName). This works for a function available in that context.

Exception breakpoints can pause on caught or uncaught exceptions. Be aware that behavior has edge cases; the Chrome documentation notes a limitation for caught exceptions in Node.js. If a breakpoint pauses inside framework or library code, inspect the call stack to find the application frame that led there.

6. Debug bundled code with source maps

Browsers execute the deployed JavaScript they receive. If a build bundles or minifies source, DevTools can use source maps to show the corresponding authored files. This helps make breakpoints, errors, and logs meaningful in the source developers work on.

1. Configure the build to generate source maps for the code you need to debug.
2. Ensure the deployed page can serve the map files and that the browser can load them.
3. Reload the page and check the Sources file tree for the authored source.
4. Set breakpoints in the mapped source and reproduce the issue.

If authored files do not appear, check that maps were generated and that their URLs are reachable from the page. A missing or inaccessible map is a build or serving issue; it does not necessarily mean the debugger is malfunctioning.

7. Live-editing paused code

DevTools can support live edits to a function while debugging, but this is a temporary debugging aid with restrictions. The function generally needs to be the top-most Call Stack function. Recursive calls and some function types have additional limits. If an edit is rejected or does not take effect as expected, make the change in your normal source files, rebuild if needed, and reload the page.

Common problems and fixes

Symptom	Likely cause	What to do
The breakpoint never pauses.	The code path did not run, the wrong file is open, or the deployed code differs from the displayed source.	Reproduce the triggering action, verify the script, and check source map availability for transformed code.
The debugger pauses in minified code.	The browser is showing deployed output and no usable authored source map is loaded.	Generate source maps in the build and serve them where the browser can reach them.
Scope does not show the value you expect.	The selected Call Stack frame may have a different scope, or execution may be outside the variable’s lifetime.	Select the relevant frame and inspect its Scope panel; check the variable at a line where it is in scope.
An event breakpoint pauses too often.	The selected event category includes handlers unrelated to the bug.	Use the Call Stack to locate your handler, then narrow the selected event breakpoint or use a line breakpoint there.
A DOM breakpoint does not pause.	The wrong node or kind of DOM change was selected.	Inspect the affected node and choose the breakpoint for its subtree, attributes, or removal as appropriate.
Pause on exceptions catches unrelated errors.	Libraries may throw exceptions they handle internally.	Use the caught versus uncaught setting that matches your question, and inspect the stack and source at each pause.
Async callers are missing from the stack.	Async stack history depends partly on framework support.	Inspect the frames available and set a breakpoint closer to the scheduling or callback code.
A live edit fails or behaves unexpectedly.	The function or call-stack state may not meet live-edit restrictions.	Apply the change in the project source and reload rather than relying on the paused edit.

Performance, reliability, and cost

Chrome DevTools debugging has no separate debugger purchase requirement for this workflow. Breakpoints let you stop at relevant statements rather than adding logging at every line. Choose targeted breakpoints to keep the investigation focused; broad event or exception breakpoints can pause repeatedly in unrelated code. Source-map debugging depends on map generation and availability, and async stack detail depends in part on framework support.

Debugging a page’s JavaScript does not itself produce a screenshot. If you also need a repeatable visual record of a page state, use a screenshot workflow separately.

Or skip the browser setup

For a screenshot of a page state, ScreenshotNeo is a website screenshot API and MCP server for developers. Its one-call API returns an image or PDF; this example saves a screenshot response:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for request options. Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. An MCP server lets AI agents, including Claude, Cursor, and other MCP clients, take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots.

Sign up for 1,000 free screenshots a month, with no card.

FAQ

Is the Chrome DevTools debugger a separate download?

No. DevTools is built into Google Chrome.

What is the difference between Scope and Watch?

Scope displays values available in the selected execution frame. Watch tracks expressions you choose as execution steps.

Can I debug JavaScript after it has been minified?

Yes, if usable source maps are generated and served so DevTools can map deployed code back to authored files.

Why does the Call Stack sometimes omit earlier asynchronous work?

Async stack history depends partly on framework support, so the full scheduling history may not be available.