How to Setup Prettier in Vs Code

Prettier formats code. No arguments, no preferences. It takes messy code and makes it clean across JavaScript, TypeScript, HTML, CSS, and more. Set rules once, format everywhere.

Skip manual formatting. Prettier handles syntax consistency and catches errors before they bite. Your code stays readable without the overhead.

Consistent style across projects. No developer preference wars.

Automates formatting. Time saved goes to real work.

Kills style debates. Teams collaborate without friction.

Catches syntax issues early. Bugs die in development.

Setup takes minutes. Three steps, then you’re done.

Hit Extensions view (‘Ctrl+Shift+X’). Search “Prettier – Code formatter.” Click Install. Done.

Drop a ‘.prettierrc’ file in your project root. Or add config to ‘package.json’. Pick your rules, set them once.

Open preferences (‘Ctrl+,’). Find “Format On Save.” Check “Editor: Format On Save.” Code formats on every save without thinking.

Prettier bends to your needs. Configure what matters:

• Indentation: Set spaces or tabs. Pick your count.
• Line Width: Max line length before wrapping kicks in.
• Semicolons: Use them or lose them at statement ends.
• Quotes: Single or double around strings.

Teams win with Prettier. Here’s proof from the trenches.

Challenge: Mobile app startup fought style chaos across developers. Manual formatting ate time and bred errors.

Solution: Prettier in VS Code fixed everything. Code stayed uniform, developers collaborated better. Automated formatting freed the team to ship quality apps instead of fixing tabs.

Challenge: Fintech company suffered code review hell. Inconsistent formatting slowed everything down.

Solution: Prettier standardized their style overnight. Code reviews got smooth, dev cycles got fast. Quality jumped, productivity soared after Prettier joined their toolkit.

Prettier in VS Code works. Simple setup, massive payoff for code quality and team flow. Formatting stops being a problem when Prettier handles it automatically.

Solo developer or big team – Prettier upgrades your VS Code setup immediately. Clean code, happy developers.

Ready to streamline your workflow with Prettier? Contact us for DevOps solutions that boost your coding process and code quality.

Watch for more deep guides and videos on developer tools and best practices.

On a personal scratch file, installing the VS Code extension is enough. On a project that other people will touch, I would do a little more. Install “Prettier – Code formatter” in VS Code first, because that is what gives the editor its Prettier command. Then add Prettier to the project too, not just to your laptop.
The reason is boring but important. If Prettier only lives in your VS Code extension, the next developer may format with a different version, or CI may check formatting with another one. That is how tiny, pointless diffs show up in pull requests. Pinning Prettier as a dev dependency keeps the editor, terminal, and pipeline pointed at the same tool.
I also like adding the project files before anyone runs a big format. A small .prettierrc says the repository uses Prettier on purpose. It can be empty at first. A .prettierignore is the guardrail: skip build output, coverage, generated files, vendored folders, or anything the team should not touch by hand.
So my setup order is simple: extension first, local Prettier package second, config third, ignore file before the first cleanup commit. That gives you convenience in VS Code without turning formatting into a personal editor preference.

The quickest way to solve formatter confusion in VS Code is to make it visible. Open a JavaScript or TypeScript file, run “Format Document With…,” and look at the list. If you see Prettier there, VS Code knows about the extension. If another formatter is selected, that explains why saving the file does not produce the Prettier result you expected.
For web projects, choose Prettier as the default formatter for the file types it should own. The extension id is esbenp.prettier-vscode. I would be careful with setting it as the formatter for everything, though. A repository may use Prettier for front-end files and still rely on Black, gofmt, rustfmt, or another tool elsewhere. Language-specific settings keep that boundary clear.
Format on save is a separate choice. Turning it on makes sense when the team already agrees that Prettier owns formatting. If the codebase is older, you may decide to format manually for a while so one small change does not create a 500-line whitespace diff.
In a team repo, I prefer writing the agreed formatter choice into workspace settings. User settings only fix your machine. Workspace settings help the next developer avoid the same five-minute mystery when Prettier is installed but VS Code keeps reaching for another formatter.

