.prettierrc Explained: Every Prettier Config Option in JSON, JSON5, YAML, or TOML

Config file formats and resolution order

Prettier searches the current directory (then each ancestor) for one of the supported file names below. The first one it finds wins; the search stops. If two config files exist in the same directory, Prettier uses the higher-priority format and ignores the rest — so don't keep both a .prettierrc and a prettier.config.js in the same folder.

Resolution walks upward from the file being formatted. That means apackages/ui/.prettierrc overrides the monorepo root config — Prettier uses the first match it finds, it does not merge configs.

The 25 options grouped by category

Prettier 3.x exposes a tightly-curated set of options. The table groups them by what they affect. The "default" column reflects Prettier 3.x — the only default that has changed since Prettier 2 is trailingComma.

That's the lot. Anything you can't change here is a Prettier opinion — file an issue upstream if you disagree, but don't expect a flag.

The 5 options 90% of teams override: printWidth, tabWidth, singleQuote, semi, trailingComma

Almost every .prettierrc in the wild touches some subset of these five. Everything else is usually left at default.

{
  "printWidth": 100,
  "tabWidth": 2,
  "singleQuote": true,
  "semi": false,
  "trailingComma": "all"
}

• printWidth (default 80): Prettier's wrap target. Not a hard column limit — Prettier may exceed it for unbreakable expressions. 100 and 120 are common widescreen choices; the React, Vue, and TypeScript repos all use 100+.
• tabWidth (default 2): spaces per indent. Set to 4 if your project uses 4-space indent. Note: this is the count Prettier writes — combine with useTabs to switch to literal tab characters.
• singleQuote (default false): set to true if your codebase uses single quotes for JS/TS strings. Doesn't affect JSX attributes — that's the separate jsxSingleQuote option.
• semi (default true): set to false for the no-semicolon style popularized by Standard.js. Prettier inserts a leading semicolon on lines that need ASI protection (e.g., before [ or ( at line start), so you stay safe either way.
• trailingComma (default "all" in 3.x): the modern default puts a trailing comma after the last array, object, and function argument. Use "es5" to drop trailing commas in function calls (needed for IE), or "none" to disable everywhere.

Per-file overrides with the overrides array

The overrides array applies different options to files matching a glob. Prettier walks the array top-to-bottom and applies the first match — list more-specific patterns first.

{
  "printWidth": 100,
  "singleQuote": true,
  "trailingComma": "all",
  "overrides": [
    {
      "files": "*.md",
      "options": {
        "printWidth": 80,
        "proseWrap": "always"
      }
    },
    {
      "files": ["*.yaml", "*.yml"],
      "options": {
        "tabWidth": 2,
        "singleQuote": false
      }
    },
    {
      "files": "package.json",
      "options": {
        "tabWidth": 2,
        "useTabs": false
      }
    },
    {
      "files": "*.tsx",
      "options": {
        "jsxSingleQuote": false
      }
    }
  ]
}

Common override use cases: shorter printWidth and proseWrap: "always" for Markdown (so docs render well on narrow screens); double quotes in YAML (where single quotes have a different semantic meaning); pinned indent for package.json (npm normalizes it on every install anyway).

Plugins: prettier-plugin-tailwindcss, prettier-plugin-organize-imports

Plugins add support for new languages or transform code beyond Prettier's core scope. Install them as devDependencies and list them in the plugins array. The two most common ones in 2025:

# Install
npm install -D prettier-plugin-tailwindcss prettier-plugin-organize-imports

{
  "plugins": [
    "prettier-plugin-organize-imports",
    "prettier-plugin-tailwindcss"
  ],
  "tailwindConfig": "./tailwind.config.ts"
}

• prettier-plugin-tailwindcss — sorts Tailwind utility classes into the official recommended order. Maintained by the Tailwind team. Must be listed last in the plugins array because it depends on other plugins having already run.
• prettier-plugin-organize-imports — removes unused imports and sorts the remaining ones using the TypeScript language service. Run order matters: list it before prettier-plugin-tailwindcss.
• Other notable plugins: @prettier/plugin-php, prettier-plugin-svelte, prettier-plugin-astro, @prettier/plugin-xml, prettier-plugin-prisma — these add parsers for languages Prettier core doesn't support.

Prettier 3 changed the plugin format — plugins must now be ES modules and export specific entry points. Older Prettier 2 plugins will fail to load until upgraded; check the plugin's README for a Prettier-3-compatible version before pinning.

Prettier 2 → Prettier 3 breaking changes (2023+)

Prettier 3.0 shipped in July 2023 and introduced several format-affecting and plugin-affecting changes. If you upgraded and saw a giant diff, this section explains why.

Upgrade strategy: bump Prettier in a dedicated PR, run prettier --write . on the whole repo, commit the result, and tell reviewers to use git blame --ignore-revs-file so the reformat commit doesn't pollute blame history. Add the formatting commit SHA to .git-blame-ignore-revs and push.

Editor integration and .prettierignore

Two pieces of infrastructure make Prettier feel automatic: editor format-on-save and a proper .prettierignore.

VS Code: format-on-save

// .vscode/settings.json (commit this file)
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[typescriptreact]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[json]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[markdown]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }
}

