bracketSameLine — where the closing angle bracket of a multi-line tag lands

What the option does

It applies only when a tag has been broken across several lines because its attributes do not fit on one. The default puts the > on a line of its own, aligned with the opening <:

<button
  type="submit"
  disabled={busy}
>
  Save
</button>

<button
  type="submit"
  disabled={busy}>
  Save
</button>

Why the default is false

With the bracket on its own line, every attribute line has the same shape, and the > becomes a clear visual boundary between the tag and its children. In deeply nested markup that boundary is doing real work — it is the difference between seeing where a tag ends and counting indentation.

There is a diff argument too, the same one that motivates trailing commas. When the > is attached to the last attribute, adding a new attribute at the end modifies that line as well as adding one. With the bracket on its own line, adding an attribute changes exactly one line.

The case for true

true is more compact, and for markup-heavy code that difference accumulates — a page of components can be noticeably shorter. It also reads closer to how hand-written HTML is often formatted, which some teams prefer for template files.

If you choose it, be aware it applies to HTML and Vue templates as well as JSX. There is no way to set it differently per language short of an overrides block in your configuration.

The rename in Prettier 2.4

This option was called jsxBracketSameLine until Prettier 2.4, when it was renamed and widened to cover HTML and Vue as well as JSX. The old name was deprecated then and removed in Prettier 3.

If you are upgrading from an old configuration and the setting seems to be ignored, check for the old key — Prettier 3 will not honour it.

Common mistakes

• •Confusing it with bracketSpacing, which is about spaces inside object braces and shares nothing but a prefix.
• •Leaving jsxBracketSameLine in a config after upgrading to Prettier 3, where it is silently unrecognised.
• •Expecting it to affect single-line tags. It only applies once a tag has already been split.
• •Expecting it to apply to self-closing tags in the same way — the /> follows related but distinct rules.

Self-closing tags follow a different rule

The option covers the > of an opening tag. A self-closing element ends in />, and that is placed on its own line when the element is broken, regardless of this setting:

<input
  type="email"
  required
/>

The reasoning is that /> closes the element rather than merely ending the tag, so attaching it to the last attribute would obscure where the element finishes. In JSX, where self-closing components are extremely common, this means the option affects fewer elements than people expect.

Scoping it per language

Because the option applies to JSX, HTML and Vue alike, a repository containing both React components and hand-written HTML templates gets one answer for both. If the two genuinely want different conventions, an overrides block is the only way to separate them:

{
  "bracketSameLine": false,
  "overrides": [
    {
      "files": "*.html",
      "options": { "bracketSameLine": true }
    }
  ]
}

Consider whether the split is worth it. Two conventions in one repository is a cost paid by every reader, and the saving is one line per broken tag.