Prettier 11 🎨 The -parser Flag — Overriding auto-detection - KandZ

⏱️ Estimated read: 9 min | |

Prettier infers the parser from the file extension by default. The --parser flag overrides that inference and forces Prettier to use a specific parser for the files it processes. It exists for the cases where the extension is missing, ambiguous, or misleading: a file piped through stdin has no extension, a .html file may be an Angular template rather than standard HTML, and a .json file may contain JSON5 syntax rather than strict JSON. The flag is a targeted override, not a global configuration. The Prettier documentation is explicit about the difference: the parser option belongs inside overrides in a configuration file, never at the top level, because a top-level parser disables inference for every file type .

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

This chapter covers the --parser flag, the --stdin-filepath alternative that preserves inference for piped input, the parser values that matter for the common file types, and the rule that separates the CLI flag from the configuration option.

Key point: The --parser flag applies to the invocation, not to the project. It is the correct tool for a one-off format of a file with an ambiguous extension, or for a piped stream that has no filename. For a recurring pattern, the overrides block in the configuration file is the correct mechanism.

Why the flag exists alongside inference

The extension problem. Prettier’s default behavior is to look at the file extension and select the parser that the language definitions associate with it. A .ts file uses the typescript parser, a .css file uses the css parser, and a .md file uses the markdown parser. This inference is what makes prettier --write . work without any configuration . The flag is only needed when the inference produces the wrong result or no result at all.

The stdin problem. A file piped through stdin has no extension unless the caller provides one. The cat foo.css | prettier invocation leaves Prettier with no way to infer the parser, and the command fails or produces an error about the missing parser. The --stdin-filepath flag is the recommended fix: it tells Prettier the path the input “pretends” to come from, and Prettier infers the parser from that path . The --parser flag is the fallback when there is no path to provide.

The ambiguity problem. The .html extension is the most common case. Prettier defaults to the standard HTML parser, but an Angular component template or a Lightning Web Component uses a different parser. The --parser angular flag forces the Angular parser for that invocation. The same applies to a .json file that contains comments or trailing commas: the json parser fails, and the json5 parser accepts the syntax .

a. The flag and its values

The flag is passed on the command line, followed by the parser name.

# Force the CSS parser for a file with an ambiguous extension
prettier --parser css ./styles.tpl

# Force the TypeScript parser
prettier --parser typescript ./script.custom

The parser names are the same names that appear in the parser option of the API and the configuration file. The common values are babel (JavaScript), typescript (TypeScript), css, scss, less, html, vue, markdown, mdx, json, json5, yaml, and graphql . A plugin can add parsers for other languages, and the --parser flag can reference a parser that the plugin provides.

The flag is not the same as the filepath option in the API. The filepath option provides a path and lets Prettier infer the parser from it. The --parser flag provides the parser directly and ignores the extension. The --stdin-filepath flag is the CLI equivalent of the filepath option, and it is the preferred approach when the input is a file with a known name .

b. The stdin-filepath alternative

The --stdin-filepath flag is the recommended mechanism for piped input because it preserves the inference behavior and the configuration overrides that depend on the file path.

# Recommended: provide the path, infer the parser
cat foo.css | prettier --stdin-filepath foo.css

# Fallback: provide the parser directly
cat foo.css | prettier --parser css

The difference matters when the project has an overrides block that applies a specific parser to a specific file pattern. The --stdin-filepath value is matched against the overrides patterns, and the matching override’s parser is used. The --parser flag bypasses the overrides entirely and forces the specified parser for the stream .

The --stdin-filepath flag is only useful in the CLI and the API. It does not make sense in a configuration file, because a configuration file describes the project, not the individual invocation .

c. The configuration rule

The parser option can be set in the configuration file, but only inside an overrides entry that scopes it to a file pattern. A top-level parser is a misconfiguration: it forces every file through the specified parser, including the CSS files that should use the CSS parser and the JSON files that should use the JSON parser .

{
  "overrides": [
    {
      "files": "*.component.html",
      "options": { "parser": "angular" }
    }
  ]
}

