singleAttributePerLine — one attribute per line, for markup diffs that read like code diffs

What the option does

The default is false, so Prettier packs as many attributes onto each line as printWidth allows, breaking only when it must. Set it to true and each attribute gets its own line whenever the tag is broken at all.

<input
  type="email"
  name="email"
  required
  autoComplete="email"
/>

A tag short enough to stay on one line is left alone. The option changes how a broken tag is laid out, not whether it breaks.

Why it helps reviews

When attributes share lines, the line a change lands on is an accident of width. Add one attribute near the front and the packing shifts, so several lines change even though the meaning of only one did.

One attribute per line makes the mapping exact: one attribute, one line, one diff entry. Adding, removing or editing an attribute produces precisely the diff a reader expects, and git blame attributes each attribute to the commit that introduced it.

This matters most on components with many props, which is where reviews are hardest and where the packed form is least predictable.

The cost

• •Files get considerably taller. A form-heavy component can grow by half again, and less fits on screen.
• •Short tags with two small attributes look over-formatted when they break at all.
• •It compounds with bracketSameLine: false, which adds another line per tag — the default combination is the most vertical of the four.

Whether that is worth it depends on how your team works. Codebases reviewed heavily in pull requests tend to conclude that it is; codebases read mostly in an editor often conclude it is not.

Common mistakes

• •Expecting single-line tags to be split. The option only governs tags that are already breaking.
• •Enabling it mid-project without a dedicated reformat commit — it touches every multi-attribute element in the codebase.
• •Assuming it is JSX-only. It applies to HTML and Vue templates as well.

How it combines with the other markup options

Three options together decide the shape of a broken tag, and their effects compound:

• •printWidth decides whether the tag breaks at all. A short tag is unaffected by anything else here.
• •singleAttributePerLine decides whether the attributes share lines once it has broken.
• •bracketSameLine decides whether the closing > gets its own line as well.

The default combination — singleAttributePerLine: false, bracketSameLine: false — packs attributes but isolates the bracket. Turning the first on gives the tallest and most diff-stable layout; turning the second on as well recovers one line per tag at some cost to that stability.

{
  "singleAttributePerLine": true,
  "bracketSameLine": false
}

What it does not override

A // prettier-ignore or <!-- prettier-ignore --> before an element still wins — the element is left exactly as written, attributes and all. That is the escape hatch for the occasional tag whose hand-arrangement genuinely carries meaning, such as a table of coordinates expressed as props.

The option also does not force a break. An element with two short attributes that fits comfortably stays on one line, which surprises people who expect the name to mean one attribute per line unconditionally.

Who tends to turn it on

Adoption splits fairly cleanly along how a team reads code. Design-system and component-library repositories tend to enable it, because their components carry many props, those props change often, and reviews are about exactly which prop changed.

Application code with lighter markup tends to leave it off, because most elements have one or two attributes and the packed form already puts each meaningful change on its own line.

A useful test: look at a recent pull request touching your markup and ask how many of the changed lines changed meaningfully. If packing is putting unrelated attributes on the same line as your edit, the option will pay for its vertical cost.