How to Use DevTools in Chrome: Open, Inspect, Debug, Speed Up

DevTools are the debugging tools built into your browser. In Chrome, press F12 (or Ctrl + Shift + I on Windows and Linux, Cmd + Option + I on Mac), or right-click anything on a page and choose Inspect. From there you can read and edit the page’s HTML and CSS, run JavaScript, pause your code on a line, watch every network request, and measure why a page is slow. This guide walks through each panel in the order you will usually need it. Panel names are from Chrome’s official documentation as of October 2026; Edge, Brave and other Chromium browsers share almost all of them, and Firefox and Safari have close equivalents under similar names.

How to open DevTools

Any of these work in Chrome:

• Right-click an element and choose Inspect. DevTools opens on the Elements panel with that element selected.
• Press Ctrl + Shift + C (Windows, Linux, ChromeOS) or Cmd + Option + C (Mac) to start inspecting an element directly.
• Press Ctrl + Shift + J or Cmd + Option + J to open straight on the Console.
• Press F12, or use the Chrome menu, then More tools, then Developer tools.

If the panel is cramped, use the three-dot menu in DevTools to change the dock side (right, bottom, left, or a separate window). If a panel you expect is missing, widen the window or click the » overflow button on the tab bar.

What each panel is for

Panel	Use it to
Elements	Inspect and edit the live DOM and CSS
Console	Read logged messages and errors, run JavaScript
Sources	Debug JavaScript with breakpoints, run snippets, save local edits
Network	See every request, its timing, headers and response
Performance	Record what the browser does and find slow load or runtime work
Memory	Find memory leaks
Application	Inspect local storage, cookies, IndexedDB and service workers
Lighthouse	Audit performance, accessibility, best practices and SEO
Recorder	Record, replay and measure user flows

DevTools in Chrome also include an AI assistance feature that can explain styles and errors. It is separate from the panels above; see Chrome’s DevTools documentation for how it handles your data before turning it on.

Elements: inspect and change HTML and CSS

The Elements panel shows the page as the browser currently holds it (the DOM), not the original source file. That difference matters: if JavaScript adds a node, you will see it here but not in “View page source”.

1. Right-click the thing you care about and choose Inspect.
2. In the Styles pane on the right, each rule is listed with the file and line it came from. Rules that lost the cascade are struck through, which answers “why isn’t my CSS applying?” in seconds.
3. Click a value to edit it, or tick and untick the checkbox beside a declaration to switch it off. Changes apply instantly.
4. Double-click text or a tag name in the tree to edit it. To change a larger piece, right-click the node and choose Edit as HTML.
5. The Computed tab and the box-model diagram show the final size, margin and padding the browser used.

All of this changes only your copy of the page in memory. Reload and it is gone. Once something looks right, copy the change back into your source files. If you edit a file under Sources with a Workspace set up, DevTools can save to disk, but do that deliberately.

Common mistake: fixing a style in DevTools, forgetting to copy it back, and then wondering why production still looks wrong.

Console: errors and quick experiments

The Console shows errors, warnings and anything your code logs, and it lets you type JavaScript against the current page. A red error line includes a link to the file and line number; click it to jump to the code in Sources.

Beyond console.log, these save time:

• console.table(rows) prints an array of objects as a table.
• console.error and console.warn style the output so it stands out from normal logs.
• console.group and console.groupEnd nest related logs.
• $0 is the element currently selected in Elements, so $0.textContent works without writing a selector.
• The filter box and log-level dropdown hide noise so you can find one message.

Logging is fine for quick checks. For anything with a loop or state that changes over time, a breakpoint is usually faster, because you can see every variable at once instead of guessing which one to print.

If you are new to JavaScript errors, the lessons on syntax errors and name errors explain the two messages you will meet most often in this panel.

Sources: debug with breakpoints

A breakpoint pauses your code on a line so you can look around. Here is a small bug that looks harmless:

const cart = [
  { name: "Book", price: 12, qty: 2 },
  { name: "Pen", price: "3", qty: 5 },
];
let t2 = 0;
for (const item of cart) { t2 = t2 + item.price; }
console.log(t2);

Expected: 15. Actual output: 123. The second price is the string "3", so 12 + "3" becomes the string "123". Here is how to find that with DevTools instead of guesswork:

1. Open Sources and pick your script in the Page file tree (or press Ctrl + P / Cmd + P and type its name).
2. Click the line number of t2 = t2 + item.price to set a breakpoint.
3. Reload or trigger the code. Execution stops on that line.
4. Look at the Scope pane. On the second pass you will see t2: 12 and item.price: "3", with the quotes showing it is a string.
5. Use Step over next function call to run one line, Step into next function call to enter a function, and Resume script execution to continue to the next breakpoint.

