Soumitra SahaAugust 7, 2026

10 VS Code Extensions Worth Installing

A verified list of 10 VS Code extensions — from ESLint and GitLens to Error Lens and REST Client — with their actual use cases and what each one covers that VS Code's defaults don't.

Most VS Code extension lists don’t age well. An extension that solved a real problem in 2021 may now duplicate something VS Code added in a later release — or the extension itself may have gone unmaintained. That gap matters more than most lists acknowledge.

The ten extensions below are verified active on the VS Code Marketplace as of early 2026. Each one covers something VS Code’s defaults leave open, and each has a job narrow enough to describe in a sentence or two.

Code quality: linting and formatting

Three extensions share the same underlying goal: keep code consistent and catch mistakes before they reach a review.

ESLint (dbaeumer.vscode-eslint, maintained by Microsoft) integrates the ESLint library into the editor. As you type, it underlines rule violations — unused variables, missing hook dependencies, potential type mismatches — and offers inline code actions to fix them on the spot. The extension supports ESLint’s flat config format (eslint.config.js), the default in ESLint v9. The most useful setting is auto-fix on save, which lets ESLint resolve fixable problems every time the file saves without any manual intervention.

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

Prettier (esbenp.prettier-vscode) handles the formatting side — the part ESLint intentionally leaves alone. It reformats the file on save: indentation, trailing commas, quotation style, line length. Prettier bundles a version of the formatter, but it uses your project’s locally installed version when one exists, which keeps behavior consistent between the editor and your CI pipeline. Setting it as the default formatter means every person on the project formats identically, regardless of what their personal settings say.

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

Biome (biomejs.biome) is the third option here, and it’s worth knowing about even if you don’t switch today. It combines linting and formatting into a single Rust-based tool — the same job as ESLint plus Prettier together. The tradeoffs are real: Biome’s rule coverage is smaller than ESLint’s plugin ecosystem, and migrating an existing project takes effort. But it starts faster, produces no config conflicts between the linter and formatter, and is actively gaining the rules that matter most for JavaScript and TypeScript projects. For a greenfield project, it’s a legitimate starting point.

The practical call for most projects: use ESLint and Prettier together if you already have them configured and working. Consider Biome for a new project where you want to skip the two-tool setup. If you want to read more about automating this kind of tooling into your commit process, the developer workflow automation guide covers Husky and lint-staged alongside these same linters.

Making errors impossible to skip

VS Code shows TypeScript and ESLint errors in the Problems panel at the bottom of the screen, and you can read the full message by hovering over a red underline in the editor. Both of those require a deliberate action on your part.

Error Lens (usernamehw.errorlens) removes that friction. It renders every diagnostic message — errors, warnings, and info — inline on the line that produced them, in the editor itself, without a hover. If a TypeScript type mismatch exists on line 42, the message appears to the right of line 42 in a subdued color while you’re reading the code around it. The line also gets a background tint matching the severity.

The most practical effect shows up during active TypeScript development when types shift with every edit. Error messages appear in your peripheral vision as you work, not in a panel you switch to after the fact. If you’re learning TypeScript and want to understand what each error means as it appears, this extension pairs naturally with TypeScript for JavaScript developers.

Git in the editor, not in the terminal

GitLens (eamodio.gitlens, maintained by GitKraken) extends the Git context available in VS Code well beyond what the default Source Control panel shows. The Community tier — free and open source — includes the features most developers reach for daily:

Inline blame: at the end of the currently focused line, GitLens renders the author, date, and commit summary in a muted annotation that updates as your cursor moves.
Rich hovers: hovering over any blame annotation opens the full commit details: message, diff stats, linked pull requests or issues, and the file’s history at that point.
File and line history: the file-level view lists every commit that touched the current file in order. The line-level view shows you when the selected line was last changed and in which commit.
Revision navigation: step forward and backward through a file’s history one commit at a time without leaving the editor.
Git CodeLens: shows the most recent commit and a contributor summary at the top of each file and at the top of each function.

The Commit Graph and AI-assisted commit message generation require a free GitKraken account and a Pro trial, but the blame, history, CodeLens, and revision navigation features are entirely free and always have been. If you work on a codebase with more than one contributor, “who changed this line and why” becomes a glance rather than a terminal lookup. The git basics guide covers the underlying Git concepts GitLens surfaces if any of the annotations look unfamiliar.