Install the esbenp.prettier-vscode extension first. The per-language entries are belt-and-braces — they make sure no other formatter (Astro extension, ESLint formatter) wins by accident.

.prettierignore

# .prettierignore
node_modules
.next
.nuxt
.svelte-kit
.turbo
dist
build
out
coverage
*.min.js
*.min.css
package-lock.json
pnpm-lock.yaml
yarn.lock

Same syntax as .gitignore. Prettier always ignores node_modules even without an entry, but build outputs and lockfiles must be listed explicitly. Lockfiles are particularly important — Prettier will rewrite them in ways that breaknpm install determinism.

Running in CI

Add prettier --check . to your CI pipeline. It exits non-zero if any file is mis-formatted and prints the path. Most teams pair this with lint-staged + husky to run prettier --write on pre-commit so badly-formatted code never reaches CI in the first place.

Key terms

Prettier

An opinionated code formatter that rewrites JavaScript, TypeScript, CSS, HTML, Markdown, YAML, GraphQL, and more into a canonical style. First released in 2017; the de-facto standard for JS/TS formatting.

.prettierrc

The configuration file Prettier reads to override its defaults. Supports JSON, JSON5, YAML, TOML, JavaScript (CJS/MJS/TS), or a "prettier" key inside package.json. Prettier searches upward from the file being formatted and uses the first match.

Opinionated formatter

A formatter that deliberately exposes few configuration options because its maintainers believe a single canonical style is more useful than per-team customization. Prettier coined this term in JavaScript tooling.

Override

An entry in the overrides array that applies different options to files matching a glob pattern. Used to vary printWidth, tabWidth, or parser per file type.

Plugin

An npm package that extends Prettier with a new parser (e.g., PHP, Astro, Svelte) or post-processes the output (e.g., sorting Tailwind classes, organizing imports). Listed in the plugins config array.

.prettierignore

An ignore file using .gitignore syntax that lists paths Prettier should skip. node_modules is always ignored automatically; build directories, lockfiles, and minified assets must be listed explicitly.

Frequently asked questions

What's the difference between .prettierrc and .prettierrc.json?

