 If you're still using console.log to find and fix JavaScript issues, you might be spending more time debugging than you need to. This tutorial shows you how to make the most of Chrome DevTools so that you can debug your JavaScript as quickly as possible. I'm going to use this buggy demo here to demonstrate all of the debugging tools in DevTools. I recommend that you open up this demo yourself and follow along with each step. The link is in the description. Whatever issue you're debugging, you always want to start by reproducing the issue. You want to find a series of actions that consistently reproduces the bug. In this demo, when I add 5 and 1, the result down here at the bottom is 51. Obviously, that should be 6. This is the bug that I need to track down. At this point, you might be tempted to use console.log to infer where the code is going wrong. Sure, it may get the job done, but it's rather inefficient. First, you have to find the relevant code, which could take a while on a big code base. Then you have to sprinkle console.log statements throughout the code. Then you've got to reload the page and look at the logs, but maybe the logs didn't give you all the information you need, so you've got to go back and add more logs, and so on. With DevTools, you can pause the code in the middle of its execution, inspect the variables that are in scope at that moment in time, and walk through your code one line at a time. Open DevTools by pressing Command Option J on Mac or Control Shift J on Windows and Linux. Then click the sources tab. The sources panel is where you debug JavaScript. It has three main parts. At the top left here is the file navigator pane, where you can inspect the files that the page uses. After clicking on a file, you can see the contents of it here in the code editor pane. And down here is the JavaScript debugging pane, which you'll learn more about shortly. Note that when your DevTools window is wide, the JavaScript debugging pane moves to the right. If you take a step back and think about how the app works, it's probably safe to guess that the incorrect sum gets computed in the click event listener that's associated to the button. Therefore, you want to pause the code right when the event listener executes. Event listener breakpoints let you do exactly that. Expand the event listener breakpoint section, then expand the mouse category, then check the click checkbox. DevTools now pauses on the first line of any click event listener that executes. Back in the demo, click the button again, and DevTools pauses on the first line of this on click function. The blue highlight indicates what line of code you're currently paused on. If you're paused on a different line of code, press resume script execution until you're paused on the correct line. You paused on the wrong line because you have a Chrome extension which registers click event listeners on every page that you visit. If you try the workflow I'm describing in an incognito window, you can see that you always pause on the correct line of code. Event listener breakpoints are just one type of breakpoint. DevTools offers many other types. For example, you can set a breakpoint on a specific line of code, or when a DOM node changes, or when an exception gets thrown, and so on. After this tutorial, I recommend checking out our breakpoints guide, which teaches you when and how to use each type. The link to that guide is in the description too. I'm paused in the click listener, and now I want to execute the code one line at a time. The code stepping controls right here let you do that. Click the step into next function call button to investigate a function further. For example, when I step into the inputs are empty function, it jumps me to the first line of that function. When I'm confident that a function is working as expected, I can click the step over next function call button. The function executes, but I don't walk through it line by line. For example, if I click step into next function call, this line here would be highlighted blue, meaning this is where I'm currently paused. But when I click step over next function call, the function executes to completion, and I pause on the next line of the function that I'm currently stepping through. Last, suppose I'm stepping through a function and I realize it's not relevant to my bug. In that case, I can press step out of current function and DevTools executes the rest of the function. If this doesn't make complete sense right now, I recommend creating a snippet, which is a little block of JavaScript code that you can execute at any time. Set a breakpoint in your snippet and play around with the code stepping controls yourself in order to understand how they all work. Back in the script, I can tell that the bug is probably somewhere in the update label function. Rather than stepping through a bunch of irrelevant code, I can set a line of code breakpoint right around where the bug probably occurs. To do that, I just click the line number next to the code. This blue icon indicates that there's a breakpoint on this line. When I press resume script execution, DevTools runs all the code up until that line and then pauses before that line executes. Over here in the JavaScript debugging pane, I can see the call stack that caused this code to execute. I can click on the functions to see where each one got called. The scope section shows me all of the local and global variables that are currently defined at this moment in time. I can click on values to edit them, but I'm not going to do that right now. However, when I look at these values, they look suspicious. They're wrapped in double quotes, which means that they're strings. This could be the cause of the bug. I'm going to investigate this further over in the watch expression section. Here I can watch the values of variables over time. You can store any valid JavaScript expression here. For example, I click add expression, then type type of sum, then press enter, and I can now see the value of that expression. As I suspected, some is a string when it should be an integer. Now I'm going to open up the console to test out a potential fix for the bug. When I'm paused on a line of code, the console has access to all the variables that are currently in scope. For example, when I evaluate add end one, it returns five. I think I can fix this bug by converting the add end one and add end two variables to integers before adding them. So let me try that now. Yep, that fixes it. I can verify that this change fixes the bug by editing the code directly from DevTools. First, I'll resume script execution, then make my change. To save the change, I press command S on Mac or control S on Windows and Linux. Then I click deactivate breakpoints so that I can test out the app without triggering the breakpoints I've set. Now the app sums up numbers as expected. All right, you now have an excellent foundation in how to effectively debug JavaScript using DevTools. From here, I recommend learning about all of the breakpoints that DevTools has to offer, as I mentioned before. We also have a JavaScript debugging reference where you can learn about literally every feature related to debugging in DevTools. Links to both are in the description. Thanks for watching and happy bug hunting.