A lot of developers stick with Visual Studio Code’s default settings much longer than necessary. While it gets the job done, it often means missing out on features that could significantly boost productivity. A small handful of settings can dramatically improve how VS Code saves files, formats code, restores work, navigates large projects, and stays consistent across machines. The trick is not to customize everything. It is to change the few settings that make things easier every day.
This guide covers 10 settings worth reviewing immediately, why they matter, when to use them, and where defaults can still make sense.
Why settings matter more than extensions
When developers want to improve VS Code, they often install more extensions first. That can help, but extensions mainly add capabilities. Settings shape your day-to-day experience.
Settings define how your editor behaves and how its features are applied in practice:
- How files save
- How editors open
- How code formatting behaves
- How much visual context do you see
- How safely can you recover from mistakes
- How portable your setup is across devices
Before you start, you should understand the three scopes that matter the most
- User settings: These are your personal defaults for every project.
- Workspace settings: These live in “.vscode/settings.json” and are ideal for project-specific rules. For example, enabling auto-save only in a content repo or changing excludes for a monorepo.
- Profile settings: VS Code profiles let you maintain different setups for different kinds of work. For example, a backend development profile or a lightweight writing profile.
That means you do not need one universal configuration for every situation. Some of the settings below belong in User settings for most people, while others are better in a workspace or profile.
1. files.autoSave
Manual saving is just an extra, repetitive action. In Visual Studio Code, there is a feature that automatically saves your file. So instead of constantly pressing Ctrl + S or saving every few seconds, your work is saved the moment you switch to another file or application. This feature is known as autoSave.
VS Code supports several auto-save modes, such as:
- off – you must manually save, mostly using CTRL + S
- afterDelay – saves after a short pause
- onFocusChange – saves when you switch away from the file
- onWindowChange – saves when you switch away from the VS Code window
The default autosave is usually off, so you have to change it in the Settings UI, or you could change it in your JSON settings. For most developers, afterDelay or onFocusChange hits the sweet spot.
To change in the Settings UI:
- Click the settings tab
- Go to files: autosave and select your preferred choice
To change the JSON settings :
- Press Ctrl + Shift + P (A tab will open)
- Type JSON and select Preferences: Open User Settings (JSON).
In your file, set files.autoSave to the mode that best fits your workflow.
NB: "files.autoSave" It is not present by default in the JSON settings, so you will have to configure it yourself. using this method:
Step 1
Step 2
{
"files.autoSave": "afterDelay"
}Why it’s useful
- It prevents you from losing your work if you forget to save.
- Keeps things updated without constant saving.
- Allows you to be more productive rather than getting interrupted by the idea of forgetting to save your work.
When to be careful
Auto save can be awkward in projects where saving triggers builds, tests, generators, or deployment tasks. In those cases, use workspace-level rules instead of a universal global setting.
2. files.autoSaveWhenNoErrors
This newer setting is one of the smartest additions to VS Code’s save workflow. It lets you keep autoSave enabled, but prevents VS Code from saving a file if it currently has errors. This is useful when you use tools like file watchers, compilers, or other automation that react whenever files change, because saving a broken file could trigger unwanted builds or errors.
To enable files.autoSaveWhenNoErrors:
- Press Ctrl + Shift + P (A tab will open)
- Type JSON and select Preferences: Open User Settings (JSON)
- Manually configure your JSON settings with:
{
"files.autosaveWhenNoErrors": "true",
}Well-suited for
- frontend projects with bundlers watching files
- backend projects with hot reload
- codebases with expensive save-triggered automation
3. editor.formatOnSave
Formatting is the process of making your code look neat, readable, and consistent by improving things like:
- Spacing
- Brackets
- Line breaks
- Indentation
Three (3) separate switches must line up before formatting happens automatically:
- A formatter is installed
- VS Code knows which one to use
- editor.formatOnSave is enabled
Formatting should be automatic whenever possible. Instead of manually running Format Document all the time, you can enable settings like the editor.formatOnSave. So VS Code formats your code every time you save the file. But before this feature works, a formatter must be installed.
A formatter is an external tool that actually knows how your code should look and can automatically clean it up. A formatter defines rules for clean code style and is the brain that knows how the code should actually look.
It is important to know that there are many formatters, and different languages often use different ones.
Here are some examples:
- ESLint or Prettier – JavaScript / TypeScript
- Black or Ruff – Python
- Clang-Format – C / C++ / C# / Java
After installing a formatter, you should specify which formatter to use for each language. If you install multiple formatters (for example, Ruff and Black for Python), Visual Studio Code won’t automatically choose one for you. Instead, it may prompt you to select a default formatter, since it detects multiple formatting tools available.
What you must do(Best Practice)
Go to your JSON settings and configure it manually. Although your Formatter and language may be different, your configuration should look similar to this:
After this, VS Code knows your preferred formatter. But even after choosing a formatter, VS Code still won’t auto-format unless you explicitly allow it. Since auto-formatting can change code style or even reformat entire files, it’s treated as a personal preference, not a default. So you must enable it manually.
Return to your JSON settings and set the editor. formatOnSave to true
{
"editor.formatOnSave": true
},Now, formatting will run every time your file is saved.
VS Code limitations and why it needs a formatter
VS Code can only say “fix how this file looks”. Without a formatter, nothing really happens even when editor.formatOnSave is enabled.
A formatter decides:
- How many spaces to use
- Where brackets should go
- How line breaks should look
- How different languages should be styled.
Why use auto-formatting features?
Better focus
You can write code quickly without worrying about how it looks, because the editor fixes it when you save.
Consistency
Your code always looks the same, no matter who wrote it.
Fewer small corrections
In code reviews, you focus on how the code works instead of fixing tiny things like missing brackets or bad spacing.
4. editor.codeActionsOnSave
Just like formatting, which cleans up how your code looks, like spacing and structure. Code actions go a step further and help improve your code by fixing issues and suggesting better ways to write it. Just make sure you only turn on auto-fix if you trust it, so it doesn’t accidentally change how your code actually works.
What it does well
- Removes unused imports
- Sorts imports consistently
- Can trigger supported fix actions from language tools
- Fixes linting issues
- Rename the variable across the file
An example of code actions
If you write: print(“Hello” VS Code may suggest “Add missing parentheses”. That fix is a code action.
Unlike the features we enabled previously, like editor.formatOnSave or files.autoSave, where we can set it to true/false. You cannot do that with editor.codeActionsOnSave because it expects a list of actions, not a boolean. For example:
"editor.codeActionsOnSave": {
"source.organizeImports": true,
"source.fixAll": true,
"source.fixAll.eslint": true,
"source.fixAll.tslint": false,
"source.sortMembers": true
}Actions like source.fixAll are then set to a boolean. You have to specify what you want.
NB: This only works if you have extensions installed that provide code actions like:
- ESLint
- Ruff
- TypeScript tools
Caution
Do not aggressively enable every possible save-time fix across every language unless your team already trusts the tooling. Start small. Organizing imports is usually safe and high-value.
5. workbench.editor.enablePreview
If you have ever clicked through a few files and then lost track of what is actually open, Preview tabs are probably the reason. workbench.editor.enablePreview is basically a setting in Visual Studio Code that controls how files open when you click on them. It determines whether files open in preview mode or as fully opened tabs.
By default, VS Code can reuse a tab as a temporary preview editor until you double-click or begin editing. Some people love that. Many people hate it.
Example of preview mode
Tab Text: index.js (italics)
The Action: You click style.css in the sidebar.
The Result: index.js disappears and is replaced by styles.css in that same spot
Example of fully opened tabs (Permanent)
Tab Text: index.js (Normal upright text, no italics)
The Action: You click style.css in the sidebar.
The Result: A new tab opens, and now you have both index.js and style.css visible.
If you find the “replacing” behavior annoying and want every single click to create a permanent tab, configure your JSON settings with the code below to keep all tabs fully open.
{
"workbench.editor.enablePreview": "false",
}
Set to true if you want to go back to preview mode.
Why I recommend setting it to false
Turning preview off makes tab behavior more predictable:
- Files stay open when you click them
- Quick Open stops reusing a temporary tab
- It becomes easier to build a stable working set of files
When the default is better
If you work on a small screen or you often inspect lots of files quickly without wanting to keep them open, Preview tabs can be useful. But for most coding-heavy sessions, predictability wins.
6. editor.stickyScroll.enabled
Sticky Scroll is one of those features that sounds minor until you use it on real files. Then you do not want to lose it.
It keeps the currently relevant parent scope visible at the top of the editor as you scroll through nested code.
When you are working on a long function or a nested loop, and you scroll down, you often forget which function you are actually inside
With Sticky Scroll enabled:
- The line defining the class, function, or loop “sticks” to the very top of the editor.
- As you scroll further into a nested block, those headers stack on top of each other.
- When you scroll past the end of that block, the header “unsticks” and moves away
Why it helps
When you are deep inside:
- nested classes
- long functions
- JSX trees
- deeply indented JSON or YAML
- notebook headings and structured content
Sticky Scroll tells you where you are without forcing you to scroll back upward.
Well-Suited for
- Large codebases
- Infrastructure-as-code files
- Markdown and notebooks
- Anyone who frequently gets lost in nested scopes
Go to the JSON setting and enable Sticky Scroll using:
{
"editor.stickyScroll.enabled": true
}7. editor.minimap.enabled and editor.minimap.side
The minimap is surprisingly polarizing. Some people consider it visual noise. Others use it as a lightweight map of the file structure.
The correct answer is not “always on” or “always off.” The correct answer is: make it intentional.
If you like visual navigation you can enable this in your JSON setting using:
{
"editor.minimap.enabled": true,
"editor.minimap.side": "right"
}If you mostly work on smaller files or want a cleaner UI:
{
"editor.minimap.enabled": false,
}Why does this deserve immediate review?
VS Code’s newer improvements made the minimap more useful, including section recognition for folding markers in large files. That makes it more than decorative. It can actually improve navigation.
My opinion
For application code and long config files, I like the minimap. For writing-heavy or distraction-free profiles, I disable it. That is exactly the kind of setting profiles are perfect for.
8. workbench.localHistory.enabled
This one is less about convenience and more about damage control.
Local History stores snapshots of file contents on save, giving you another recovery path beyond Git and undo. It is already enabled by default, but you should verify you have not disabled it, and understand what it can do.
Why it matters
Local History is a lifesaver when:
- You accidentally overwrite a file
- A refactor goes sideways
- You delete something and regret it
- You need to restore work that never made it into Git
A surprising number of developers do not realize this feature exists. That means they discover it only after a painful mistake, or probably never.
In my view, it is one of the most quietly useful protections in VS Code.
Configure in JSON settings to enable. Always be cautious of the boolean(true/false) and that it is set to the correct one.
{
"workbench.localHistory.enabled": true
}9. workbench.settings.editor
If you live in settings.json, you should stop forcing yourself through the Settings UI every time.
Why advanced users prefer it
The JSON settings experience gives you:
- Faster bulk editing
- Easier copy/paste of snippets
- Versionable configuration patterns
- A clearer understanding of what is actually set
- IntelliSense and validation while editing
When the UI is better
If you are still discovering settings names or want guided search and descriptions, the Settings UI is excellent.
Practical compromise
Use the Settings UI when exploring, and switch to JSON once you know what you want. If that is how you already work, set this and save yourself the extra click.
Configure in JSON settings using:
{
"workbench.settings.editor": "json"
}10. Settings Sync
A carefully tuned editor is only valuable if it follows you. VS Code’s built-in Settings Sync can synchronize:
- settings
- keyboard shortcuts
- user snippets
- user tasks
- UI state
- extensions
- profiles
Why it matters
Without sync, your setup slowly fragments across machines. Your laptop behaves one way, your desktop another, and your remote environment becomes a third strange universe.
What to know before enabling it
- You can sign in with Microsoft or GitHub
- Keyboard shortcuts sync per platform by default
- Machine-specific settings are not synchronized by default
- Remote windows do not sync extensions to or from SSH, dev containers, or WSL
Why it belongs in a “change immediately” list
This is not just convenience. It is setup resilience. A good environment should be reproducible.
A practical starter settings.json
If you want a sensible baseline, this is a strong place to begin:
{
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000,
"files.autoSaveWhenNoErrors": true,
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.organizeImports": "explicit"
},
"workbench.editor.enablePreview": false,
"workbench.editor.enablePreviewFromQuickOpen": false,
"editor.stickyScroll.enabled": true,
"editor.minimap.enabled": true,
"editor.minimap.side": "right",
"workbench.localHistory.enabled": true,
"workbench.settings.editor": "json"
}
NB: That is not the only right answer, but it is a very solid default foundation.
How to decide which settings should be global vs project-specific
This is where experienced VS Code users separate useful customization from chaos.
Make it global if it reflects personal preference
Examples:
- preview tabs on or off
- minimap on or off
- settings editor in UI or JSON
- sticky scroll preference
Make it workspace-specific if it affects team or project behavior
Examples:
- auto save behavior for a generated-code repo
- language-specific formatting rules
- folder exclusions for large monorepos
- save-time automation tied to project tooling
Make it profile-specific if it reflects a mode of work
Examples:
- a writing profile with no minimap and cleaner UI
- a frontend profile with aggressive formatting and linting
- a remote profile with lighter extension load
Common mistakes when changing VS Code settings
1. Over-customizing immediately
Do not tweak 80 settings in one sitting. You will not know which change helped and which one made things worse. Its better to take it a few steps at a time
2. Mixing personal preference with team policy
Your font ligatures are personal. Save-time code actions that rewrite imports might affect a shared repo. Treat them differently.
3. Forgetting workspace overrides exist
Many settings are best applied to one project, not every project.
4. Installing extensions to solve settings problems
If the issue is tab behavior, saving, layout, or formatting workflow, first check whether a built-in setting already handles it.
5. Ignoring recovery features
Local History and Settings Sync are not glamorous, but they reduce pain when something breaks.
Bottom line
You don’t need dozens of extensions or endless tweaks to improve VS Code.
You need the right defaults. Once your editor saves, formats, restores, and navigates the way you expect, everything else becomes easier. And that’s when VS Code stops feeling like a tool and starts feeling like part of your workflow.
