Web Visual Editor: a small VS Code extension for editing HTML by clicking

The premise: preview and source in the same window

Web Visual Editor is a Visual Studio Code extension for editing HTML files visually in real time. The model is straightforward. The extension opens a WebView with a preview of the document, you click on an element in that preview, and the corresponding markup in the source editor is selected. The reverse also holds, so a selection made in the text editor shows up as a highlight in the preview, including multiple ranges. The project describes this as visual selections being synchronized with text selections on editor, and vice versa, which is the feature that makes the extension usable rather than a curiosity. Edits in the source editor are reflected on every keystroke, and edits in the WebView are written back to the source instantly, so the two views never drift apart. The extension is categorised as a Visualization extension and is published in the marketplace under the Urin publisher.

What you can do inside the preview

The editing operations available in the WebView are the ones you would expect from a visual editor, and they are written back to the file rather than applied to a live DOM. You can select HTML elements, copy or cut them, paste text or HTML into a selected element, and delete the selected elements from the source. Every edit made via the WebView is undoable and redoable, which is the detail that decides whether such a tool is usable in a real file rather than a toy. There is also zoom in and out for the page, and drag to move, which rewrites the position of the element rather than the order of elements in the markup. Copy and cut work on the source text of the selected elements, the same range that is highlighted in the source editor, so what you paste elsewhere is the markup rather than a rendering of it.

Paste inserts before the closing tag, and reformats

Paste has a defined insertion point and a defined escaping rule, and both matter if you use it. The inserted content goes just before the closing tag of the last selected element, or before the body tag if nothing is selected. If the clipboard contains valid HTML it is inserted as-is, and plain text is HTML-escaped first, so pasting a snippet of markup works and pasting a fragment of prose does not break the document. The inserted range is then reformatted by the HTML formatter that VS Code already ships with. The project also documents a multi-selection behaviour: Ctrl+Click adds or removes an element from the current selection, and selections made in the source editor, including multiple ranges, are also reflected in the WebView. That last point is what makes it possible to align a source range with what you see.

Moving elements has three conditions attached

Drag to move and keyboard nudge are behind a setting, and they only apply to elements that satisfy a set of conditions, which is sensible because moving an element means rewriting its position and the result has to stay reversible and predictable. An element is draggable when all of the following are true. Its position is not static or sticky. Its left and right are not both set simultaneously, and the same applies to top and bottom. And any explicitly set position value uses px units, since other units such as percent, em and rem make the element non-movable. The reason for the px restriction is that a position expressed in a relative unit cannot be converted into an absolute offset without knowing the containing block, so the extension declines to guess. There is also a formatting caveat worth heeding: when the setting is enabled, moving an element rewrites its tag using the HTML formatting, and to avoid inconsistent indentation the project advises formatting the entire document before starting visual editing, with Shift+Alt+F.

Scripts are off by default, and that is the point

The webVisualEditor.allowScript setting controls whether script tags and on* event attributes are allowed to run inside the WebView, and the default is false. That default is the most interesting design decision in the extension, because a preview that executes the document's own JavaScript is a preview that can run arbitrary code in the context of your page, and a visual editor is often opened on a file you have just written and not yet trusted. With scripts disabled, the preview is inert and the editing operations are still available. The price is that a page which needs JavaScript to render will not render fully, which is exactly why there is a globalScripts setting to inject scripts you choose yourself. The setting webVisualEditor.globalScripts lists scripts to inject into all HTML pages in the preview, and each entry is either a URL or a local path, and it takes effect only when allowScript is true. The documentation gives this configuration as an example.

// settings.json
{
  "webVisualEditor.allowScript": true,
  "webVisualEditor.globalScripts": [
    "https://cdn.tailwindcss.com",  // CDN URL
    "/scripts/inject.js"             // root-relative path
  ]
}

Local script files are tracked, so saving them refreshes the preview automatically.

Root-relative paths and the limits of the setting

The webVisualEditor.rootPath setting defines the root directory for resolving root-relative paths such as /styles/main.css, is specified as a path relative to the workspace root, must be inside the workspace, and defaults to the workspace root. The limitation on absolute paths is stated with a good reason: since both absolute paths and root-relative paths begin with a slash on Unix-like systems, they cannot be distinguished, so a path starting with a slash is always interpreted as root-relative. That also means the same setting governs the root-relative entries in globalScripts, which the documentation says are resolved using rootPath. The must be inside the workspace constraint is the other half of the design, since the WebView reads files from disk relative to the workspace and the extension has no business resolving paths outside it.

Live resource updates, and why the extension is so small

CSS, images and other files referenced by relative path are tracked, and the WebView refreshes automatically when any of them is saved, so a change to a stylesheet shows up without reloading the preview by hand. The interesting claim in the project is not about the feature list but about the implementation. The extension is described as similar to microsoft/vscode-livepreview, and the differences it lists are the ability to synchronize code selection with visual selection in the preview, the fact that Web Visual Editor has minimal functionality so the codebase is very small and future expansions are easy, and the design intent of reflecting changes made in the preview back to the code, which means enhancing the editing capabilities within the preview may be beneficial later. The package manifest backs the smallness claim: the runtime dependencies are he for HTML entity handling and jsdom for parsing, and nothing else. It is built with esbuild and TypeScript, requires VS Code 1.99.0 and Node 25.0.0 or newer, and the compile script runs a type check, then eslint, then the esbuild bundle.

Where it sits, and what to check first

The extension is published on the Visual Studio Marketplace, and the repository is MIT licensed. The release history shows v0.1.17 on 2026-07-19, v0.1.16 on 2026-06-21 and v0.1.15 on 2026-06-19, and the last push to the repository was on 2026-07-19, so the version numbering is still in the zero point one range and the extension is young. The feature set is correspondingly narrow, and the project says so rather than pretending otherwise. What the extension is good at is the class of edit that is faster to do by pointing than by typing: selecting the wrong nesting, moving a positioned block, pasting a fragment into the right place, deleting a wrapper. What it cannot do is anything about styling, layout systems or responsive design, and the px-only rule on moving elements is a reminder of how much of a design tool this is not. The alternative to compare it with is microsoft/vscode-livepreview, which the project names as the similar extension and contrasts on selection sync and on code size.

Editorial conclusion

Web Visual Editor fits a developer who knows HTML but does not want to leave the editor to fix a nesting mistake, or who wants to try a layout change by dragging rather than by guessing at CSS, and it fits anyone who prefers a small readable extension over a large one. It does not fit a project that needs a full design tool, since the project's own comparison with microsoft/vscode-livepreview describes this one as having minimal functionality, and it does not fit a codebase that relies on script-driven behaviour, because scripts are blocked by default and enabling them is a separate decision. Before you rely on it, read the movable element conditions, because an element is only draggable when its position is not static or sticky, when left and right are not both set, and when any explicit position value uses px units, and format the whole document before you start editing visually, since moving an element rewrites its tag using the HTML formatter.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. urin/vscode-web-visual-editor on GitHub