Debugging JavaScript with Google Chrome DevTools and Visual Studio Code

PostedDecember 12, 2019 5.2k views DevelopmentVS Code

While this tutorial has content that we believe is of great benefit to our community, we have not yet tested or edited it to ensure you have an error-free learning experience. It's on our list, and we're working on it! You can help us out by using the "report an issue" button at the bottom of the tutorial.


Learning to debug is an essential skill for developers, allowing them to quickly and efficiently fix errors during development. But how to use debugging tools is not always obvious when working with JavaScript outside of a full-fledged Integrated Developer Environment (IDE). This tutorial will take a look at getting started debugging JavaScript with the Google Chrome DevTools, as well as with the popular text editor Visual Studio Code.

In this tutorial, we will:

  • Open the ‘Sources’ tab in Google Chrome
  • Inspect our code
  • Set breakpoints, inspect variables, etc. in Chrome
  • Download the Debugger for Chrome extension for Visual Studio Code
  • Create our Debug configuration
  • Launch our Debug configuration
  • Set breakpoints, inspect variables, etc. in Visual Studio Code


For this article, we’re going to be debugging an application called 'Quick Chat’.

Landing page for the Quick Chat test application

While it is not required for you to run the same application, you can build the application yourself or clone the source code if you choose.

Whatever project you decide to run, you’ll need to start it up. You can serve your application from Node, or from the Live Server extension for a static site. If you’re new to the Live Server extension, check out this getting started video.

In this project, we’ve added a tiny bug that fails to register who the user is after they’ve logged in. The app incorrectly grabs the user’s username by referencing usernameInput.text instead of usernameInput.value. We will use this to practice debugging.

Debugging Basics

Let’s start with the basics. The idea of debugging is being able to (conditionally) trigger what are called breakpoints to pause the execution of your code. This provides you with the opportunity to look at the state of your application by taking an action such as inspecting variables. You can even take it a step further and 'watch’ variables of your choosing, so that whenever your application gets paused, you can inspect them specifically.

After triggering a breakpoint, you will typically have the following options:

  • Continue the execution of your program.
  • Step through your code line by line.
  • Step out of the current function that you are in.
  • Step into the next function call.

You’ll additionally have access to view the call stack. In other words, as functions call other functions in your program, you can inspect the history of those function calls.

Debugging in Google Chrome

To get started with debugging in Chrome, add a debugger statement to the application as shown in the following loginBtn click event handler:

Code screenshot with a debugger statement

When this statement is reached, your application will be paused and the debug tools will automatically be activated. Noticed how the application is grayed out to signify that it has been stopped. Notice also how the Sources tab in Chrome DevTools has popped up:

Quick Chat app paused, with debugger view in Chrome DevTools

Let’s breakdown what we’re seeing.

Source Code

The first thing you might notice is what appears to be a copy of your code. This is the code that the browser has loaded and is running as your application. You can also see that the debugger line is highlighted a blue color to let us know that this is where our application has been paused:

Debugger line highlighted in Chrome DevTools

Chrome gives you the ability to view this code for a reason. With the code in front of you, you can now set breakpoints. A breakpoint is an intentional stopping or pausing place in a program. The debugger statement we used above functions as a breakpoint, but isn’t necessarily picked up by Chrome as one.

To add a breakpoint, click in the gutter, or empty space, to the left of the line numbers. As you do, notice that Chrome now adds this breakpoint to the list of breakpoints further down.

List of Breakpoints in Chrome DevTools


In the scope tab, you have the ability to inspect variables in your application. You’ll notice there is a local section (local scope to the function where the breakpoint is), a global section (the global scope), and a scripts section. In the scripts section, you can view variables within the scope of the current script:

Scripts section of Chrome DevTools

This is where a significant amount of your debugging time will be spent. This is a much more efficient replacement for writing out many console.log() statements.


In addition to viewing variables in the scope tab, you can also define variables that you want to look into specifically. By adding a variable to the watch tab, each time you hit a breakpoint, you can quickly find the value of that variable (which may be undefined depending on where you are in the code). Hit the add icon and enter the name of the variable you want to track, in this case, usernameInput.