Functionally nothing — both are read by Prettier as JSON when their contents start with a { character. The plain .prettierrc (no extension) is a historical convention where Prettier auto-detects the format by parsing: it tries JSON first, then YAML. .prettierrc.json forces the JSON parser explicitly, which makes intent obvious to editors and tooling and gives you better JSON-specific schema validation in VS Code. New projects should prefer the explicit form (.prettierrc.json, .prettierrc.yaml, or .prettierrc.toml) so your editor knows which language server to use and so contributors are not surprised by format auto-detection.

Can .prettierrc have comments?

Only if you use a format that supports comments. Strict JSON (.prettierrc.json or a comment-free .prettierrc) does NOT allow // or /* */ comments — adding one breaks Prettier with a parse error. To document your config inline, switch the file to .prettierrc.json5 (supports both // and /* */), .prettierrc.yaml (supports # comments), or .prettierrc.toml (also #). Another option is a JavaScript config file (prettier.config.js or .prettierrc.js) that exports a plain object — you get full JS comments plus the ability to compute values dynamically. Most teams pick YAML for readability since it has the lowest comment-friction.

What did Prettier 3 change as the default trailingComma?

Prettier 3.0 (released July 2023) flipped the default for trailingComma from "es5" to "all". With "all", Prettier inserts trailing commas everywhere they are syntactically valid — including function parameter lists and function calls, which need ES2017+ to parse. The Prettier team made the switch because (a) ES2017 is now the floor for every modern toolchain, (b) trailing commas produce cleaner git diffs when you add a new argument, and (c) it matches what most large codebases were already overriding to. If you target older runtimes you can opt back in with "trailingComma": "es5" or "trailingComma": "none". This is the single most common surprise when upgrading from Prettier 2.

How do I make Prettier use 2 spaces?

Two spaces is already the Prettier default — tabWidth is 2 and useTabs is false out of the box. You only need to set anything if you want a different indent or to switch to literal tab characters. To force 2 spaces explicitly (helpful when an .editorconfig file in the same repo would otherwise override Prettier), add {"tabWidth": 2, "useTabs": false} to .prettierrc. For 4 spaces, set tabWidth to 4. For tabs, set "useTabs": true (tabWidth then controls how Prettier counts tab width when calculating line wraps, not what it inserts). Note that Prettier reads .editorconfig by default if no .prettierrc value is set — explicit Prettier config wins.

How do I exclude files from Prettier?

Create a .prettierignore file in the project root. It uses the same syntax as .gitignore — one pattern per line, # for comments, ! to un-ignore. Prettier always ignores node_modules and .git automatically, but a generated build directory like dist/ or .next/ needs to be listed explicitly. A typical .prettierignore: node_modules\n.next\ndist\nbuild\ncoverage\npackage-lock.json\npnpm-lock.yaml\n*.min.js. Prettier also respects .gitignore by default when run with --ignore-unknown or when you set "ignorePath" in config. Use prettier --check . to see which files Prettier would touch — it prints anything mis-formatted and exits non-zero, which is what you want in CI.

Can I use Prettier without a config file?

Yes — Prettier works zero-config. Run npx prettier --write . on any directory and it formats every supported file using the built-in defaults (80-column wrap, 2-space indent, double quotes, semicolons, trailing commas everywhere). This is by design: Prettier is an opinionated formatter and the defaults reflect choices the maintainers consider correct. Skipping the config file removes a source of bikeshedding in code reviews and ensures every Prettier-using project on your machine formats the same way. Add a .prettierrc only when you need to override a default (commonly singleQuote, printWidth, or a plugin) or you ship the config to enforce style across a team.

What's the difference between Prettier and ESLint?

Prettier is a formatter — it rewrites code to match a fixed style (whitespace, quotes, line breaks, trailing commas). ESLint is a linter — it analyzes code for problems (unused variables, undefined references, accessibility issues, suspected bugs) and can auto-fix some of them. Use both: ESLint catches errors Prettier does not see, and Prettier handles formatting better and faster than ESLint stylistic rules. Disable ESLint stylistic rules that conflict with Prettier by adding "prettier" to the end of your extends array in .eslintrc (it comes from eslint-config-prettier). The common workflow is prettier --write . to format, then eslint --fix . to catch bugs — or run them together via lint-staged on pre-commit.

How do I run Prettier on every save in VS Code?

Install the Prettier extension (esbenp.prettier-vscode) from the Marketplace, then add two settings to .vscode/settings.json: "editor.defaultFormatter": "esbenp.prettier-vscode" and "editor.formatOnSave": true. Optionally set per-language defaults like "[typescript]": {"editor.defaultFormatter": "esbenp.prettier-vscode"} so Prettier only handles the languages it supports and other formatters (Astro, Svelte) handle theirs. The extension automatically picks up your .prettierrc — no extension-specific config needed. Commit the .vscode/settings.json file so the whole team gets the same editor behavior the moment they open the repo. For CI parity run prettier --check . in your test pipeline.