Visual Studio Code is already a capable web editor, but the right extensions can remove repetitive work without turning your project into a collection of overlapping tools. The useful choices depend on the kind of project you build: a static site needs a preview workflow, a JavaScript project needs linting and formatting, and a Tailwind project needs class-aware editor support.
This guide selects extensions from the official Visual Studio Code Marketplace using practical criteria: a clear web-development job, an official listing, useful documentation, a maintained upstream project or publisher, and a setup that makes sense for an individual developer or small team. It is not a ranking based on download counts or an unperformed benchmark. Marketplace versions and features change, so check the linked listing before installing.
Quick comparison
| Extension | Best for | Main benefit | Important limitation |
|---|---|---|---|
| Prettier – Code formatter | Consistent formatting | Formats supported files using project rules | It formats code; it is not a replacement for a linter |
| ESLint | JavaScript and TypeScript diagnostics | Shows lint problems and can apply safe fixes | Your project still needs an ESLint configuration and package |
| Live Preview | Static HTML and front-end prototypes | Runs a local server and previews changes | It does not provide a production backend or deployment environment |
| GitLens | Understanding Git history | Adds blame, history, and repository context inside VS Code | Some advanced features require a paid plan |
| Tailwind CSS IntelliSense | Tailwind CSS projects | Adds class completion, previews, and diagnostics | It is useful only when the project is detected as Tailwind |
| Error Lens | Seeing diagnostics while editing | Displays errors and warnings beside the relevant code | Inline messages can become noisy in a large project |
All six have free Marketplace listings. GitLens has optional paid features, so review its current plan details if you need more than its free functionality. The other extensions do not remove the need to check their own repository and license terms when your organization has software-supply-chain requirements.
1. Prettier – Code formatter
Prettier – Code formatter is the straightforward choice when a team wants consistent formatting for HTML, CSS, JavaScript, TypeScript, JSON, Markdown, and other supported file types. It connects VS Code to Prettier and can format a file manually or when you save it.
The important setup decision is where the formatting rules live. Prefer a project-local Prettier package and configuration, committed with the project, instead of relying only on a global editor installation. That way, a teammate, a CI job, and your editor can use the same version and rules. The extension's documentation also explains how it loads a locally installed Prettier and how to configure format-on-save.
Use Prettier for layout and style decisions such as indentation, line wrapping, quotes, and trailing commas. Do not ask it to enforce application-specific correctness. ESLint, tests, type checking, and code review still have separate jobs.
Common Prettier mistake
Only one formatter should normally be the default for a language. If ESLint, a framework extension, and Prettier all format the same file on save, the tools can fight over the result. Set Prettier as the default formatter for the languages you intend to format and let ESLint handle lint fixes separately.
Prettier's upstream VS Code project is available on GitHub. Before standardizing on it, check the Marketplace listing's supported VS Code version and the project's current documentation.
2. ESLint
The official ESLint extension integrates ESLint diagnostics into VS Code. It is useful for JavaScript and TypeScript projects where lint rules catch likely mistakes, enforce a team's conventions, or provide fixable code actions as you work.
The extension uses the ESLint library installed in the opened workspace when one is available. Install ESLint as a development dependency and keep the configuration in the repository. A minimal project setup might look like this:
pnpm add --save-dev eslint
The exact configuration depends on your framework, module system, and ESLint version. Use the ESLint documentation and the configuration format already used by your project rather than copying an old .eslintrc example into a flat-config project.
ESLint complements Prettier when the responsibilities are clear. Let Prettier format; let ESLint report code-quality and correctness issues. Some projects intentionally combine them through plugins, but that adds configuration and can produce duplicate diagnostics. Start with separate responsibilities and add integration only when the project has a reason to do so.
When ESLint is not enough
Linting is a fast feedback loop, not proof that a feature works. It will not replace tests, type checking, browser checks, security review, or an accessibility review. Keep those checks in your normal project commands and CI.
The extension is maintained in Microsoft's vscode-eslint repository. Its Marketplace listing and repository documentation are the best places to confirm support for the current VS Code and ESLint versions.
3. Live Preview
Live Preview is a Microsoft extension for previewing web projects from VS Code. Its documentation describes a local server, quick HTML previewing, and an embedded preview that can be opened while editing.
It is a good fit for:
- A static HTML, CSS, and JavaScript site.
- A small prototype where you want to see changes quickly.
- Checking relative paths and basic browser behavior without configuring a separate server.
Live Preview is not a substitute for the development server supplied by a framework. If your application needs server-side rendering, a database, authentication, environment variables, or a build pipeline, use the project's own development command. You should also test the finished site in the browsers and deployment environment you support; an embedded editor preview is only one view of the result.
Treat the local server as a development tool. Do not place secrets in files just because the preview runs on your machine, and do not assume that local behavior proves your production server's headers, caching, routing, or HTTPS configuration.
The extension's source and current usage notes are in Microsoft's vscode-livepreview repository. Confirm the supported VS Code version in the Marketplace listing before installing it on an older editor.
4. GitLens
GitLens adds Git context to the editor. Depending on the feature and your repository, it can show line blame, open-file history, revisions, comparisons, and other information without requiring you to leave VS Code.
That context is most useful when you are maintaining an unfamiliar codebase or reviewing why a line exists. Use blame as a path to a commit, issue, or pull request—not as a way to assign fault. History explains what changed, but the current tests and requirements explain what should happen now.
GitLens has a free core offering and optional paid functionality. The GitLens pricing page lists the current feature boundaries. Do not assume that a feature mentioned in an old tutorial is included in the free plan, and do not approve a subscription for a small team until you know which users need the paid features.
GitLens is published by GitKraken, and its upstream repository provides the current documentation and release history. The extension can expose repository history and remote information inside the editor, so review your organization's source-code and extension policies before enabling it on sensitive projects.
5. Tailwind CSS IntelliSense
Tailwind CSS IntelliSense is designed for projects that use Tailwind CSS. It adds editor assistance such as class-name completion, hover information, and diagnostics for Tailwind utility classes.
It is most valuable when a class name is composed from many utilities or when a project has a large design vocabulary. Completion can help you discover valid utilities, while hover information reduces the need to switch to documentation for every value.
The extension needs to recognize the project and its Tailwind setup. If completion does not appear:
- Confirm that Tailwind is installed and configured in the workspace.
- Open the project root rather than an unrelated parent or child folder.
- Check the extension's output or diagnostics for configuration errors.
- Confirm that the file type and class syntax are supported by the current version.
- Read the current Tailwind editor setup documentation before adding custom settings.
Do not treat autocomplete as validation of the rendered design. Check responsive states, keyboard focus, color contrast, reduced motion, and the actual browser output separately. The extension helps you write classes; it does not decide whether the interface is accessible.
The project is maintained in the Tailwind CSS IntelliSense repository. Because Tailwind's configuration and major versions can change, check the Marketplace compatibility information and the documentation for the version used by your project.
6. Error Lens
Error Lens displays diagnostics inline near the code that caused them. This can make a compiler, linter, or type-checking message visible without moving to the Problems panel.
It is useful when you are fixing several local issues and want the feedback close to the relevant line. It can also make a project's existing diagnostics easier for a new contributor to notice. Start with errors and warnings; showing every hint or informational message can make the editor harder to scan.
Error Lens changes how diagnostics are displayed, not where they come from. If a message is wrong or missing, investigate the language server, compiler, linter, or project configuration that generated it. Turning on inline text should not be used to hide a noisy check or lower a useful severity.
The Error Lens repository documents its commands and settings. Review its current settings before enabling inline messages across a team, because a configuration that helps one developer can distract another.
A small setup that avoids extension conflicts
You do not need every useful extension in every workspace. Start with the smallest set that solves a real problem, then record the choice in the repository if teammates should share it.
The .vscode/extensions.json file can recommend project extensions without forcing anyone to install them:
{
"recommendations": [
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint"
]
}
For a static site, add ms-vscode.live-server. For a Tailwind project, add bradlc.vscode-tailwindcss. Keep GitLens and Error Lens as personal or team choices unless there is a clear shared workflow for them.
A reasonable settings starting point for a JavaScript or TypeScript project is:
{
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
},
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
}
}
Keep formatter and lint rules in project configuration files, not only in personal settings. If a repository already has a formatter or framework-specific language service, test the combination on a small branch before enabling automatic fixes on save.
How to choose the right extensions
- Every JavaScript or TypeScript project: Start with Prettier and ESLint if the project uses them. They solve different problems when configured deliberately.
- Static HTML and CSS: Add Live Preview for a quick local feedback loop, then test in the supported browsers.
- Tailwind CSS: Add Tailwind CSS IntelliSense after confirming that the extension can detect the workspace configuration.
- Git-heavy maintenance work: Add GitLens when line history and file history will change how you investigate changes.
- A project with many diagnostics: Try Error Lens, but tune the visible severity levels if inline messages become distracting.
- A small team: Commit only the recommendations and settings that improve a shared workflow. Personal navigation and display preferences do not need to become team policy.
Extensions run code in or around your development environment, so treat them as dependencies. Install from the official Marketplace, review the publisher and repository, update deliberately, and remove extensions that are no longer needed. Do not give an extension access to secrets or sensitive repositories without checking the organization's policy.
If your main goal is AI-assisted code generation rather than editor ergonomics, compare the separate AI coding assistants guide instead of assuming that a general web-development extension list covers that decision.
Sources and review notes
The extension choices and maintenance checks in this article were reviewed on September 19, 2026. The official Marketplace pages were checked for current listings and version information, and the linked upstream repositories were checked for current project activity. Versions, pricing, supported VS Code engines, and features can change after publication.