Watch tab in Chrome DevTools

Step Functions, Call Stack, and Breakpoints List

The last section, located in the bottom left of the Sources tab in this configuration, will allow you to view the list of breakpoints, call stack, etc.

Call stack and breakpoints tabs in Chrome DevTools

In the call stack above, there is one function listed that is the event handler for my login button. This function is listed because it is the only function that has been called so far. As functions call more functions, that chain will be updated appropriately.

Notice also the arrow buttons at the top of this screenshot. These correspond to the functions referenced for continuing execution of your code or stepping through it line by line or by function. Test these buttons a bit to get used to how you navigate the execution of your code.

Lastly, there are different kinds of breakpoints that can be set. Let’s take a look at creating a conditional breakpoint, one that will only get triggered if a certain condition is met. For example, let’s say we want to break on the login button callback only when the user attempted to log in without entering a username. We can do this, by right-clicking in the gutter and choosing conditional breakpoint with the following condition, usernameInput.text === ''.

Setting up a conditional breakpoint in Chrome DevTools

In the case of debugging Quick Chat, if you press the login button without entering a username, this breakpoint will be triggered. Otherwise code will continue to execute as normal.

Note that there are even more breakpoint options available that are not covered here.

Debugging in VS Code

As you’ve seen so far, the Chrome Developer Tools offer a great experience to debug your application with lots of functionality. However, Visual Studio Code in many ways has matching debugging functionality integrated more seamlessly into your environment.

To get started debugging in VS Code, install the Debugger for Chrome extension:

Debugger for Chrome extension in Visual Studio Code

Let’s take a quick look at the Debug tab in the sidebar (on the left side of your editor by default). Open the debug tab by clicking on the icon that looks like a bug. With this pane open, you will see similar tools to what we saw in Chrome: variables, watch, call stack, and breakpoints.

Variables, watch, call stack, and breakpoint tabs from Chrome DevTools rendered in Visual Studio Code

The majority of the functionality that you get in Chrome Dev Tools is available right here inside of VS Code.

Now that you’ve seen the Debug tab, create a launch configuration that tells VS Code how to debug your application. VS Code stores debug configurations in a file called launch.json inside of a folder named .vscode. To have VS Code create this file for us, click on the 'No Configurations’ dropdown and choose 'Add Configuration’.

Add Configuration option in Visual Studio Code

Then choose 'Chrome’:

Chrome Environment option in Visual Studio Code

Choose the 'Chrome: Launch’ configuration from the popup dropdown list:

Chrome: Launch option in Visual Studio Code

The specific configuration that we created will automatically attach to the application at the defined port. We need to make one small change to this configuration to correctly point to the source code for the app. The source code is located in the public directory, which is why we have updated the 'webRoot’ property.

Note: Keep in mind that your application must already be running locally at a certain port for this to work.

webRoot property setting in Visual Studio Code

With the configuration defined, you can now start your debug session by clicking the green play button. Your application will pop up in a Chrome window. Also, notice the debug menu bar that popped up in the background inside of VS Code. With this debug toolbar, you can pause, restart, continue, and use step functions to navigate your code and interact with the debugger.

With debugging connected, you can set a breakpoint in the code, just like we did in Chrome. Click in the 'gutter’ next to the line number. Let’s keep our breakpoint in the same location as before, just inside the login event callback.

Now, when trying to log in without entering a username, the breakpoint will trigger switching the context back to VS Code for further investigation.

Debugger switching from Chrome back to Visual Studio Code

From here, the functionality that we discussed in Chrome maps over directly to VS Code. If you want to add a conditional breakpoint, right-click in the gutter and choose 'conditional breakpoint’ with some condition. If you want to watch a variable, click to add a new one, and type the name of the variable to watch. If you want to explore variables, go to the variables tab.


Taking the next step as a developer taking advantage of the ecosystem of tools that your language lives in. Debugging is one of those topics that takes some time and effort to get started with, but ultimately the benefit will outweigh the cost.


Creative Commons License