The --parser flag is the CLI equivalent of the overrides entry, but it applies to the entire invocation. It is appropriate for a one-off command, not for a recurring pattern. A project that regularly formats Angular templates should put the override in the configuration file, so that the CLI, the editor, and the CI pipeline all apply the same parser .

Complete Example Session

# ============================================
# PART 1: THE INFERENCE DEFAULT
# ============================================
prettier ./src/app.ts
# The typescript parser is inferred from the extension.

# ============================================
# PART 2: THE AMBIGUOUS EXTENSION
# ============================================
prettier --parser css ./styles.tpl
# The css parser is forced for the .tpl file.

# ============================================
# PART 3: THE ANGULAR TEMPLATE
# ============================================
prettier --parser angular ./app.component.html
# The angular parser is forced instead of the html parser.

# ============================================
# PART 4: THE JSON5 FILE
# ============================================
prettier --parser json5 ./config.json
# The json5 parser accepts comments and trailing commas.

# ============================================
# PART 5: THE STDIN WITH FILEPATH
# ============================================
cat foo.css | prettier --stdin-filepath foo.css
# The css parser is inferred from the provided path.

# ============================================
# PART 6: THE STDIN WITHOUT FILEPATH
# ============================================
cat foo.css | prettier --parser css
# The parser is provided directly.

// ============================================
// PART 7: THE OVERRIDES CONFIGURATION
// ============================================
{
  "overrides": [
    { "files": "*.component.html", "options": { "parser": "angular" } }
  ]
}

// ============================================
// PART 8: THE TOP-LEVEL MISTAKE
// ============================================
{
  "parser": "babel"
}
// Every file is parsed as JavaScript.

# ============================================
# PART 9: THE VERIFICATION
# ============================================
prettier --parser css ./styles.tpl --check

# ============================================
# PART 10: THE DECISION
# ============================================
# One-off with ambiguous extension? → --parser
# Piped input with a path? → --stdin-filepath
# Recurring pattern? → overrides in config

The ten parts covered the inference default, the ambiguous extension, the Angular template, the JSON5 file, the stdin with filepath, the stdin without filepath, the overrides configuration, the top-level mistake, the verification, and the decision.

Quick Reference

The flag

Flag	Effect
`--parser <name>`	Force the parser for the invocation
`--stdin-filepath <path>`	Infer the parser from the provided path

Common parser names

Name	Language
`babel`	JavaScript
`typescript`	TypeScript
`css`	CSS
`scss`	SCSS
`less`	Less
`html`	HTML
`angular`	Angular templates
`vue`	Vue SFC
`markdown`	Markdown
`json`	JSON
`json5`	JSON5
`yaml`	YAML

The rule

Location	Allowed
CLI flag	Yes
`overrides[].options.parser`	Yes
Top-level `parser`	No (disables inference)

The stdin choice

Situation	Flag
Piped input with a known path	`--stdin-filepath`
Piped input with no path	`--parser`

Best Practices

✅ Do This:

# Use --parser for a one-off ambiguous extension
prettier --parser css ./styles.tpl                            # ✅

# Use --stdin-filepath for piped input with a known path
cat foo.css | prettier --stdin-filepath foo.css               # ✅

// Use overrides for a recurring pattern
{ "overrides": [{ "files": "*.component.html", "options": { "parser": "angular" } }] } // ✅

❌ Don’t Do This:

// Put parser at the top level
{ "parser": "babel" }                                         // ❌

# Use --parser when the extension is already correct
prettier --parser typescript ./app.ts                         // ❌ (redundant)

# Pipe without a filepath or parser
cat foo.css | prettier                                        // ❌ (no parser)

Common Pitfalls

Pitfall	Why It Happens	Fix
CSS file parsed as JavaScript	Top-level `parser: "babel"`	Move the parser into `overrides`
Stdin fails with no parser	No `--stdin-filepath` and no `--parser`	Add one of the flags
Overrides not applied to stdin	`--parser` bypasses the overrides	Use `--stdin-filepath`
JSON5 syntax fails with the JSON parser	The `json` parser is strict	Use `--parser json5`
Angular template formatted as HTML	Default `.html` parser	Use `--parser angular` or an override

Real-World Examples

