# Edge DevTools in VS Code attaches a real browser to your source tree > The Microsoft Edge Tools for VS Code extension embeds the Edge Developer Tools in the editor, connecting to a real Microsoft Edge instance so you can change CSS, run diagnostics and debug with the Styles tool synced back to your source through sourcemaps, which is what makes it usable with Sass and React. It needs Edge installed on the machine, and in an untrusted workspace it is limited to a specific set of settings. **microsoft/vscode-edge-devtools** — A VSCode extension that allows you to use browser devtools from within the editor. The devtools will connect to an instance of Microsoft Edge giving you the ability to alter CSS styling, perform diagnostics, and debugging. Get it now at http://aka.ms/devtools-for-code - Repository: https://github.com/microsoft/vscode-edge-devtools - Website: https://docs.microsoft.com/microsoft-edge/visual-studio-code/microsoft-edge-devtools-extension - Stars: 829 · Forks: 361 - Language: TypeScript - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-vscode-edge-devtools ## A browser preview next to the code The Microsoft Edge Tools for VS Code extension allows you to use the Developer Tools of Microsoft Edge inside Visual Studio Code. The extension description is blunter about the mechanism: the devtools connect to an instance of Microsoft Edge, which is what gives you the ability to alter CSS styling, perform diagnostics and debug. That distinction is the whole design. This is not a headless renderer or a DOM inspector that parses your files. It attaches to a browser you can also open yourself, so what you see in the editor is the same page, in the same browser, running the same code. The feature list in the README describes what you get. Live analysis of issues in your source code, so you find out about problems while you develop. A browser preview with a built-in toolbar for device and mode emulation, which is how you check a layout at a phone width without leaving the editor. The Console and Application tools. And breakpoint support. The item that matters most for real projects is the third one: changes in the Styles tool sync live with your source code, including abstractions like Sass and React using sourcemaps. Editing a rule in the browser writes the change back to the file that produced it, rather than to a generated stylesheet, and the examples directory holds a sourcemaps.md document that walks through the mechanism. The package manifest records the shape of the extension too. Its display name is Microsoft Edge Tools for VS Code, the publisher is ms-edgedevtools, the version is 2.1.13, the category is Debuggers, and the extension kind is ui. The engine requirement is a Visual Studio Code version of 1.136.0 or later, and the extension activates on startup finished rather than on a command, so the preview is there when you begin working rather than when you first press a button. ## Sourcemaps are what make the live style editing usable It is easy to read the Styles tool syncing with your source as a convenience and miss that it is the technical centre of the extension. A browser DevTools panel shows CSS rules as the browser sees them after every transformation your build pipeline applies. If your styles are written in Sass, what you see in the panel is the compiled output, and editing it there would change a generated file that your next build overwrites. The same is true for a component framework where the styles you wrote are several steps away from the rule in the panel. Sourcemaps are the mechanism that closes that gap. With a mapping in place, the panel can point at the original source, and an edit lands in the file you actually maintain. The README names Sass and React explicitly as the abstractions it handles, and the examples directory contains a sourcemaps.md document for the setup. That dependency has a consequence worth planning for. The extension is only as good as your build's sourcemap output, so a project with a broken or missing sourcemap configuration will not get the behaviour the feature list promises, and the failure will look like the extension not working rather than like a build problem. The alternative is the workflow this extension is displacing. You can open the Edge DevTools in a separate browser window, with the same tools, and edit styles there. The difference in approach is where the panel lives and where the edits land: the standalone window gives you a full browser next to the editor and no path back to your source, while the extension puts the panel in the editor and can write the change into the file that produced it, at the cost of running inside the editor rather than in a browser you control. ## The preview pane, device emulation and the tools The preview is a real browser surface, and the toolbar in it is what makes the extension usable for front end work rather than just for inspection. The built-in toolbar offers device and mode emulation, so you can change the viewport and the rendering mode of the page from inside the editor and watch your layout respond. For a developer who spends the day in VS Code, that is a short path between a CSS problem and the change that fixes it, and it removes the alt-tab dance of switching to a browser, resizing the window and back. Alongside the preview, the extension ships the Console and Application tools, so runtime logs and storage inspection are available without leaving the editor, and it supports breakpoints, which means the debugging loop does not require a separate window either. Live analysis of issues in your source code completes the picture. The point of bringing the browser into the editor is not the tools themselves, which the standalone DevTools already have, but that the findings arrive where the fix is made. The manifest shows a few of the ways the extension can be configured, with the restricted setting names visible in the capabilities block: vscode-edge-devtools.browserArgs, vscode-edge-devtools.defaultUrl, vscode-edge-devtools.userDataDir, vscode-edge-devtools.hostname and vscode-edge-devtools.port. The browserArgs setting in particular is how you launch a browser with your own flags, which is what a team with a proxy, a debugging profile or a specific user data directory needs. ## Workspace trust limits what the extension can touch The manifest is unusually explicit about untrusted workspaces, and it is the detail most likely to affect how you deploy the extension in a team. The capabilities block marks untrustedWorkspaces as supported, but only in the limited sense, with the description that workspace trust is needed to configure and debug projects. Five settings are listed as restricted configurations: vscode-edge-devtools.browserArgs, vscode-edge-devtools.defaultUrl, vscode-edge-devtools.userDataDir, vscode-edge-devtools.hostname and vscode-edge-devtools.port. Read together, those five names describe the extension's reach. It can launch a browser process, point that browser at a URL, give it a user data directory, and choose a host and a port to connect on. In a folder you have not trusted, each of those is exactly the kind of setting a workspace should not be able to influence, because a project you have just opened is untrusted code by definition, and a settings change there could redirect a browser to an arbitrary address or attach a debugger to an arbitrary local service. Virtual workspaces are marked as false, which is simpler: the extension does not run there at all. The practical consequence for a team is that the extension needs workspace trust to be granted before it can configure and debug a project, and the restricted settings cannot be changed from an untrusted folder. That is a sensible design, and it also means that any onboarding process that opens a repository without trusting it will not get a working preview, which is worth checking before a rollout. ## Installing it and what the machine needs The installation is a marketplace install, and the README is clear that the extension is not self-contained. This extension needs Microsoft Edge to be on your computer. Windows machines already come with it, and for Mac and Linux the README asks you to download and install a version of Edge. The download link given is the developer tools one at aka.ms/devtools-for-code, and the full documentation is on Microsoft Learn at the microsoft-edge path under visual-studio-code. That Edge dependency is the price of the design. The extension is not shipping a browser, it is attaching to one, and the alternative would be either bundling a browser, which changes what the panel shows, or dropping back to a separate window, which is the workflow the extension exists to improve on. For contributors, the repository is a TypeScript project with a webpack build, an ESLint configuration in .eslintrc.mjs, a tsconfig.json, and the usual directories: src for the extension code, test for the tests, build for the build configuration, resources for the extension resources, startpage for the start page, and examples for the documentation such as the sourcemaps walkthrough. There is also a .vscodeignore, which decides what is left out of the packaged extension, and an icon.png with a dark variant. The extension has no GitHub releases, because it ships through the Visual Studio Code marketplace instead, and the CHANGELOG.md in the repository tracks the versions. The last push to the main branch was on 2026-10-16, so the extension is being worked on rather than left as a snapshot. ## Telemetry, consent and the security reporting route Two short sections of the README deal with data and with security, and both are worth reading before a team rolls the extension out. On data, the extension gets data and telemetry from Visual Studio Code which the team uses to improve the product, and the README points at the Visual Studio Code telemetry documentation for how to turn it off. The longer data collection paragraph states that the software may collect information about you and your use of the software and send it to Microsoft, that Microsoft may use it to provide services and improve its products and services, and that your use of the software operates as your consent to these practices. It also notes that some features may enable Microsoft to collect data from users of your applications, in which case you must comply with applicable law, including providing appropriate notices to your users together with a copy of the privacy statement. That last clause is the one that matters beyond this extension. If you enable a feature that collects data from your own users, the notification duty falls on you, and the README says so explicitly. On security, issues and bugs should be reported privately by email to the Microsoft Security Response Center at secure@microsoft.com, with a stated response within 24 hours and a request to follow up by email if no reply arrives. Further information, including the MSRC PGP key, is in the Security TechCenter. Contributions go through a different route. Most contributions require agreeing to a Contributor License Agreement declaring that you have the right to grant the rights to use your contribution, with the details at cla.microsoft.com and the practical steps in CONTRIBUTING.md. ## Conclusion Adopt this extension when you build web front ends in VS Code and want to change styles in the running page while keeping the result in your source files, especially when your styles come from Sass or React and the mapping is done with sourcemaps. Do not adopt it if Microsoft Edge is not on the machine, because the extension drives a real Edge instance rather than an embedded renderer. Before you install, read the workspace trust settings, since the manifest limits the extension in untrusted workspaces and restricts browserArgs, defaultUrl, userDataDir, hostname and port, and check the telemetry statement, because the extension reports usage data through Visual Studio Code and the README describes your use of it as consent to those practices. ## FAQ ### What does the Microsoft Edge Tools for VS Code extension do? It lets you use the Microsoft Edge Developer Tools inside Visual Studio Code, with the devtools connecting to a Microsoft Edge instance so you can alter CSS styling, run diagnostics and debug, and change the page in a preview with device and mode emulation. ### What do I need installed to use the Edge DevTools extension? Microsoft Edge has to be on your computer. Windows machines already come with it, and for Mac and Linux the README asks you to download and install a version of Edge, with a link at aka.ms/devtools-for-code. ### Does the Edge DevTools extension work in an untrusted workspace? Only to a limited extent. The manifest marks untrusted workspaces as supported with a limited description, saying workspace trust is needed to configure and debug projects, and it restricts the browserArgs, defaultUrl, userDataDir, hostname and port settings in that case. Virtual workspaces are not supported. ### How do I report a security issue in the Edge DevTools extension? Privately by email to the Microsoft Security Response Center at secure@microsoft.com, with a stated response within 24 hours and a request to follow up by email if nothing arrives. More information, including the MSRC PGP key, is in the Security TechCenter. ## Sources - [Issues](https://github.com/microsoft/vscode-edge-devtools/issues) - [License: MIT](https://github.com/microsoft/vscode-edge-devtools/blob/main/LICENSE) - [microsoft/vscode-edge-devtools on GitHub](https://github.com/microsoft/vscode-edge-devtools) - [Project website](https://docs.microsoft.com/microsoft-edge/visual-studio-code/microsoft-edge-devtools-extension) - [README](https://github.com/microsoft/vscode-edge-devtools/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-vscode-edge-devtools