Markdown Formatter

What the formatter fixes

• List markers. *, -, + all get normalised to one consistent character (default -).
• Heading hierarchy. Warns (or promotes) when H2 is followed by H4 with no H3 in between.
• Blank lines. Exactly one blank line between blocks; no runs of three or more.
• Tables. Pads each column so the pipes align in the source, even though Markdown renderers don’t care.
• Trailing whitespace. Strips trailing spaces on every line except the intentional two-space line-break marker.
• Reference links. Collects [label]: url definitions at the end of the document, sorted alphabetically.
• Code fences. Language tag is normalised to lowercase; indent-based code blocks become fenced blocks.

Style options you can set

Why consistent Markdown matters

In a team repo, inconsistent Markdown produces noisy diffs: every time someone saves a file with a different editor, list markers swap and tables reflow. A formatter enforces one style so pull request reviewers see only content changes. Think of it as prettier for prose.

When not to format

• Fenced code blocks stay byte-for-byte intact, the formatter will never touch the contents of a code block. If formatting changes code, it’s a bug.
• Intentional hard wraps at narrow widths (readme.md on a terminal project) get re-wrapped if you enable the wrap column. Disable wrap if you keep hand-tuned line breaks.
• Embedded HTML blocks pass through unchanged.

Drop-in replacements

If you prefer a local CLI, the formatter uses the same AST rules as remark-stringify with the remark-gfm plugin. prettier --parser markdown produces a similar result.