Top 5 VS Code Extensions for Developers in 2026

I've been using VS Code since it was called "Code - OSS." The extension ecosystem is the main reason I've stuck with it. Every year I audit my installed extensions and cut the ones I'm not actually using. These five have survived every purge.

1. GitHub Copilot

The obvious one. I was skeptical when it launched (I'd used tab-complete tools before and found them more distracting than helpful). Copilot was different because it generates blocks, not just single lines. Write a function signature and a comment, and it produces the body. Half the time the body is correct and I move on. The other half, it's a starting point that's faster to edit than writing from scratch.

The trick is to treat it like a pair programmer who types fast but doesn't know your codebase. Review what it produces. Keep your interfaces narrow so it has less room to generate nonsense.

2. ESLint

I don't think about ESLint anymore. It's just there, flagging undefined variables before they become runtime errors, enforcing consistent imports, catching the kind of bugs that are trivial but annoying. The only configuration I care about is "source.fixAll.eslint": true on save: that auto-fixes anything ESLint can fix without asking.

3. Prettier

Prettier's value isn't about which style it enforces. It's that there's exactly one style enforced, automatically, every time I save. No debate about trailing commas or single quotes in code review. The debate ended when we put "editor.defaultFormatter": "esbenp.prettier-vscode" in the team settings.

4. GitLens

I use GitLens mostly for its inline blame annotations. Hover over a line, see who wrote it and when. Sounds minor until you're staring at a confusing piece of code and need to know whether it was written by someone who's still on the team or by an intern three years ago. The history view is useful when tracking down when a bug was introduced, but the inline blame is what I use hourly.

5. Playwright Test

If you write end-to-end tests, this extension makes the feedback loop tolerable. Test results show up inline, you can debug with breakpoints inside test files, and the codegen feature records browser interactions into test code. I use it more for debugging flaky tests than writing new ones, but it does both.

Bonus: My Settings.json

These aren't going to change your life, but they save me small annoyances:

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.tabSize": 2,
  "editor.wordWrap": "on",
  "editor.minimap.enabled": false,
  "explorer.confirmDelete": false,
  "typescript.updateImportsOnFileMove.enabled": "always"
}

The minimap one is controversial. I know some people swear by it. I find it takes up space without providing useful information. Try turning it off for a week and see if you miss it.

You Might Also Like

• Generative Engine Optimization (GEO) for Technical Docs
• The Internal Linking Mistake I Made for Years (And How I Fixed It)
• Why Your Technical Blog Needs a Tag Taxonomy (And How to Build One That Lasts)
• Using Google Search Console: What Actually Moves the Needle for a Dev Blog

Frequently Asked Questions