15 Actually Useful VS Code Settings (2026)

In this tutorial, you'll learn about 15 actually useful vs code settings (2026). We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

VS Code settings lists always mention theme, font size, and tab size. Those change the look, not the workflow. This list targets the settings that fundamentally change how you interact with your editor — saving keystrokes, reducing visual noise, and preventing entire categories of mistakes. Every setting here is a genuine productivity multiplier that eliminates a recurring source of friction. Unlike installing a new extension, these settings are built into VS Code and require no additional dependencies or ongoing maintenance.

In this guide, you will learn 15 VS Code settings that improve your editing workflow by automating repetitive tasks, reducing visual clutter, and preventing common errors. Each setting is presented with its exact JSON key and value, along with an explanation of why it matters and how to use it effectively. These are the settings that experienced VS Code users configure on every new machine they set up. Each setting requires a one-time configuration change and then pays back continuously through every hour of editing.

Additional Keyboard Shortcuts Worth Knowing

While this guide focuses on settings, a few keyboard shortcuts amplify the impact of those settings. Ctrl+Shift+P (Cmd+Shift+P) opens the Command Palette, which is the fastest way to access any VS Code feature by name. Ctrl+P (Cmd+P) opens the Quick Open file picker with fuzzy search across all project files. Ctrl+\ creates a new editor split for side-by-side file comparison.

