Open Activity Monitor while VS Code is running and you'll often find it near the top of the memory list, close to Chrome or ahead of it. For a code editor, the numbers feel disproportionate. Atom, TextMate, and the editors that came before VS Code were rarely this heavy. The explanation is the same one that applies to Slack, Discord, and dozens of other modern desktop apps: the Electron framework.
Understanding why VS Code uses so much memory makes the practical fixes easier to reason about. Most of the weight comes from a small number of identifiable sources, and most of those sources can be trimmed if you're willing to trade some convenience for headroom.
Why VS Code is heavier than people expect
VS Code is built on Electron, a framework that lets developers ship desktop apps using web technologies by bundling a full copy of Chromium, Google's browser engine, inside the application. When you launch VS Code, you're launching what is essentially a browser running a sophisticated text-editing interface. That Chromium baseline costs several hundred megabytes before any of your files load.
On top of the Electron layer, VS Code runs a Node.js process for its extension host, a separate backend process to handle file operations, and a renderer process for the editor UI itself. Activity Monitor will show VS Code as several processes rather than one, because that's what it is: multiple cooperating processes, each holding its own slice of memory.
Then there are language servers. When you open a TypeScript file, VS Code starts a TypeScript Language Server in the background. This process reads your project's type definitions, builds an in-memory model of your entire codebase, and keeps it updated as you type. The richer the analysis VS Code offers (go-to-definition, inline errors, rename-across-files), the more that language server has to hold in RAM. A large TypeScript monorepo can push the language server alone past 500 MB.
VS Code also runs file watchers to detect changes on disk. In large projects with deep node_modules directories or many generated files, these watchers add their own overhead and can contribute to sluggishness even when the editor is otherwise idle. Microsoft's own VS Code performance documentation identifies file watcher scope as one of the most impactful things to tune.
The extensions problem
Extensions are VS Code's biggest selling point and its biggest memory liability. Each extension you install doesn't just sit quietly in a folder; it runs inside VS Code's extension host process, and many extensions spawn additional background processes of their own.
A linter like ESLint starts a server process to analyse your files. A formatter like Prettier runs its own worker. A test runner integration monitors your project and keeps results in memory. Git integrations, remote development tools, and AI assistants like GitHub Copilot all add their own processes on top of the extension host. The result is that a VS Code installation with fifteen extensions isn't running one app; it's running a small cluster.
The extension problem compounds over time. When you install VS Code, you install a handful of extensions. Over months, the list grows, often with extensions added for a one-off task and never removed. Many of those extensions activate on every startup by default, even in projects where they're not needed. A Python linter runs in your Rust project. A Docker integration runs when you're writing plain Markdown. VS Code loads all of it.
Realistic numbers
Here's what to expect at different levels of use:
- VS Code with no project open, a few extensions: 300-500 MB. The Electron core, extension host, and idle language services account for most of this.
- A typical workspace with two or three extensions: 800 MB to 1.5 GB. A language server for your primary language, a linter, and a formatter push usage up quickly once a project is open and indexed.
- A TypeScript project with the TypeScript Language Server active: add 300-600 MB on top of your baseline, depending on project size and the depth of type definitions in use.
- GitHub Copilot enabled: add roughly 200-400 MB. Copilot Chat, which maintains richer context about your codebase, sits toward the higher end of that range.
- Ten or more extensions, large TypeScript monorepo: 2-3 GB is a normal figure and not a sign that something is wrong. It's the predictable result of running everything simultaneously.
The best tool to check this is VS Code's own built-in process explorer. Open the Command Palette with Command-Shift-P, type "Developer: Open Process Explorer", and press Return. This shows every VS Code process, what it's doing, and how much memory it's using. It's often more useful than Activity Monitor for understanding where VS Code's memory is actually going.
Practical fixes
Most of VS Code's memory overhead is controllable. These are the steps that make a genuine difference:
Audit your extensions. Open the Extensions panel and look at what's installed. For each one, ask: do I actually use this in my current projects? If not, disable it or uninstall it. VS Code lets you disable extensions globally or per-workspace, which means you can keep an extension installed but only activate it when you need it. Removing five unused extensions can recover several hundred megabytes.
Use profiles per project type. VS Code has a Profiles feature that lets you maintain separate sets of extensions, settings, and keybindings. A "Python" profile with only Python-relevant extensions, a "Markdown" profile with just a spell checker and a preview, and a "TypeScript" profile with the full stack keeps each workspace lean. Switching profiles is quick, and the memory difference between a lean profile and a loaded one can be 1 GB or more.
Exclude node_modules and build output from file watchers. In your settings.json, add node_modules, dist, .next, or whichever generated directories apply to your project under files.watcherExclude. This reduces the number of file system events VS Code processes and can improve responsiveness in large projects. VS Code's performance documentation covers the exact setting syntax.
Disable telemetry. VS Code sends usage data by default. Turning this off in preferences (telemetry.telemetryLevel set to off) doesn't save enormous amounts of memory, but it removes a background process that fires periodically and contributes minor overhead over long sessions.
Restart VS Code when it gets heavy. Like most Electron apps, VS Code's memory usage grows over a long session as caches accumulate and language servers index more of your project. Quitting and relaunching resets this. If VS Code feels slower at the end of the day than it did in the morning, a fresh launch is often the quickest fix. For a comparison of how other Electron-based tools behave over time, see Slack on Mac: 2GB RAM and what to do about it.
The native alternatives and the honest trade-off
Three editors are commonly recommended as lower-memory alternatives to VS Code: Sublime Text, Zed, and Helix.
Sublime Text is a native app, not an Electron one. It opens large files faster than VS Code and typically uses 100-200 MB even with a project open. Its extension ecosystem is smaller and the Language Server Protocol support, while present via packages like LSP, is less polished than VS Code's built-in implementation. If you write mostly in a single language and don't rely on many extensions, Sublime Text is a legitimate daily driver.
Zed is a newer editor built in Rust, designed explicitly to be fast and memory-efficient. On Apple Silicon it makes good use of the architecture. Memory usage is typically under 200 MB even with a large project, and it supports the Language Server Protocol natively. The trade-off is a smaller extension ecosystem and fewer integrations than VS Code's. Copilot support exists but the integration story for some tools is still maturing.
Helix is a terminal-based modal editor, closer in spirit to Vim or Neovim than to VS Code. It's extremely lean and fast, but the learning curve is steep and it requires comfort with a modal editing model. Worth knowing about, but probably not the right recommendation for someone who just wants VS Code to use less memory.
The honest trade-off is this: VS Code's memory cost is the price of its extension model. If you rely on a debugger integration, a test runner, a specific language server, and Copilot, switching to Zed means rebuilding your workflow. For many developers that trade isn't worth it. For developers who mainly want good syntax highlighting and Git integration, either Zed or Sublime Text delivers that at a fraction of the cost. If you're comparing VS Code's memory use to other heavy apps in your day, see Xcode memory on Mac and Chrome on Mac: why it eats RAM for context on the broader picture. And if you're wondering whether Figma is contributing to the same pressure, that guide covers the browser-tab architecture Figma uses.