Three extensions that remove small friction

These three don’t solve the same problem, but each one removes friction that shows up multiple times a day.

Todo Tree (Gruntfuggly.todo-tree) searches your entire workspace for comment tags — TODO, FIXME, BUG, and any custom tags you add — and collects them in a tree view in the activity bar. Click any item to jump to the file and line. It uses ripgrep internally, so the search is fast even in large repositories. The problem it solves is a simple one: without this extension, every TODO comment is invisible until you happen to open the right file. With it, your entire backlog of in-code notes lives one click away.

Path Intellisense (christian-kohler.path-intellisense) autocompletes filenames and relative paths as you type. When you start an import with ./, the extension offers the actual filenames in that directory. It reads tsconfig.json paths and baseUrl automatically, so TypeScript path aliases like @/components/Button resolve correctly in suggestions. The practical impact grows with project size: in a flat directory structure it’s convenient, in a large monorepo it’s close to essential.

REST Client (humao.rest-client) lets you write and run HTTP requests in plain .http or .rest files directly inside VS Code. Define a request in a file:

GET https://api.example.com/users/1
Accept: application/json

###

POST https://api.example.com/users
Content-Type: application/json

{
  "name": "Alice"
}

A “Send Request” link appears above each request via CodeLens. Click it and the response opens in a side panel with syntax highlighting. The extension supports multiple requests per file, environment variables for switching between dev and production base URLs, request chaining, and all common authentication schemes. Keeping your API requests in version-controlled .http files — right next to the code they test — is more durable than a collection of saved requests in a GUI tool. If you want a more detailed look at structuring the backend those requests hit, the Express project structure guide covers the server side.

HTML and JSX tag pairing

Auto Rename Tag (formulahendry.auto-rename-tag) automatically renames the paired closing tag when you rename an opening HTML or JSX tag. Change <section> to <article> and the </section> at the end of the block becomes </article> in the same keystroke.

One important caveat: VS Code 1.44 and later includes editor.linkedEditing, a built-in setting that does the same thing for HTML and Handlebars files. If HTML is your primary environment, test "editor.linkedEditing": true in your settings before installing the extension. The extension is still useful for JSX and TSX files, where the built-in linked editing doesn’t activate — and in practice, most React and Astro projects have enough JSX that the extension earns its keep.

Visual coherence with almost no effort

Material Icon Theme (PKief.material-icon-theme) replaces VS Code’s default file icons with a large set of Material Design icons. File types that get distinct icons include TypeScript, TSX, JSON, environment files, Docker configs, Prisma schemas, Astro components, and many others. Folder icons are similarly differentiated: folders named components, hooks, utils, public, or api display different icons based on their name.

The practical benefit is scanning speed. When every file type looks the same, your eye reads filenames. When icons distinguish file types at a glance, you find what you’re looking for faster in a long list. The extension has 35 million installs, is actively maintained, and requires no configuration to start — activate it from the command palette and the icons apply immediately.

Abstract illustration of a code editor with inline diagnostics, a git branch graph, and a quality checkmark — representing developer tooling concepts. — The three themes these extensions address: code quality, git visibility, and editor clarity.

Where to start if you want fewer than ten

Not every project needs all ten. Priority depends on what you’re working on:

Your situation	Install first
New JavaScript or TypeScript project	ESLint + Prettier, or Biome
Shared codebase, multiple contributors	GitLens + Todo Tree
React, Astro, or any JSX-heavy project	Auto Rename Tag + Error Lens
Building or testing an HTTP API	REST Client
Any project, no configuration needed	Material Icon Theme + Path Intellisense

The narrower lesson here is about selection: a small set of extensions that each do one clear job is more useful than a large collection of ones you half-configured and occasionally forget you installed. VS Code adds built-in features in roughly every monthly release, so checking an extension’s changelog occasionally — especially for the older ones — tells you whether a capability has moved into the editor itself.

Install the two or three that match your current project, verify they don’t conflict with your existing settings, and add the rest later when the need is concrete.