Ctrl+Shift+E focuses the file explorer. Ctrl+Shift+F focuses the global search. Ctrl+\`` toggles the integrated terminal. Ctrl+Shift+K` (Cmd+Shift+K) deletes the current line. These shortcuts complement the settings in this guide by reducing the time between thinking of an action and executing it.

Custom keybindings can be added to keybindings.json, opened via the Command Palette with "Preferences: Open Keyboard Shortcuts (JSON)." The keybindings system supports chording (sequences like Ctrl+K followed by Ctrl+F) and condition-based bindings (different shortcuts for different languages or contexts).

// Example custom keybinding
{
  "key": "ctrl+alt+n",
  "command": "workbench.action.terminal.new"
}

How to Apply These Settings

VS Code settings are stored in settings.json. Open it by pressing Ctrl+, (Cmd+, on macOS) to open the Settings UI, then click the "Open Settings (JSON)" icon in the top-right corner (the file icon with a curved arrow). Alternatively, use the Command Palette (Ctrl+Shift+P / Cmd+Shift+P) and search for "Preferences: Open Settings (JSON)."

Each setting in this guide is shown as a JSON key-value pair. Add them to your settings.json file. VS Code reads the file on save and applies changes immediately — no restart needed. If a setting conflicts with an existing value, the last value written wins. Duplicate keys are not allowed; VS Code highlights them with a squiggle underline.

For team-wide settings, add a .vscode/settings.json file to your project root. This file overrides user settings for that project only. Commit it to version control so all team members get consistent editor behavior. Combine with .vscode/extensions.json to recommend workspace extensions.

Editor Behavior

editor.formatOnSave — Auto-formats your file every time you save. Set it to true and never think about indentation, semicolons, or trailing commas again. Pair it with a formatter like Prettier or the built-in formatter for your language.

This setting triggers the default formatter for the current language whenever you save the file. For JavaScript, TypeScript, CSS, and JSON, Prettier is the standard formatter. For Python, use the built-in formatter or Black. For Go, gofmt runs automatically. The formatter is determined by the [language].defaultFormatter setting, which you can configure per language.

The setting eliminates an entire category of code review comments. Without auto-formatting on save, team members have inconsistent formatting, and developers waste mental energy on formatting during reviews. With this setting, every file is consistently formatted at the moment of saving, and reviewers focus on logic and architecture instead of whitespace.

"editor.formatOnSave": true,
"[javascript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[python]": {
  "editor.defaultFormatter": "ms-python.black-formatter"
}

editor.codeActionsOnSave — Runs code actions on save. The most useful: "source.organizeImports": "explicit" — automatically sorts and removes unused imports. Add "source.fixAll": "explicit" for auto-fixable linter rules.

Code actions are automated refactorings that VS Code applies when saving a file. Import organization removes unused imports, sorts the remaining ones according to the language's convention, and groups them by type (built-in, third-party, local). The linter fix action applies auto-fixable rules from ESLint, pylint, or any active language server.

The "explicit" value (new in VS Code 1.85+) replaces the older true value. It means "run this action on save if the user has explicitly configured it." This distinguishes actions that the user opted into from actions that are safe defaults. Settings with "explicit" are visually marked in the VS Code UI when configuring.

"editor.codeActionsOnSave": {
  "source.organizeImports": "explicit",
  "source.fixAll": "explicit"
}

files.autoSave — Set to afterDelay with a 1000ms delay. Saves automatically one second after you stop typing. Eliminates the mental overhead of remembering to save. If you use Git, combine with files.Refactoring.autoSave: true.

Auto-save eliminates the "did I save?" mental check that interrupts your flow. With afterDelay mode, VS Code saves the current file one second after your last keystroke. If you are typing continuously, the timer resets on each keystroke, so it does not save mid-word. The file saves during natural pauses in typing.

The files.Refactoring.autoSave: true companion setting saves files when you perform a rename Refactoring across multiple files. Without this, rename refactorings leave dirty files that must be saved manually. Combined with files.autoSave, you never see the unsaved dot indicator in the editor tab unless there is a save error.

"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000,
"files.refactoring.autoSave": true

editor.stickyScroll.enabled — Pins the current scope's parent declarations (class names, function names) to the top of the editor as you scroll. When you are 500 lines deep in a file, you always see which function you are inside. Essential for large files.

Sticky scroll displays the current nesting context (class, function, method, if-block) at the top of the editor as you scroll through a file. The context updates as you scroll through different scopes. If you are inside a nested function within a class, the sticky header shows both the class name and the function name in a stacked header.

The setting is invaluable for large files with deep nesting. In a 1000-line React component with 15 nested functions, you can scroll to any position and instantly see which function you are editing without scrolling back to the top. The sticky headers support click navigation — click a header to jump to the corresponding scope definition.

"editor.stickyScroll.enabled": true,
"editor.stickyScroll.maxLineCount": 5

Navigation & Layout

editor.minimap.enabled: false — Turn off the minimap. It is a pixelated distraction that shows structure you can get from the scrollbar. Reclaim that 80px column for actual code. If you miss navigation, use Ctrl+P to jump to any symbol.

The minimap shows a miniature view of the entire file in the right gutter. It consumes approximately 80 pixels of horizontal space that could display actual code. The minimap's resolution is too low to read text — it shows only the distribution of code density (clusters of lines, blank lines, comments). This information is also available from the scrollbar, which shows the same density pattern without consuming space.

After disabling the minimap, most users adjust within a day and do not miss it. If you relied on the minimap for navigation, replace it with better alternatives: Ctrl+P (Cmd+P) to search and jump to any file, Ctrl+Shift+O (Cmd+Shift+O) to navigate to any symbol within the file, and the built-in scrollbar showing change indicators from Git and error markers.

"editor.minimap.enabled": false

workbench.tree.indent — Set to 20 or 24. The default 8px indent in the file tree makes nesting levels barely distinguishable. A wider indent makes directory structure instantly readable at a glance.

The default tree indent of 8 pixels is too narrow to visually distinguish nesting levels, especially on high-resolution displays. Increase it to 20 or 24 pixels to create clear visual separation between parent and child items. The wider indent makes the directory structure scannable without needing to follow the folder icon positions.

This setting affects the file explorer sidebar, the search results tree, and any other tree view in VS Code. The indent width applies uniformly across all tree views. The ideal value depends on your screen resolution and font size — test 16, 20, and 24 to find what looks best on your setup.

"workbench.tree.indent": 20

editor.cursorSmoothCaretAnimation: "on" — Animates cursor movement between character positions. Prevents the disorienting jump when you Ctrl+Right across a long line. Subtle but reduces eye tracking effort significantly.

Smooth caret animation transitions the cursor between positions using a brief animation instead of an instant jump. When you press Ctrl+Right to jump across a long line, the cursor slides through the intermediate characters in a fraction of a second. The animation is fast enough to not feel slow but visible enough to track the cursor's movement.

The setting accepts three values: "off" (no animation), "on" (animate all cursor movements), and "explicit" (animate only when triggered by explicit user actions like keyboard navigation, not by programmatic cursor movement from extensions). The "explicit" option is recommended for the best balance of visual feedback and performance.

"editor.cursorSmoothCaretAnimation": "on"

Visual Enhancements

editor.bracketPairColorization.enabled: true — Colors matching bracket pairs in different colors. When you have four levels of nested callbacks, you can instantly see which closing brace belongs where. The single most impactful visual setting for readability.

Bracket pair colorization assigns a distinct color to each nesting level of brackets. Level 1 brackets are blue, level 2 are green, level 3 are orange, level 4 are purple, and so on. The colors cycle through a predefined palette of six colors with sufficient contrast against both light and dark themes.

The setting applies to all bracket types: parentheses (), square brackets [], curly braces {}, and angle brackets <>. Each type independently participates in the colorization — a ( at level 1 gets the same color as a { at level 1. The colorization updates in real time as you type, so inserting a new opening bracket immediately shows the color for the new nesting level.

"editor.bracketPairColorization.enabled": true

editor.guides.bracketPairs: true — Draws vertical lines connecting matching bracket pairs. Like bracket colorization but spatial — you see the vertical extent of each scope. Together they eliminate "which brace closes what?" confusion permanently.

Bracket pair guides draw vertical lines in the editor gutter next to the line numbers, connecting the opening and closing brackets of each scope. When your cursor is inside a bracket pair, the vertical guide for that pair is highlighted. This gives you a spatial sense of where each scope begins and ends, which is especially useful in deeply nested code.

The guides are rendered as thin vertical lines with the same color as the corresponding bracket pair colorization. They do not add visual noise because they only appear in the gutter area, not within the text. When combined with bracket pair colorization, you have both color coding (which level) and spatial visualization (where the scope extends).

"editor.guides.bracketPairs": true,
"editor.guides.indentation": true

Search & File Management

files.exclude — Hides files from the explorer and search. Add **/node_modules, **/.next, **/dist, **/.git. Less noise in the file tree means faster navigation. The pattern is an array of globs.

The files.exclude setting hides specified file patterns from the VS Code file explorer, file picker, and search results. Files matching these patterns are not deleted or ignored by Git — they are simply not shown in the VS Code UI. This reduces visual clutter in the explorer sidebar by hiding generated files that you rarely need to navigate manually.

Common exclusion patterns include build output directories (dist, build, .next), dependency directories (node_modules, vendor, .venv), version control directories (.git, .svn), operating system files (.DS_Store, Thumbs.db), and cache directories (.cache, .parcel-cache). The patterns support glob syntax with ** for recursive matching and * for single-level matching.

"files.exclude": {
  "**/node_modules": true,
  "**/.next": true,
  "**/dist": true,
  "**/.git": true,
  "**/.DS_Store": true,
  "**/coverage": true
}

search.exclude — Hides files from global search only (they still show in the explorer). Add **/package-lock.json, **/*.min.js, **/coverage. Prevents search results from being filled with generated files.

Unlike files.exclude, which hides files from both the explorer and search, search.exclude hides files only from global search (Ctrl+Shift+F / Cmd+Shift+F). The files remain visible in the file explorer sidebar. This is useful for excluding files that contain many matches but are not useful to search through — generated files, lock files, minified bundles, and test fixtures.

The search.exclude patterns support environment-specific overrides. You can set different patterns for different workspaces or platforms. The patterns also support when clauses to conditionally exclude files based on the search context, though this is rarely needed in practice.

"search.exclude": {
  "**/package-lock.json": true,
  "**/*.min.js": true,
  "**/coverage": true,
  "**/*.snap": true,
  "**/fixtures": true
}

Terminal & Diff

terminal.integrated.fontFamily — Set to a monospace font with good Unicode support like "Fira Code", "JetBrains Mono", or "Cascadia Code". The terminal font is separate from the editor font. A good terminal font makes ls, git log, and htop noticeably more readable.

The integrated terminal font is independent of the editor font. You can use a different font family, size, or weight for each. Terminal fonts benefit from clear glyph distinction between similar characters: 0 vs O, 1 vs l, rn vs m. Programming ligature fonts like Fira Code and Cascadia Code also support terminal-friendly ligatures for ->, =>, !=, and other common operator patterns.

Font selection affects both the terminal and the debug console. A well-chosen terminal font improves readability of log output, command output, and Git diffs. The terminal also supports fontWeight and fontSize settings that are independent of the editor settings, allowing separate configuration for code and terminal output.

"terminal.integrated.fontFamily": "JetBrains Mono",
"terminal.integrated.fontSize": 14,
"terminal.integrated.fontWeight": "normal"

diffEditor.ignoreTrimWhitespace: false — Shows whitespace changes in diffs. Default true hides trailing whitespace and line-ending differences, which can mask real changes in code review. Set to false and decide per-diff if whitespace matters.

The default diff editor setting hides whitespace-only changes, treating lines that differ only in trailing whitespace or line endings as identical. This is useful for ignoring formatting-only changes when the formatter configuration changed. However, it also masks legitimate whitespace changes, such as adding a trailing space that changes markdown rendering or removing trailing whitespace as part of a cleanup commit.

Set this to false to see all whitespace changes in the diff editor. The diff view uses a special visual indicator for whitespace changes — dots for spaces and arrows for tabs — showing exactly what changed. Reviewers can mentally filter out whitespace changes while still knowing they exist. If whitespace noise becomes overwhelming, toggle the setting back with the "Ignore Trim Whitespace" button in the diff editor toolbar.

"diffEditor.ignoreTrimWhitespace": false,
"diffEditor.renderWhitespace": "boundary"

Startup & Security

workbench.startupEditor: "none" — Opens VS Code directly to your project without the Get Started tab. Saves one keystroke (closing the tab) every single time you open the editor. Add "welcome.showOnStartup": false for the same effect.

By default, VS Code shows a "Get Started" tab every time you open a new window. This tab contains links to recent files, documentation, and extension recommendations. For experienced users who know what they are working on, this tab adds friction rather than value. Setting workbench.startupEditor to "none" opens the editor directly with the last file you were editing or the file explorer sidebar.

The complementary workbench.startupEditor: "welcomePage" shows the Welcome page (useful for new users learning VS Code). The "readme" option opens the README file if one exists in the project root. The "none" option is the fastest path to your code, eliminating the mental overhead of closing the startup tab before starting work.

"workbench.startupEditor": "none",
"workbench.welcomePage.walkthroughs.openOnInstall": false

security.workspace.trust.enabled: false — Disables workspace trust prompts. If you only open your own projects, the trust dialog is unnecessary friction. Only disable this if you understand the security implications — untrusted code can execute tasks and extensions.

Workspace trust is a security feature introduced in VS Code 1.57. When you open a folder in VS Code, it displays a "Do you trust the authors of the files in this folder?" prompt. Selecting "Trust" enables tasks, debugging, and extensions for that workspace. Selecting "No" opens the folder in restricted mode with limited functionality.

For developers who only open their own projects or projects from known sources, the trust prompt becomes repeated friction without benefit. Disabling it skips the prompt and treats all workspaces as trusted. If you frequently open code from unknown sources (downloaded repositories, third-party code), keep workspace trust enabled and evaluate each workspace individually.

"security.workspace.trust.enabled": false

Advanced Settings for Power Users

Beyond the core settings listed above, several advanced configurations provide additional workflow improvements. The editor.cursorSurroundingLines setting keeps a configurable number of visible lines above and below the cursor when scrolling. Set it to 8 to maintain context around your cursor position, preventing the cursor from hitting the top or bottom edge of the editor.

The editor.suggestSelection setting controls how VS Code selects the first item in the autocomplete dropdown. Set to "first" to select the first item (default), or "recentlyUsed" to select the most recently used snippet for the current prefix. The "recentlyUsedByPrefix" option is recommended — it prioritizes completions you have selected for the same prefix before, learning your patterns over time.

The workbench.colorCustomizations setting lets you override any theme color without creating a full theme. This is useful for increasing contrast on specific elements. For example, highlight the active tab with a custom color or make the line highlight more visible. The overrides apply on top of any theme, so they survive theme changes.

"editor.cursorSurroundingLines": 8,
"editor.suggestSelection": "recentlyUsedByPrefix",
"workbench.colorCustomizations": {
  "tab.activeBackground": "#2a2a3e",
  "editor.lineHighlightBackground": "#2a2a3e"
}

Performance Settings for Large Projects

Working with large monorepos or projects with thousands of files requires performance tuning. Set files.watcherExclude to exclude directories from file watching. VS Code watches the filesystem for changes to update the explorer, Git decorators, and language servers. Watching node_modules or build output directories consumes significant CPU and memory.

The search.quickOpen.includeHistory setting controls how many recent entries appear in the quick open dropdown. Reduce it to 10 to keep the dropdown focused on frequently opened files. Set search.quickOpen.history.persist to false to clear history on restart, preventing stale entries from accumulating over weeks of use.

The editor.unicodeHighlight.ambiguousCharacters setting highlights characters that look like ASCII but are actually Unicode. This catches homoglyph attacks and accidental non-ASCII characters in source code. Enable it globally and make exceptions for specific languages that legitimately use non-ASCII characters.

"files.watcherExclude": {
  "**/node_modules/**": true,
  "**/.git/**": true,
  "**/dist/**": true,
  "**/.next/**": true
},
"search.quickOpen.includeHistory": 10,
"editor.unicodeHighlight.ambiguousCharacters": true

Language-Specific Settings

Different languages benefit from different VS Code configurations. For Python, configure pylint or ruff as the linter with ruff.lint.run: "onSave" to check imports and formatting. Set python.terminal.activateEnvironment: true to auto-activate the virtual environment when opening a new terminal.

For JavaScript and TypeScript, configure <a href="/programming-languages/typescript/">TypeScript</a>.updateImportsOnFileMove.enabled: "always" to automatically update import paths when files are moved or renamed. Set <a href="/programming-languages/javascript/">JavaScript</a>.suggest.completeFunctionCalls: true to include parentheses after function name completions. Enable <a href="/programming-languages/typescript/">TypeScript</a>.suggest.autoImports: true to automatically add import statements when using a symbol from another module.

For Go development, set go.useLanguageServer: true to enable the Go language server (gopls) for advanced features like Refactoring, code navigation, and diagnostics. Configure go.lintTool: "golangci-lint" for comprehensive linting. Set go.formatTool: "gofumpt" for stricter formatting than the default gofmt.

"[python]": {
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "ms-python.black-formatter",
  "ruff.lint.run": "onSave"
},
"[javascript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "typescript.updateImportsOnFileMove.enabled": "always"
},
"[typescript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "typescript.suggest.autoImports": true
},
"[go]": {
  "editor.formatOnSave": true,
  "go.useLanguageServer": true,
  "go.lintTool": "golangci-lint"
}

Troubleshooting Settings

If a setting does not take effect, check these common issues. First, verify the setting name is correct — VS Code settings are case-sensitive and follow camelCase convention. Use the Settings UI (Ctrl+,) to search for the setting name; if it does not appear, the name is incorrect. Second, check for conflicting settings in workspace .vscode/settings.json that override your user settings. Workspace settings take precedence over user settings.

Third, restart VS Code after changing settings that affect the editor's core behavior. Some settings related to file watching, terminal behavior, and security take effect only on startup. For terminal settings, you may need to close and reopen the terminal panel. For language-specific settings, the language server may need to restart — running the "Developer: Reload Window" command forces a full restart.

If a setting works on one machine but not another, check the VS Code version. Some settings were introduced in specific versions. The setting editor.stickyScroll.enabled requires VS Code 1.70+. The editor.codeActionsOnSave with "explicit" values requires VS Code 1.85+. Check Help > About to verify your version and update if necessary.

Real-World Task: Standardize Team Settings

You have joined a new team of five developers, and each has a different VS Code configuration. Code reviews are filled with formatting comments because files look different in each developer's editor. Use VS Code settings to standardize the team's experience.

1. Create a .vscode/settings.json in the project root with editor.formatOnSave: true and editor.codeActionsOnSave for import organization.
2. Create a .vscode/extensions.json that recommends Prettier, ESLint, and any language-specific extensions the project needs.
3. Add editor.defaultFormatter settings for each language used in the project so all developers use the same formatter.
4. Set editor.bracketPairColorization.enabled and editor.guides.bracketPairs for consistent visual experience.
5. Commit these files to the repository. Existing team members see a notification suggesting they install the recommended extensions. New clones get the settings automatically.

Practice Questions

1. What is the difference between files.exclude and search.exclude settings?
2. How does editor.stickyScroll.enabled help when working with large files?
3. What happens when you set editor.codeActionsOnSave with "source.organizeImports": "explicit"?
4. Why would you set diffEditor.ignoreTrimWhitespace to false instead of the default true?
5. What is the fastest way to apply these settings to your entire team?

Answers

1. files.exclude hides files from both the explorer sidebar and global search. search.exclude hides files only from global search while keeping them visible in the explorer.
2. It pins the current scope's parent declarations (class names, function names, method names) to the top of the editor, so you always see which scope you are inside as you scroll through long files.
3. VS Code automatically sorts imports, removes unused imports, and groups them by category every time you save a file.
4. Setting it to false shows all whitespace changes in diffs, including trailing whitespace and line-ending differences. This reveals real changes that the default hides.
5. Add a .vscode/settings.json file to your project repository with the desired settings. Team members get these settings automatically when they open the project.

Mini Project: Configure a New Development Environment

Create a settings.json file from scratch for a new development machine. Start with editor.formatOnSave and editor.codeActionsOnSave as the foundation. Add bracket pair colorization and guides for visual clarity. Configure files.exclude and search.exclude for your primary languages. Set up the terminal font and diff editor settings. Add files.autoSave and editor.stickyScroll for large-file navigation. Apply the security.workspace.trust setting to disable the trust prompt.

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.organizeImports": "explicit",
    "source.fixAll": "explicit"
  },
  "editor.bracketPairColorization.enabled": true,
  "editor.guides.bracketPairs": true,
  "editor.stickyScroll.enabled": true,
  "editor.cursorSmoothCaretAnimation": "on",
  "editor.minimap.enabled": false,
  "workbench.tree.indent": 20,
  "workbench.startupEditor": "none",
  "files.autoSave": "afterDelay",
  "files.autoSaveDelay": 1000,
  "files.exclude": {
    "**/node_modules": true,
    "**/.git": true,
    "**/dist": true,
    "**/.next": true
  },
  "search.exclude": {
    "**/package-lock.json": true,
    "**/*.min.js": true,
    "**/coverage": true
  },
  "terminal.integrated.fontFamily": "JetBrains Mono",
  "diffEditor.ignoreTrimWhitespace": false,
  "security.workspace.trust.enabled": false
}

After applying these settings, spend one day working with them before deciding whether to keep each one. Some changes (like disabling the minimap) feel uncomfortable for the first few hours but become neutral or positive within a day. Others (like format on save) provide immediate and obvious benefit from the first save. The 15 settings in this guide are not exhaustive — they are the starting point for a workflow that evolves with your needs.

VS Code's settings system is designed for experimentation, with no lock-in risk. Each setting is independent, so you can enable or disable them individually without side effects on other parts of the editor. The Settings UI shows a "Reset" button next to every changed setting, making it easy to revert any change. You can safely try every setting in this guide without worrying about permanent modifications. Settings that do not work for your workflow can be removed in seconds by deleting or commenting out the corresponding JSON line.

Start with the three highest-impact settings: editor.formatOnSave, editor.bracketPairColorization.enabled, and editor.stickyScroll.enabled. These three cover formatting consistency, readability, and navigation — the three most common sources of editor friction. Once these feel natural, layer on the remaining settings at your own pace.

Apply these settings incrementally over a few days rather than all at once. Each setting will integrate into your muscle memory more naturally.