prettier-plugin-svelte: giving Prettier a Svelte parser

What Prettier cannot parse without it

Prettier formats code by parsing it and printing it back out, and a Svelte component is not something its built-in parsers understand. The HTML parser stops at the component syntax, so this plugin registers a parser that handles the whole file.

The features section describes the coverage. It formats HTML, CSS and JavaScript using Prettier, it formats Svelte syntax such as each loops, if statements and await blocks, and it formats the JavaScript expressions embedded in the Svelte syntax, including expressions inside braces and event bindings such as onclick handlers.

That third item is the one that decides whether the plugin is worth installing. A component is not three languages side by side; it is one file where a script block, a template and a style block are interleaved with expressions that belong to the template's logic. A formatter that treated the template as plain HTML would produce broken or ugly output at every expression boundary, and one that formatted only the script block would leave the rest of the file alone.

The project is MIT licensed, written in TypeScript, published under the name prettier-plugin-svelte, and its most recent release is 4.1.1 from 2026-06-15 after 4.1.0 in June and 4.0.1 in May 2026. The repository's last push was on 2026-07-21.

The version matrix that decides everything else

The compatibility list at the top of the documentation is short and strict, and it is the first thing to check.

The current major version, prettier-plugin-svelte 4, only works with prettier 3 and Svelte 5 or newer. Version 3 only works with prettier 3. Version 2 only works with prettier 2. There is also a separate branch in the repository, the version-3 branch, that holds the documentation for version 3, which is the one compatible with Svelte 4.

That Svelte 5 requirement is not incidental. The README makes the point in its migration notes: upgrade to Svelte 5 before upgrading to version 4 of the plugin, because version 4 does not support older Svelte versions. So the upgrade path for an existing project is a two-step move, framework first and formatter second, and doing them in the other order leaves you with a plugin that will not parse your components.

Two options also disappeared in version 4. The svelteStrictMode option has been removed, and attributes are now never quoted, because that is what the attribute value will mean in a future Svelte version. The svelteBracketNewLine option has been removed too, and the replacement is Prettier's own bracketSameLine option, which is one of the cases where the plugin steps aside and lets the core formatter handle it.

Installing the plugin and formatting from the command line

The package installs as an ordinary development dependency alongside Prettier itself:

npm i --save-dev prettier-plugin-svelte prettier

The plugin then has to be registered with Prettier and pointed at Svelte files. The README's configuration file does both, by listing the plugin in the plugins array and by adding an override that assigns the svelte parser to files matching the svelte extension:

// .prettierrc
{
    // ..
    "plugins": ["prettier-plugin-svelte"],
    "overrides": [{ "files": "*.svelte", "options": { "parser": "svelte" } }],
}

With that in place, formatting the whole project is the standard Prettier command:

npx prettier --write .

The README also shows the same command wired into a package.json script, which is the form most teams end up with because it becomes a single command in the repository:

// package.json
{
    // ..
    "scripts": {
        "format": "prettier --write .",
    },
}

The options are optional, and the README recommends a .prettierrc file over passing flags on the command line, since a checked-in configuration means every developer and every CI run formats the same way.

The three Svelte-specific options

Three settings belong to the plugin rather than to Prettier, and each has a CLI override and an API override in addition to the configuration file key.

The first is svelteSortOrder, which controls the order of the svelte:options block, the script block, the markup and the styles. The default is options-scripts-markup-styles. You join the keywords with a hyphen in the order you want, or set the value to none if you do not want Prettier to reorder anything at all. The CLI form is --svelte-sort-order and the API form is svelteSortOrder. The options keyword only exists from version 2 onwards, so on version 1 of the plugin you write scripts-markup-styles instead.

The second is svelteAllowShorthand, which enables or disables component attribute shorthand when the attribute name and the expression are the same. The default is true, the CLI override is --svelte-allow-shorthand and the API override is svelteAllowShorthand. With it enabled an input element can be written as a shorthand binding, and with it disabled the explicit form is written instead.

The third is svelteIndentScriptAndStyle, which controls whether the code inside script and style tags is indented. The default is true, and the CLI and API forms follow the same pattern. The README is honest about the trade-off: turning off the indentation saves a level of nesting but might break code folding in your editor.

All three fit in a configuration file like this:

{
    "svelteSortOrder": "options-styles-scripts-markup",
    "svelteAllowShorthand": false,
    "svelteIndentScriptAndStyle": false
}

Plugin ordering and the Tailwind case

If your project also uses the Tailwind Prettier plugin, the two have to be loaded in a specific order, and the README is explicit that the Tailwind plugin must come last:

