Prettier is an opinionated code formatter that enforces consistent style by parsing code and reprinting it according to its own rules, while ESLint handles code quality — using both together eliminates style debates and catches real bugs.
Prettier parses code into an AST and reprints it from scratch, guaranteeing consistent output regardless of the original formatting.
Prettier handles stylistic formatting (indentation, quotes, semicolons); ESLint handles code quality (bugs, unused variables, best practices). They solve different problems.
Prettier's deliberately limited options eliminate formatting debates — teams adopt consistent style without bikeshedding over subjective preferences.
Use eslint-config-prettier to disable conflicting ESLint rules, format-on-save in the editor, lint-staged for pre-commit hooks, and CI checks as a final guardrail.
Code formatting seems trivial, but inconsistent style creates noisy diffs, slows code reviews, and causes endless team debates about tabs vs spaces, semicolons, and trailing commas. Prettier solves this by being deliberately opinionated — it provides very few configuration options, forcing teams to adopt a consistent style without bikeshedding.
Unlike a linter that flags issues, Prettier is a code printer. It parses your code into an AST (Abstract Syntax Tree), completely discards the original formatting, and reprints the code according to its own rules. This means Prettier does not care how your code looked before — it always produces the same output for the same AST. This "parse and reprint" approach is fundamentally different from ESLint's "find and fix" approach, which is why Prettier handles formatting more consistently.
Prettier vs ESLint: Different Responsibilities
This is the most common interview question about formatting. ESLint and Prettier serve different purposes: Prettier handles formatting — indentation, line breaks, quote style, semicolons, bracket spacing, trailing commas. These are stylistic choices with no impact on code behavior. ESLint handles code quality — unused variables, missing error handling, incorrect API usage, accessibility violations. These catch actual bugs and enforce best practices. The key distinction: Prettier makes code look consistent; ESLint makes code work correctly.
The recommended setup uses eslint-config-prettier to disable all ESLint formatting rules that would conflict with Prettier. This way, Prettier handles all formatting and ESLint focuses exclusively on code quality. The older approach of running Prettier as an ESLint plugin (eslint-plugin-prettier) is discouraged because it is slower and produces confusing error messages for formatting issues.
Prettier intentionally offers very few options: printWidth (line length), tabWidth, useTabs, semi (semicolons), singleQuote, trailingComma, bracketSpacing, and a few others. This minimal configuration is a feature, not a limitation. By removing choices, Prettier eliminates formatting debates entirely. The team does not need to agree on style — they just use Prettier's defaults. Any time spent arguing about formatting is time not spent on product features.
The most effective Prettier workflow uses format-on-save in your editor. Configure your IDE to run Prettier automatically when you save a file. This means you never think about formatting — write code however you like, hit save, and Prettier fixes it instantly. Combined with a CI check that verifies formatting (prettier --check .), this ensures no unformatted code reaches the repository.
Tools like lint-staged with husky run Prettier on staged files before each commit, catching formatting issues at the commit level. This is a safety net for developers who forget to set up format-on-save. The CI check serves as the final guardrail.
Prettier is a formatter (makes code look consistent), ESLint is a linter (finds bugs and enforces quality). Use both: Prettier for style, ESLint for quality. Disable ESLint's formatting rules with eslint-config-prettier to avoid conflicts. The opinionated nature of Prettier is its greatest strength — it eliminates style debates entirely.
Fun Fact
Prettier was created by James Long in 2017 after he was inspired by the refmt tool in the Reason/OCaml ecosystem. Within two years, it had been adopted by most major JavaScript projects including React, Vue, Angular, and Babel — effectively ending the JavaScript community's decades-long formatting wars.