1. Force the CSS parser

prettier --parser css ./styles.tpl

2. Force the Angular parser

prettier --parser angular ./app.component.html

3. Force the JSON5 parser

prettier --parser json5 ./config.json

4. Stdin with filepath

cat foo.css | prettier --stdin-filepath foo.css

5. Stdin with parser

cat foo.css | prettier --parser css

6. The overrides configuration

{ "overrides": [{ "files": "*.component.html", "options": { "parser": "angular" } }] }

7. The top-level mistake

{ "parser": "babel" }

8. The verification

prettier --parser css ./styles.tpl --check

9. The inference default

prettier ./app.ts

10. The decision

One-off → --parser; Piped → --stdin-filepath; Recurring → overrides

Visual

The inference and the override

┌─────────────────────────────────────────────────────────────┐
│  DEFAULT                                                     │
│    prettier ./app.ts                                         │
│       │                                                      │
│       ▼                                                      │
│  Extension .ts ──► typescript parser                         │
│                                                              │
│  OVERRIDE                                                    │
│    prettier --parser css ./styles.tpl                        │
│       │                                                      │
│       ▼                                                      │
│  Parser forced to css, extension ignored                     │
└─────────────────────────────────────────────────────────────┘

The stdin choice

┌─────────────────────────────────────────────────────────────┐
│  cat foo.css | prettier --stdin-filepath foo.css             │
│    → path provided, parser inferred from .css               │
│                                                              │
│  cat foo.css | prettier --parser css                         │
│    → parser provided directly, no path needed                │
│                                                              │
│  cat foo.css | prettier                                      │
│    → no path, no parser, error                               │
└─────────────────────────────────────────────────────────────┘

The configuration rule

┌─────────────────────────────────────────────────────────────┐
│  CORRECT                        WRONG                        │
│                                                              │
│  {                              {                            │
│    "overrides": [                 "parser": "babel"          │
│      {                                                       │
│        "files": "*.component.html",                          │
│        "options": { "parser": "angular" }                    │
│      }                                                       │
│    ]                                                         │
│  }                              }                            │
│                                                              │
│  Scoped to the pattern          Forces every file            │
└─────────────────────────────────────────────────────────────┘

The parser values

┌─────────────────────────────────────────────────────────────┐
│  babel         typescript      css         scss              │
│  less          html            angular     vue               │
│  markdown      mdx             json        json5             │
│  yaml          graphql                                       │
└─────────────────────────────────────────────────────────────┘

Summary

Item	Value
Flag	`--parser <name>`
Purpose	Force a parser for the invocation
Default	Inferred from the file extension
Stdin alternative	`--stdin-filepath <path>`
Configuration location	`overrides[].options.parser`
Top-level parser	Disables inference (misconfiguration)
Common values	`babel`, `typescript`, `css`, `html`, `json`, `json5`

Key takeaways:

The --parser flag overrides the extension-based inference for the invocation. It is the tool for an ambiguous extension, a non-standard file type, or a piped stream without a filename. The inference remains the default and the correct choice for the files with standard extensions .
--stdin-filepath is the preferred flag for piped input. It provides the path that the stream pretends to come from, and Prettier infers the parser from that path. It also allows the overrides configuration to apply, which the --parser flag bypasses .
The parser option belongs inside overrides in a configuration file. A top-level parser disables the inference for every file type, which is the source of the “CSS file parsed as JavaScript” error. The CLI flag is the equivalent of an override for a single invocation .
The parser names are the same names that the API and the configuration use. The common values cover the languages that Prettier supports by default. A plugin can add a parser for another language, and the flag can reference it.
The flag is not a substitute for the configuration. A recurring pattern—an Angular template directory, a JSON5 configuration file—should be handled with an overrides entry, so that the CLI, the editor, and the CI pipeline all apply the same parser.

Remember: Prettier’s default is to infer the parser from the file extension. The --parser flag is the override for the cases where the inference is wrong or impossible. Use --stdin-filepath for piped input with a known path, --parser for a one-off ambiguous file, and overrides for a recurring pattern. And never put parser at the top level of the configuration, because that turns a targeted override into a global misconfiguration.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!