Other tools in the same panel:

• Watch: add an expression such as typeof item.price and see its value update as you step.
• Call stack: shows how you got here; click a frame to inspect variables in the caller.
• Conditional breakpoint: right-click a line number and add a condition like item.qty > 4 so you pause only on the case you care about. A logpoint prints a message instead of pausing, which replaces a temporary console.log you would have to delete later.
• Event listener breakpoints: pause when a click, key press or timer fires, useful when you cannot find which handler runs.
• Pause on exceptions: stop at the line that throws, not where the error eventually surfaces.

While paused, the Console runs in the paused scope, so you can type Number(item.price) and test a fix before editing the file. For a broader method of working through bugs, see how to debug like a pro, and for the same ideas in an editor, how to use debuggers and IDE tools.

Network: see what the page requests

Open the Network panel, then reload the page. DevTools only records while it is open, so open it first. Each row is one request.

• Filter by type (Fetch/XHR, JS, CSS, Img) with the buttons, or type text in the filter box. -main.css hides a file, and domain:example.com keeps one domain.
• Click a request to see Headers (status code, request and response headers), Preview and Response (the body), Initiator (what triggered it) and Timing (where the time went).
• Use the Throttling dropdown (default “No throttling”) to simulate a slower connection such as 3G, then reload.
• Long-press the reload button and choose Empty cache and hard reload to see what a first-time visitor downloads. Ticking Disable cache does the same while DevTools is open.

Typical findings: an API call returning 404 or 500, a request that never fires because of a bug in your code, an image far larger than it is displayed, or a script that blocks everything else while it downloads.

Performance: find slow load and runtime work

1. Open the page in an Incognito window so extensions do not skew the numbers.
2. Open Performance. Under capture settings, set CPU throttling (4x slowdown is a reasonable start; higher values approximate low-end phones).
3. Click Record, do the thing that feels slow (scroll, click, load), then click Stop.
4. Read the result: the overview charts show frame rate, CPU and network. The Main flame chart shows main-thread work with time on the horizontal axis and the call stack going down. Red markers flag long tasks. Click an event and the Summary tab names it and links to the code responsible.

The question to ask is: what is occupying the main thread while the page feels stuck? Usually it is one long JavaScript task, repeated layout, or a large rendering job. Fix the biggest block first and record again to confirm it shrank. The Performance panel in recent Chrome versions also surfaces Core Web Vitals and suggested insights; the docs on analyzing runtime performance cover them.

Lighthouse: a quick audit

The Lighthouse panel runs an automated audit and scores Performance, Accessibility, Best Practices and SEO, each with a list of specific issues. Choose a device type (mobile or desktop) and categories, then run it. The default Navigation mode audits a fresh page load; Timespan audits while you interact; Snapshot audits the page as it is now.

Treat the scores as a checklist, not a goal. Your machine, extensions and cached data all change the numbers, and Chrome’s own docs say results from different machines cannot be compared directly. For performance problems, Chrome recommends the Performance panel for detail; Lighthouse is most useful for accessibility, SEO and best-practice checks.

Application and Memory, briefly

Use Application to look at local storage, session storage, cookies and IndexedDB, and to clear them when a bug only happens for a returning visitor. It also shows service workers. Use Memory when a page gets slower and heavier the longer it stays open: take heap snapshots before and after an action and compare what was kept alive.

A simple workflow

1. Console shows an error: click the link to the line.
2. Nothing in the Console, but wrong data: check Network for the request and its response.
3. Wrong layout or style: select the element and read Styles and Computed.
4. Wrong logic: set a breakpoint and read Scope.
5. Feels slow: record in Performance, then compare after a fix.

Reproduce the problem reliably first; a bug you can trigger on demand is a bug you can step through. To practice JavaScript with instant feedback, the lessons on printing to the console are a gentle start, and the full Chrome DevTools documentation covers every feature above in depth.

Frequently asked questions

What are DevTools?

Debugging and inspection tools built into the browser. They show the page’s live HTML and CSS, run JavaScript, pause code, log network requests and record performance.

How do I open DevTools in Chrome?

Press F12 or Ctrl + Shift + I (Cmd + Option + I on Mac), or right-click and choose Inspect.

Do changes I make in DevTools save?

No. Edits to HTML and CSS affect only the open page and vanish on reload, unless you set up a Workspace to save edits to local files.

How do I use DevTools to check page speed?

Use Network to see what loads and how large it is, Performance to find slow main-thread work, and Lighthouse for a quick scored audit.