I would not treat .prettierrc versus package.json as a religious choice. Prettier supports both. The better question is where the team will actually notice the setting six months from now.
For a small npm package, a prettier key in package.json can be perfectly reasonable. The file is already open when people edit scripts, dependencies, and tooling. For a larger app, I usually prefer a separate .prettierrc or prettier.config.js in the project root. It is easier to find, easier to review, and it keeps formatting decisions away from unrelated package metadata.
There is one rule I would be stricter about: do not rely on somebody’s global editor setup. Prettier intentionally avoids global config because a project should format the same way after it is cloned on another machine. That is the whole point of committing the config.
If the project is straightforward, keep the config boring. A few choices such as tab width, semicolons, single quotes, trailing commas, and print width are enough for most teams. The more you tune, the more you invite the style debate Prettier was supposed to end. Pick the shape the team can live with, commit it, and let the tool be invisible most days. Future maintainers will quietly thank you for that small decision.

Format on save has two switches, and people often flip only one of them. VS Code must be allowed to format when you save, and Prettier must be the formatter chosen for the file. If either side is missing, nothing useful happens.
I would test it in a single file before changing a whole workspace. Open a JavaScript or TypeScript file with obviously messy spacing. Run Format Document With…, choose Prettier, and confirm the file formats correctly. Then enable format on save. In settings, that is the editor.formatOnSave option. If the project has several languages, consider turning it on only where Prettier is supposed to run.
If saving still does nothing, check the ordinary culprits. The file may be ignored by .prettierignore. Another formatter may be the default. The language may need a Prettier plugin. Workspace settings may be overriding your user settings. It is rarely magic; VS Code is usually following some setting you have not looked at yet.
For teams, format on save is lovely once everyone agrees on the same Prettier version and config. Before that, it can create noisy diffs. I would rather standardize the project first, then enable save formatting, than let every developer discover a different behavior on their own machine.

When Prettier “doesn’t work,” I try not to touch five settings at once. That usually makes the problem harder to see. Start with one file and ask VS Code a simple question: which formatter is available here?
Run “Format Document With…”. If Prettier is not in the menu, you have a discovery problem: wrong file type, disabled extension, missing plugin, or workspace restrictions. If Prettier is in the menu, choose it once. If the file changes, make Prettier the default formatter for that language. If the file does not change, it may already be formatted, which is easy to overlook.
If you get an error, read it before editing settings. Prettier has to parse the file, so broken syntax can stop it. A bad config can stop it too. So can a plugin that the project expects but has not installed. Another quiet culprit is .prettierignore. If the file is ignored, Prettier is probably obeying the project, not failing.
When I am still unsure, I open the VS Code Output panel and select Prettier. That log is not pretty, but it usually tells you which Prettier version ran, which config it found, and what blocked the format. Guessing is slower.

No. If a team tells me Prettier replaced ESLint, I assume they have only solved formatting. Prettier is great at making files look consistent. It decides how code is printed: line breaks, indentation, quotes, commas, semicolons, and similar choices. ESLint is still the tool that can complain about code patterns the project considers risky or wrong.
The two tools get messy only when ESLint is also carrying old formatting rules. Then you save a file, Prettier changes it, ESLint complains, and somebody loses ten minutes reading config instead of reviewing the feature. That is the part to remove. Let Prettier own style. Let ESLint own code rules.
In a practical setup, Prettier runs in VS Code and in CI as a formatting check. ESLint runs beside it for JavaScript or TypeScript rules. If you enable ESLint fixes on save, test the order so it does not undo or argue with Prettier.
I would also be careful with the phrase “Prettier catches errors.” It can expose syntax errors because it has to parse the file, but it does not know whether the code is correct, secure, well typed, or properly tested. It makes review quieter; it does not replace review. That distinction matters in real teams.

For a team, Prettier should not depend on who saved the file in VS Code. The formatting rules need to live in the repository, and CI should be able to check them without opening an editor. That usually means a local Prettier dependency, a committed config, a .prettierignore file, and a couple of package scripts.
I like having one script that checks and one that fixes. The check script can run Prettier with –check, which reports unformatted files and exits with a failing status when something needs attention. That behavior is exactly why it works in CI. The write script can run Prettier with –write, which is useful locally because it changes files in place.
I would not make CI rewrite code unless the team has a very deliberate automation flow. In most repositories, CI should fail clearly and tell the developer what to run. That keeps formatting changes in the same branch and review as the work.
The ignore file is the quiet hero here. Without it, a first formatting pass can touch coverage output, generated code, snapshots, vendor folders, or build artifacts. Then the pull request becomes impossible to review. Set the boundary first. After that, Prettier makes reviews calmer because people stop commenting on spaces and start reviewing behavior.