vscode-chrome-debug 0,2 travis-ci gulp npm

Debug your JavaScript code running in Google Chrome from VS Code.

2 years after

VS Code - Debugger for Chrome

Debug your JavaScript code running in Google Chrome from VS Code.

Travis Release Release

A VS Code extension to debug your JavaScript code in the Google Chrome browser, or other targets that support the Chrome Debugging Protocol.


Supported features

  • Setting breakpoints, including in source files when source maps are enabled
  • Stepping, including with the buttons on the Chrome page
  • The Locals pane
  • Debugging eval scripts, script tags, and scripts that are added dynamically
  • Watches
  • Console

Unsupported scenarios

  • Debugging web workers
  • Any features that aren't script debugging.

Getting Started

To use this extension, you must first open the folder containing the project you want to work on.

Using the debugger

When your launch config is set up, you can debug your project! Pick a launch config from the dropdown on the Debug pane in Code. Press the play button or F5 to start.


The extension operates in two modes - it can launch an instance of Chrome navigated to your app, or it can attach to a running instance of Chrome. Just like when using the Node debugger, you configure these modes with a .vscode/launch.json file in the root directory of your project. You can create this file manually, or Code will create one for you if you try to run your project, and it doesn't exist yet.


Two example launch.json configs. You must specify either file or url to launch Chrome against a local file or a url. If you use a url, set webRoot to the directory that files are served from. This can be either an absolute path or a path relative to the workspace (the folder open in Code). It's used to resolve urls (like "http://localhost/app.js") to a file on disk (like "/users/me/project/app.js"), so be careful that it's set correctly.

    "version": "0.1.0",
    "configurations": [
            "name": "Launch localhost with sourcemaps",
            "type": "chrome",
            "request": "launch",
            "url": "http://localhost/mypage.html",
            "webRoot": "${workspaceRoot}/app/files",
            "sourceMaps": true
            "name": "Launch index.html (without sourcemaps)",
            "type": "chrome",
            "request": "launch",
            "file": "${workspaceRoot}/index.html"

If you want to use a different installation of Chrome, you can also set the "runtimeExecutable" field with a path to the Chrome app.


You must launch Chrome with remote debugging enabled in order for the extension to attach to it.


  • Right click the Chrome shortcut, and select properties
  • In the "target" field, append --remote-debugging-port=9222
  • Or in a command prompt, execute <path to chrome>/chrome.exe --remote-debugging-port=9222


  • In a terminal, execute /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222


  • In a terminal, launch google-chrome --remote-debugging-port=9222

Launch Chrome and navigate to your page.

An example launch.json config.

    "version": "0.1.0",
    "configurations": [
            "name": "Attach with sourcemaps",
            "type": "chrome",
            "request": "attach",
            "port": 9222,
            "sourceMaps": true,
            "url": "<url of the open browser tab, you wanna connect to"
            "name": "Attach to url with files served from ./out",
            "type": "chrome",
            "request": "attach",
            "port": 9222,
            "url": "<url of the open browser tab, you wanna connect to",
            "webRoot": "${workspaceRoot}/out"

Other targets

You can also theoretically attach to other targets that support the same Chrome Debugging protocol, such as Electron or Cordova. These aren't officially supported, but should work with basically the same steps. You can use a launch config by setting "runtimeExecutable" to a program or script to launch, or an attach config to attach to a process that's already running. If Code can't find the target, you can always verify that it is actually available by navigating to http://localhost:<port>/json in a browser. If you get a response with a bunch of JSON, and can find your target page in that JSON, then the target should be available to this extension.


See our wiki page for some configured example apps: Examples

Other optional launch config fields

  • diagnosticLogging: When true, the adapter logs its own diagnostic info to the console, and to this file: ~/.vscode/extensions/msjsdiag.debugger-for-chrome/vscode-chrome-debug.txt. This is often useful info to include when filing an issue on GitHub.
  • runtimeExecutable: Workspace relative or absolute path to the runtime executable to be used. If not specified, Chrome will be used from the default install location
  • runtimeArgs: Optional arguments passed to the runtime executable
  • userDataDir: Can be set to a temp directory, then Chrome will use that directory as the user profile directory. If Chrome is already running when you start debugging with a launch config, then the new instance won't start in remote debugging mode. If you don't want to close the original instance, you can set this property and the new instance will correctly be in remote debugging mode.
  • url: Required for a 'launch' config. For an attach config, the debugger will search for a tab that has that URL. It can also contain wildcards, for example, "localhost:*/app" will match either "http://localhost:123/app" or "http://localhost:456/app", but not "http://stackoverflow.com".
  • sourceMapPathOverrides: A mapping of source paths from the sourcemap, to the locations of these sources on disk. Useful when the sourcemap isn't accurate or can't be fixed during the build process. The left hand side of the mapping is a pattern that can contain a wildcard, and will be tested against the sourceRoot + sources entry in the source map. If it matches, the source file will be resolved to the path on the right hand side, which should be an absolute path to the source file on disk. A couple mappings are applied by default, corresponding to the default configs for Webpack and Meteor -
    "sourceMapPathOverrides": {
    "webpack:///*": "${webRoot}/*", // Example: "webpack:///src/app.js" -> "/users/me/project/src/app.js"

Related Repositories



:tada: An Angular Starter kit featuring Angular 4 (Router, Http, Forms, Services ...



:tada: An Angular Starter kit featuring Angular 4 (Router, Http, Forms, Services ...



Awesome tooling and resources in the Chrome DevTools ecosystem ...



VSCode extension for react native - supports syntax highlighting, debugging and ...



A curated list of delightful VS Code packages and resources. ...

Top Contributors

roblourens auchenberg jalissia marvinhagemeister MSLaguana lijunle justsml isidorn Tyriar nojvek MartinMa msftgits octref gitter-badger basteln3rk empoman


package version
vscode-chrome-debug-core 3.16.4
vscode-debugadapter ^1.22.0
dev @types/mocha ^2.2.35
@types/mockery ^1.4.29
@types/node ^6.0.41
@types/source-map ^0.1.27
@types/tmp 0.0.32
concurrently ^3.1.0
glob ^7.1.1
gulp ^3.9.1
http-server ^0.9.0
mocha ^3.0.2
mockery ^1.7.0
tmp 0.0.31
ts-loader ^1.0.0
tslint ^3.15.1
typemoq ^0.3.3
typescript ^2.4.1
vscode ^1.0.3
vscode-chrome-debug-core-testsupport ^3.14.5
vscode-debugadapter-testsupport 1.19.0
vscode-debugprotocol ^1.22.0
webpack ^2.2.0-rc.1
webpack-fail-plugin ^1.0.5


-   v1.1.0 zip tar
-   v1.0.0 zip tar
-   v0.5.2 zip tar
-   v0.5.1 zip tar
-   v0.5.0 zip tar
-   v0.4.7 zip tar
-   v0.4.6 zip tar
-   v0.4.5 zip tar
-   v0.4.2 zip tar
-   v0.4.1 zip tar
-   v0.4.0 zip tar
-   v0.3.6 zip tar
-   v0.3.5 zip tar
-   v0.3.4 zip tar
-   v0.3.3 zip tar
-   v0.3.2 zip tar
-   v0.3.0 zip tar
-   v0.2.5 zip tar
-   v0.2.4 zip tar
-   v0.2.3 zip tar
-   v0.2.2 zip tar
-   v0.2.1 zip tar
-   v0.2.0 zip tar
-   v0.1.12 zip tar
-   v0.1.11 zip tar
-   v0.1.10 zip tar
-   v0.1.9 zip tar
-   v0.1.8 zip tar
-   v0.1.7 zip tar
-   v0.1.6 zip tar