# Browser Preview for VS Code: a real Chromium process you can attach a debugger to > Browser Preview for VS Code renders web pages in a headless Chromium process inside the editor and can hand that process to Debugger for Chrome. Its own README tells you to uninstall it in favour of the Live Preview extension, and the manifest still carries Live Share activation events that nobody removed. **auchenberg/vscode-browser-preview** — GitHub describes it as A real browser preview inside your editor that you can debug.. The repository metadata lists TypeScript as its primary language. The metadata lists the MIT license. This article stays within the project description and details documented in the GitHub repository README. - Repository: https://github.com/auchenberg/vscode-browser-preview - Stars: 4,375 · Forks: 152 - Language: TypeScript - License: MIT - Published: 2026-08-13 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/auchenberg-vscode-browser-preview ## A deprecated extension that still launches its own Chromium process Browser Preview for VS Code does not render HTML with a webview the way most editor extensions do. It starts a headless Chromium instance in a new process, and that process can be Google Chrome or Microsoft Edge. The rendering target is therefore a real browser build sitting on your disk, not a bundled renderer, which is the whole reason in-editor debugging is possible at all: breakpoints set in a VS Code debug session land in code running inside that Chrome process. The first line of the README is a deprecation notice. The extension is deprecated in favour of the Live Preview extension, and it states that Live Preview has much of the same functionality, including an embedded preview and external browser debugging, and that you can uninstall or disable this one safely. Issues belong in the microsoft/vscode-livepreview repository from here on. What is left in the marketplace entry is a working implementation whose issue tracker is somewhere else. The repository is not archived, yet it is frozen: the last push was on 2023-04-30 and the newest release, v0.7.2, dates from 2021-09-28. The package version in package.json matches that newest release, and the displayName is literally "[Deprecated] Browser Preview", so the deprecation is baked into the manifest rather than left to the README. The engine floor is `^1.30.0`, which is old enough that the extension was written against a VS Code extension API that has had years of churn since. ## The manifest still registers Live Share commands the deprecation implies nothing about package.json lists twelve activation events. Several are obvious: `onView:targetTree`, `onCommand:browser-preview.openPreview`, `onCommand:browser-preview.openActiveFile`, `onDebugInitialConfigurations`, `onDebug`, and `onFileSystem:vsls`. The rest are Live Share hooks: `onCommand:liveshare.start`, `liveshare.startFromActivityBar`, `liveshare.startReadOnly`, `liveshare.startReadOnlyFromActivityBar`, `liveshare.startReadOnlyFromSessionExplorer`, `liveshare.inviteUserJoin` and `liveshare.inviteUserJoinByEmail`. Read the deprecation notice next to that list and a contradiction shows up. The extension tells you to report bugs elsewhere, yet the manifest still pays activation cost on every Live Share start and invite command. A skim over the README would not catch this, because the README never mentions Live Share at all. Anyone auditing this extension for a locked-down environment should check whether those events force the extension host to load the deprecated bundle on a shared Remote session. Two other layout details are worth a look before adopting. The manifest declares the extension kind as both ui and workspace, so it will load either on the local machine or in the remote workspace depending on where VS Code places it, and a headless Chrome process launched from a remote host is a different security story from one launched on a laptop. The `main` entry is `./build/ext-src/extension.js`, and the tree is split into `ext-src/`, `src/`, `tests/` and `docs/`, with a separate `tsconfig.extension.json` for the extension half. ## browser-preview.startUrl points at the VS Code documentation site out of the box The default value of `browser-preview.startUrl` in package.json is `https://code.visualstudio.com`. That is Microsoft documentation, not a blank page and not your own project, so a fresh install opens the extension pointed at someone else's website. Change it in settings, which is where the README sends you: search for "browser preview" and set the key to the URL you actually want, for example a local development server. The rest of the configuration block is small and every key does one thing: ```json "browser-preview.startUrl": // The default start url for new Browser Preview instances "browser-preview.verbose": false // Enable verbose logging of messages sent between VS Code and Chrome instance "browser-preview.chromeExecutable": // The full path to the executable, including the complete filename of the executable "browser-preview.format": // Option to set the type of rendering with the support for `jpeg` (default one) and `png` formats "browser-preview.ignoreHttpsErrors": false // Ignore HTTPS errors if you are using self-signed SSL certificates ``` Two of those deserve a second look. `browser-preview.verbose` defaults to an empty string even though the type is boolean, which is a small sign of a manifest that stopped being tidied. `browser-preview.ignoreHttpsErrors` exists for exactly one job: reaching a local server behind a self-signed certificate. Turning it on is fine for `localhost` and wrong for anything else, and nothing in the README warns you about the difference. ## jpeg is the default frame format, so the lossy codec is on unless you change it Rendering goes through `browser-preview.format`, which accepts jpeg or png, and the default is the lossy one. A preview is only useful when it looks like the page will look, and jpeg smears text antialiasing, thin 1px borders and flat colour blocks. Switch the setting to the png format before you use the preview to judge typography or a tight grid layout, otherwise you are looking at artefacts the browser never produced. The same section admits several previews open at the same time, and the mechanism line explains what that costs: each preview is its own Chromium process started in a new process. Open enough tabs and you have that many headless Chrome instances, each holding its own memory and its own renderer, on a machine the README assumes already has Chrome installed. The README does not document a process limit, a pool, or a way to shut idle previews down, so the practical ceiling is whatever your machine tolerates. For a closer look at a running instance, the README points at `chrome://inspect` for attaching Chrome DevTools. That path works because the process is real Chrome, which is also the argument for the extension existing at all. ## Debugging needs a second extension and the browser-preview debug type In-editor debugging is not built in. You install Debugger for Chrome (msjsdiag.debugger-for-chrome) separately, then add a launch configuration whose `type` is `browser-preview`. Two entries appear in the README's example, one with `"request": "attach"` named "Browser Preview: Attach" and one with `"request": "launch"`, a `"url"` pointing at `http://localhost:3000`, named "Browser Preview: Launch". Attach for a preview you opened yourself, launch when the debug session should start the page for you. That example carries `"version": "0.1.0"` and a `configurations` array. It is also sixteen lines long and is the configuration the README prints verbatim, so treat the exact shape as something to copy rather than something to paraphrase. Additional supported properties are named in a single sentence: `webRoot`, `pathMapping`, `trace`, `sourceMapPathOverrides` and `urlFilter`, with the README deferring their semantics to the vscode-chrome-debug documentation. The extension reuses that launch vocabulary rather than defining its own. The extension activates on `onDebugInitialConfigurations` and `onDebug`, which is how it can contribute these entries into a freshly created launch.json. The animation referenced under the "Watch It" heading lives in docs/DEBUGGING.md. ## First run is a marketplace install and one command, not a build There is no npm install line, no yarn command and no build step anywhere in the README. Installation happens in the Visual Studio Marketplace, and the entry point after installation is the Browser Preview button in the sidebar on the left, or the command `Browser View: Open Preview`. The one prerequisite the README states plainly: Google Chrome must be installed on your computer. There is no bundled browser download and no message in the docs about what you see when Chrome is missing, so if the preview fails to appear, an absent or oddly located Chrome is the first thing to check. On machines where Chrome lives somewhere the auto-detection does not reach, `browser-preview.chromeExecutable` takes the full path including the complete filename of the executable. A first run that ends well looks like this: you open the sidebar view, a preview pane appears, and the page at your `browser-preview.startUrl` loads. If you kept the default, that page is the VS Code documentation site, which is a useful sanity check. Then change the start URL, open a second preview to confirm multiple views work, and only then wire up the debug configuration, because the debugger needs the preview already open to attach to it. ## Live Preview covers the same ground with a different process model The alternative is named by the project's own README: the Live Preview extension from Microsoft, and the deprecation notice is unambiguous that this is where the functionality moved. The notice claims much of the same functionality, including an embedded preview and external browser debugging, and the README lists microsoft/vscode-livepreview as the place to file issues. That is a different support destination before it is a different feature set. The real difference in approach is the process boundary. Browser Preview hands your machine's own Chrome or Edge to the editor, which is what makes chrome://inspect and a source-mapped debugger work with no abstraction in between, and what makes the machine need a real browser installed. Live Preview is the successor that Microsoft keeps building against a moving extension API and a current engine target. Choosing Browser Preview means choosing an implementation pinned to VS Code `^1.30.0` and Chrome discovery that stopped changing on 2023-04-30; choosing Live Preview means accepting that the successor's own behaviour is the one that gets fixed when something breaks. There is one more difference worth naming: neither the README nor package.json documents auto refresh. Browser Preview opens URLs and starts them; nothing in the configuration block, the debug example or the feature list describes live reload on file save. If your workflow depends on a preview that refreshes itself, verify that behaviour in your own setup before you rely on it, because the documentation is silent. ## Conclusion Adopt it only if you already have a pinned VS Code profile where swapping to Live Preview is a larger change than living with a frozen extension, and only if the browser-preview debug type still resolves in your editor. Skip it for any new setup, because the deprecation notice in the README sends every reported issue to a different repository. Verify first that the sidebar Browser Preview button appears and that Chrome is on the machine, since the extension needs a local Chrome or Edge install rather than a bundled browser. ## FAQ ### How do I install Browser Preview for VS Code? It is installed from the Visual Studio Marketplace; the README gives no npm or build command. After installing, open the Browser Preview button in the sidebar or run the command `Browser View: Open Preview`, and make sure Google Chrome is installed on your machine. ### Why is Browser Preview for VS Code marked deprecated? The README states the extension is deprecated in favour of the Live Preview extension, which it says is under active development and has much of the same functionality, including an embedded preview and external browser debugging. ### How do I change the start page in Browser Preview for VS Code? Open your settings, search for "browser preview" and set `browser-preview.startUrl` to the URL you want. Its default value in package.json is `https://code.visualstudio.com`. ### Can I debug the Browser Preview inside VS Code? Yes, but not on its own. Install Debugger for Chrome (msjsdiag.debugger-for-chrome) and configure a launch entry with `"type": "browser-preview"` and a `request` of either `attach` or `launch`. Optional properties include `webRoot`, `pathMapping`, `trace`, `sourceMapPathOverrides` and `urlFilter`. ### Does Browser Preview for VS Code refresh automatically when I save a file? The README does not document auto refresh. It documents opening URLs, multiple previews at once, and attaching Chrome DevTools via `chrome://inspect`, but no setting in the configuration block turns on reload on save. ## Sources - [Official README](https://github.com/auchenberg/vscode-browser-preview#readme) - [Project repository](https://github.com/auchenberg/vscode-browser-preview) - [Release notes](https://github.com/auchenberg/vscode-browser-preview/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/auchenberg-vscode-browser-preview