Live Preview serves your static pages from a VS Code workspace

A static server rooted at the workspace

Live Preview is a VS Code extension that hosts a local server for you to preview your web projects on. The key word is local, and the second key word is workspace. The server is hosted from the root of the workspace you have open, or from a subfolder of it if the livePreview.serverRoot setting points elsewhere, and it serves the files inside that tree. That is the whole product. There is no build step, no bundler and no framework integration, because the extension is not trying to be one. The documentation is explicit about who should use it: it is most useful for projects where a server is not already created, and it names apps built with React or Angular as the counterexample, pointing those users at the integrated browser in VS Code instead. The reason is obvious once stated. A React application needs a dev server to transform JSX, and this extension does not provide one, so running it against such a project gives you a broken page rather than a preview.

The embedded browser, and how a page gets opened

Previewing starts from the editor. You can preview an HTML file quickly by clicking the preview button in the top right corner of your editor or using the context menu, and the page opens in an embedded browser inside VS Code. The embedded browser is not a stripped down viewer. It tracks page history, it has a URL bar for address-based navigation, and it has an expandable menu that lets you preview the current page in your own browser, perform a page search with the find box also reachable through CTRL and F and Enter for the next result, and open the editor's webview DevTools. The DevTools entry is the part that surprises people, because a webview normally looks like a sealed iframe. Here you can inspect the DOM and see console output while the page is served from the local server. When previewing in VS Code's Integrated Browser you can open Developer Tools from the browser toolbar to view console messages, and the legacy embedded preview still provides an Embedded Live Preview Console channel in the Output tab, which is created only when the legacy preview is opened, for instance when livePreview.useIntegratedBrowser is disabled or the Integrated Browser is unavailable.

Live refresh, and the opt-out attribute on a body tag

The refresh behaviour is configurable and the default is the aggressive one. By default, changes appear as you make them in the editor, and the livePreview.autoRefreshPreview setting lets you change that to refresh on save or not at all. There is also a per-page opt-out that is worth knowing about, because it solves a specific problem: an individual page can opt out of live refreshing by adding the data-server-no-reload attribute to its body tag. The naming makes the mechanism clear, since the extension watches the server and reloads the client when a file changes, and the attribute tells it to leave that one page alone. That is useful for a page with unsaved state in the browser, such as a form the user is halfway through filling in, where a reload throws the input away. It is also a good demonstration of the extension being designed around real editing workflows rather than a blanket file watcher.

External browser preview and js-debug breakpoints

The same features are available in an external browser, and the preview target is editable in the extension settings, so you can choose between the embedded view and a real browser window. The external preview supports debugging via the built-in js-debug extension and by attaching to the Edge Devtools Extension, which allows features such as setting breakpoints and inspecting elements. You trigger it with the Live Preview: Show Debug Preview command in the command palette. The distinction here matters for how you work. The embedded browser is fast and self-contained, and its DevTools are the editor's webview DevTools. The external browser is slower to set up but it is a real browser with real debugging, so if you are chasing a layout bug that only appears in Chromium outside the webview, the external path is the one that reproduces it. Both paths serve the same local server, so the page you are debugging is the page you are editing.

Persistent server tasks and traffic logging

If you want a long-lived server rather than a preview that comes and goes, the extension offers a Live Preview task, which also logs the server traffic, and it can be launched with the Live Preview: Start Server command. The logging is not just console output. You can click on a logged entry to open the file location of the file the server returned, which turns a wall of request lines into a navigable map of what the page actually asked for. That is the feature that turns this from a convenience into a debugging aid, because a broken asset path shows up as a request you can click through to the file. The task type is registered in the extension manifest as a task type, and the extension activates on that task type as well as on the webview panel, so a task that is already configured in your workspace will start the server without opening a preview at all.

Workspace-less previewing and multi-root behaviour

Two structural behaviours are documented, and both have consequences. The first is workspace-less use. You can preview a file with no workspace open, and the server will access files outside your workspace, but files without a workspace are served on their own server instance and use their absolute path as the file path. Linked files for those pages may not be correct if they are relative to a specific root, for example a project root, and tasks do not work outside of a workspace, so the server just launches in the background upon external preview and you use the Live Preview: Stop Server command to kill it. The second is multi-root. Live Preview works with multi-root workspaces and simply opens an additional server for each root that you open a preview on. You can see which ports are open for Live Preview by hovering the status bar indicator, usually in the bottom-right corner of the window. The practical implication is that each preview target gets its own server and its own port, so if you are debugging a multi-root project you need to check the status bar to know which port to open.

The server root warning, and what it means for your links

The most common complaint the documentation addresses is the message about previewing a file that is not a child of the server root. It appears in one of three situations: you have no workspace open and opened a preview, you opened a preview for a file that is not part of your workspace, or you have the livePreview.serverRoot setting set to a subfolder in your workspace and your file is not a child of that subfolder. The reason is that the server is hosted from the root of the workspace you open, or from the subfolder based on livePreview.serverRoot, and files outside that can be previewed but some file paths, such as a link to the root, may not go to the right place. The advice given is to open a workspace at the root of the project if you are working on a web project. That is a real limitation rather than a bug, because the server has no way to know what your intended root is when you have not told it. A Codespaces specific note follows, where the embedded preview does not work and you have to open the links that host the forwarded port content by hand before it works.

Packaging, engine requirements and where the extension is published

The extension is published in the Visual Studio Marketplace under the identifier ms-vscode.live-server, with the display name Live Preview and the package name live-server in its manifest. The manifest declares the VS Code engine requirement as ^1.109.0, so the extension needs a recent Visual Studio Code. The version in the manifest is 0.4.20 with preview set to true, and the release list in the project shows the v0.5 builds under date-stamped tags such as v0.5.2026092301 on 2026-09-23 and v0.5.2026091601 on 2026-09-16, with the last push to the repository on 2026-10-19. Two manifest settings are worth a closer look before you install it in a shared environment. The extension declares that untrusted workspaces are not supported, with the description explaining that Live Preview runs a server to host workspace files, and it declares that virtual workspaces are not supported. The reason for the first is the sensible one: opening a server over files from an untrusted workspace means running that content locally. The licence is MIT, so the code can be read, modified and redistributed with attribution, and the repository carries a SECURITY.md alongside the usual contribution and changelog files.

Editorial conclusion

Adopt Live Preview if you are editing static HTML and CSS without a build step, and you want a browser view that refreshes as you type and can attach js-debug breakpoints from inside VS Code. Do not adopt it for a project that already runs its own dev server, since the documentation points those users at the integrated browser in VS Code instead, and do not adopt it in an untrusted workspace, which the extension declares unsupported because it runs a server to host workspace files. Verify two things before you rely on it: that the page you open is a child of the server root, since files outside it preview but with broken relative links, and that livePreview.autoRefreshPreview is set the way you want, since the default refreshes as you make changes rather than on save. The practical first step is to open a workspace at the project root and click the preview button, then check the status bar indicator for the port the server opened.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/vscode-livepreview on GitHub
3. Project website
4. README
5. Releases