// .prettierrc
{
    // ..
    "plugins": [
        "prettier-plugin-svelte",
        "prettier-plugin-tailwindcss", // MUST come last
    ],
}

The reason is that the Tailwind plugin rewrites class attribute values, so it has to see the class lists after the Svelte parser has produced them. Get the order wrong and the class sorting silently does nothing, which is the kind of failure that looks like a Tailwind bug rather than a configuration one.

The same section raises a second problem that only appears once you use configuration overrides: the Prettier VS Code extension decides which files to handle using its own document selectors, so it needs to be told about Svelte files in the editor settings:

// settings.json
{
    // ..
    "prettier.documentSelectors": ["**/*.svelte"],
}

Between these two, the plugin in the configuration file and the selector in the editor settings, a Svelte project ends up with formatting configured in three places: the .prettierrc, the editor settings, and the format-on-save behaviour of the extension.

The bundled VS Code extension and the browser build

There are two ways to get the plugin, and they differ in what you have to configure.

The plugin is bundled in the Svelte for VS Code extension. If you only format through the editor, the README says you therefore do not need to do anything in addition. The extension lets you define options through extension-specific configuration, with one significant caveat: those settings are ignored if any configuration file such as a .prettierrc is present. So the convenient per-user options silently stop applying the moment a project checks in a configuration file, which is the moment most teams decide they want a shared configuration anyway.

Installing the plugin as a package is what buys you control over the formatting behaviour, command line formatting, the use of a different IDE, and the ability to use the official Prettier VS Code extension to format Svelte files rather than relying on the Svelte extension.

There is also a browser build, and the README describes it as semi-supported. The package exports a browser entry point, prettier-plugin-svelte/browser, which depends on prettier/standalone and therefore uses no Node APIs. What is not supported well is using it without a build step: you still need a bundler such as Vite to assemble everything into one self-contained package in advance. So the browser build is for applications that already bundle, not for a script tag.

Where the output can surprise you

The documentation ends with an FAQ that answers the question every new user asks, which is why the formatter sometimes produces output that looks broken.

The example is a nested span. Written plainly as a span containing a span containing long text, the formatter rewrites it with the angle brackets split across lines, with the closing bracket of the inner element pushed onto its own line and the indentation arranged so the structure is visible. The README explains that this is caused by whitespace sensitivity: for inline elements such as span and a, it makes a difference when rendered whether there is a space or a newline between the tags, so the formatter preserves the exact whitespace and adjusts the line breaks around it.

The result is correct but visually startling if you have not seen it before, and it is worth knowing that a diff full of split brackets is the plugin doing its job rather than a misconfiguration.

The other rough edge is the indentation option. Turning off indentation for script and style blocks saves a level of nesting, and the README warns it might break code folding in your editor, which is a real cost for people who rely on folding long components.

A third consideration is scope rather than behaviour. The plugin formats; it does not lint. It will not tell you that a Svelte pattern is discouraged, and it will not reorder imports or rename anything. If you are expecting one tool to keep a Svelte codebase tidy, Prettier with this plugin is the formatting half of that job and something else has to cover the rest.

Maintenance, build tooling and licence

The repository uses the modern toolchain for a Prettier plugin: Rollup for the bundle, with the build script running rollup -c and the published files being plugin.js, its source map, browser.js and index.d.ts. The package exports the main entry and the browser entry separately, which is what makes the standalone browser build possible.

Tests run under ava, with an ava.config.js in the repository and a wallaby.js for the live-reload test runner. Type checking is a separate script running tsc with noEmit, and the repository formats itself with Prettier, since the lint script runs prettier --check . and the format script runs prettier --write .

Releases are managed with changesets, through the .changeset directory and the changeset version and changeset publish scripts, with the changelog generated by a Svelte-specific changelog plugin. The package requires Node 20 or newer, the licence is MIT with a LICENSE file at the root, and the author listed in the metadata is James Birtles.

The last push was on 2026-07-21 and the newest release is 4.1.1 from 2026-06-15, so the project is being maintained on a steady cadence rather than abandoned, and the compatibility matrix is narrow by design: three plugin majors against two Prettier majors and two Svelte majors is a small surface to keep working.

Editorial conclusion

Adopt prettier-plugin-svelte if your project formats Svelte files and you want the formatting rules for templates, scripts, styles and embedded expressions to come from one place rather than from hand-maintained ignore rules. Do not adopt version 4 on Svelte 4, since the plugin refuses that combination, and do not expect the browser build to drop the bundler requirement. Verify first that your Svelte major version matches the plugin major version, that the parser override for svelte files is present in your Prettier configuration, and that the plugins array keeps any Tailwind plugin last, since the README states it must come last.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sveltejs/prettier-plugin-svelte on GitHub