markdownlint

Markdown/CommonMark linting and style checking for Visual Studio Code

Introduction

The Markdown markup language is designed to be easy to read, write, and understand. It succeeds - and its flexibility is both a benefit and a drawback. Many styles are possible, so formatting can be inconsistent. Some constructs don't work well in all parsers and should be avoided. For example, here are some common/troublesome Markdown constructs.

markdownlint is an extension for the Visual Studio Code editor that includes a library of rules to encourage standards and consistency for Markdown files. It is powered by the markdownlint library for Node.js (which was inspired by markdownlint for Ruby). Linting is performed by the markdownlint-cli2 engine, which can be used in conjunction with this extension to provide command-line support for scripts and continuous integration scenarios. The markdownlint-cli2-action GitHub Action uses the same engine and can be integrated with project workflows. For more, see the Interoperability section below.

Install

1. Open Visual Studio Code
2. Press Ctrl+P/Ctrl+P/⌘P to open the Quick Open dialog
3. Type ext install markdownlint to find the extension
4. Click the Install button, then the Enable button

OR

1. Press Ctrl+Shift+X/Ctrl+Shift+X/⇧⌘X to open the Extensions tab
2. Type markdownlint to find the extension
3. Click the Install button, then the Enable button

OR

1. Open a command-line prompt
2. Run code --install-extension DavidAnson.vscode-markdownlint

Use

When editing a Markdown file in VS Code with markdownlint installed, any lines that violate one of markdownlint's rules (see below) will trigger a Warning in the editor. Warnings are indicated by a wavy green underline and can also be seen by pressing Ctrl+Shift+M/Ctrl+Shift+M/⇧⌘M to open the Errors and Warnings dialog. Hover the mouse pointer over a green line to see the warning or press F8 and Shift+F8/Shift+F8/⇧F8 to cycle through all the warnings (markdownlint warnings all begin with MD###). For more information about a markdownlint warning, place the cursor on a line and click the light bulb icon or press Ctrl+./Ctrl+./⌘. to open the quick fix dialog. Clicking one of the warnings in the dialog will display that rule's help entry in the default web browser.

For a tutorial, please see Build an Amazing Markdown Editor Using Visual Studio Code and Pandoc by Dave Johnson.

By default, markdownlint will scan and report issues for files that VS Code treats as Markdown. You can see what language mode the current file has in the Status Bar at the bottom of the window and you can change the language mode for the current file. If you have a custom file type that VS Code should always treat as Markdown, you can associate that file extension with the markdown language identifier.

Rules

• MD001 heading-increment - Heading levels should only increment by one level at a time
• MD003 heading-style - Heading style
• MD004 ul-style - Unordered list style
• MD005 list-indent - Inconsistent indentation for list items at the same level
• MD007 ul-indent - Unordered list indentation
• MD009 no-trailing-spaces - Trailing spaces
• MD010 no-hard-tabs - Hard tabs
• MD011 no-reversed-links - Reversed link syntax
• MD012 no-multiple-blanks - Multiple consecutive blank lines
• MD013 line-length - Line length
• MD014 commands-show-output - Dollar signs used before commands without showing output
• MD018 no-missing-space-atx - No space after hash on atx style heading
• MD019 no-multiple-space-atx - Multiple spaces after hash on atx style heading
• MD020 no-missing-space-closed-atx - No space inside hashes on closed atx style heading
• MD021 no-multiple-space-closed-atx - Multiple spaces inside hashes on closed atx style heading
• MD022 blanks-around-headings - Headings should be surrounded by blank lines
• MD023 heading-start-left - Headings must start at the beginning of the line
• MD024 no-duplicate-heading - Multiple headings with the same content
• MD025 single-title/single-h1 - Multiple top level headings in the same document
• MD026 no-trailing-punctuation - Trailing punctuation in heading
• MD027 no-multiple-space-blockquote - Multiple spaces after blockquote symbol
• MD028 no-blanks-blockquote - Blank line inside blockquote
• MD029 ol-prefix - Ordered list item prefix
• MD030 list-marker-space - Spaces after list markers
• MD031 blanks-around-fences - Fenced code blocks should be surrounded by blank lines
• MD032 blanks-around-lists - Lists should be surrounded by blank lines
• MD033 no-inline-html - Inline HTML
• MD034 no-bare-urls - Bare URL used
• MD035 hr-style - Horizontal rule style
• MD036 no-emphasis-as-heading - Emphasis used instead of a heading
• MD037 no-space-in-emphasis - Spaces inside emphasis markers
• MD038 no-space-in-code - Spaces inside code span elements
• MD039 no-space-in-links - Spaces inside link text
• MD040 fenced-code-language - Fenced code blocks should have a language specified
• MD041 first-line-heading/first-line-h1 - First line in file should be a top level heading
• MD042 no-empty-links - No empty links
• MD043 required-headings - Required heading structure
• MD044 proper-names - Proper names should have the correct capitalization
• MD045 no-alt-text - Images should have alternate text (alt text)
• MD046 code-block-style - Code block style
• MD047 single-trailing-newline - Files should end with a single newline character
• MD048 code-fence-style - Code fence style
• MD049 emphasis-style - Emphasis style should be consistent
• MD050 strong-style - Strong style should be consistent
• MD051 link-fragments - Link fragments should be valid
• MD052 reference-links-images - Reference links and images should use a label that is defined
• MD053 link-image-reference-definitions - Link and image reference definitions should be needed
• MD054 link-image-style - Link and image style
• MD055 table-pipe-style - Table pipe style
• MD056 table-column-count - Table column count
• MD058 blanks-around-tables - Tables should be surrounded by blank lines
• MD059 descriptive-link-text - Link text should be descriptive
• MD060 table-column-style - Table column style

See markdownlint's Rules.md file for more details.

The following rules can be automatically fixed by moving the cursor to a rule violation (wavy underlined text) and typing Ctrl+./Ctrl+./⌘. or clicking the light bulb icon.

• MD004 ul-style
• MD005 list-indent
• MD007 ul-indent
• MD009 no-trailing-spaces
• MD010 no-hard-tabs
• MD011 no-reversed-links
• MD012 no-multiple-blanks
• MD014 commands-show-output
• MD018 no-missing-space-atx
• MD019 no-multiple-space-atx
• MD020 no-missing-space-closed-atx
• MD021 no-multiple-space-closed-atx
• MD022 blanks-around-headings
• MD023 heading-start-left
• MD026 no-trailing-punctuation
• MD027 no-multiple-space-blockquote
• MD030 list-marker-space
• MD031 blanks-around-fences
• MD032 blanks-around-lists
• MD034 no-bare-urls
• MD037 no-space-in-emphasis
• MD038 no-space-in-code
• MD039 no-space-in-links
• MD044 proper-names
• MD047 single-trailing-newline
• MD049 emphasis-style
• MD050 strong-style
• MD051 link-fragments
• MD053 link-image-reference-definitions
• MD054 link-image-style
• MD058 blanks-around-tables

Commands

Fix

All of a document's violations of the automatically-fixable rules above can be fixed for you.

markdownlint registers itself as a source code formatter for Markdown files and can be invoked by the Format Document/editor.action.formatDocument and Format Selection/editor.action.formatSelection commands, either from the Command Palette (via View|Command Palette... or Ctrl+Shift+P/Ctrl+Shift+P/⇧⌘P) or via the default key bindings of Shift+Alt+F/Ctrl+Shift+I/⇧⌥F (to format the document) and Ctrl+K Ctrl+F/Ctrl+K Ctrl+F/⌘K ⌘F (to format the selection). To automatically format when saving or pasting into a Markdown document, configure Visual Studio Code's editor.formatOnSave or editor.formatOnPaste settings like so:

"[markdown]": {
    "editor.formatOnSave": true,
    "editor.formatOnPaste": true
},

markdownlint also contributes the markdownlint.fixAll command which fixes a document's violations in one step and can be run from the Command Palette or by binding the command to a keyboard shortcut. To automatically fix violations when saving a Markdown document, configure Visual Studio Code's editor.codeActionsOnSave setting like so:

"editor.codeActionsOnSave": {
    "source.fixAll.markdownlint": "explicit"
}

Automatically-applied fixes from either method can be reverted by Edit|Undo or Ctrl+Z/Ctrl+Z/⌘Z.

Workspace

To lint all Markdown files in the current workspace, run the markdownlint.lintWorkspace command (from the Command Palette or by binding it to a keyboard shortcut). This will use markdownlint-cli2, the same engine that powers the extension, to lint all files and output the results to a new terminal in the "Terminal" panel. Results will also appear in the "Problems" panel (Ctrl+Shift+M/Ctrl+Shift+M/⇧⌘M) because of the problem matcher included with the extension. Entries in the "Problems" panel can be clicked to open the corresponding file in the editor. To customize the files that are included/excluded when linting a workspace, configure the markdownlint.lintWorkspaceGlobs setting (see below) at workspace or user scope.

Disable

To temporarily disable linting of Markdown documents, run the markdownlint.toggleLinting command (from the Command Palette or by binding it to a keyboard shortcut). To re-enable linting, run the markdownlint.toggleLinting command again.

Note: The effects of the markdownlint.toggleLinting command are reset when a new workspace is opened; linting defaults to enabled.

Configure

By default (i.e., without customizing anything), all rules are enabled except MD013/line-length because many files include lines longer than the conventional 80 character limit:

{
    "MD013": false
}

Rules can be enabled, disabled, and customized by creating a JSON file named .markdownlint.jsonc/.markdownlint.json or a YAML file named .markdownlint.yaml/.markdownlint.yml or a JavaScript file named .markdownlint.cjs/.markdownlint.mjs in any directory of a project. Additionally, options (which include rules and other settings) can be configured by creating a JSON file named .markdownlint-cli2.jsonc or a YAML file named .markdownlint-cli2.yaml or a JavaScript file named .markdownlint-cli2.cjs/.markdownlint-cli2.mjs in any directory of a project. Rules can also be configured using VS Code's support for user and workspace settings.

For more information about configuration file precedence and complete examples, see the Configuration section of the markdownlint-cli2 README.md.

A custom rule configuration is often defined by a .markdownlint.json file in the root of the project:

{
    "MD003": { "style": "atx_closed" },
    "MD007": { "indent": 4 },
    "no-hard-tabs": false
}

To extend another configuration file, use the extends property to provide a relative path:

{
    "extends": "../.markdownlint.json",
    "no-hard-tabs": true
}

Files referenced via extends do not need to be part of the current project (but usually are). These files can be authored in the formats described above as well as the TOML format popular in some communities.

Configuration sources have the following precedence (in decreasing order):

• .markdownlint-cli2.{jsonc,yaml,cjs,mjs} file in the same or parent directory
• .markdownlint.{jsonc,json,yaml,yml,cjs,mjs} file in the same or parent directory
• Visual Studio Code user/workspace settings (see markdownlint.config and markdownlint.configFile below)
• Default configuration (see above)

Configuration changes saved to any location take effect immediately. Files referenced via extends are not monitored for changes. Inherited configuration can be explicitly disabled (or re-enabled) in any configuration file.

When a workspace is open, running the markdownlint.openConfigFile command (from the Command Palette or by binding it to a keyboard shortcut) will open an editor for the .markdownlint-cli2.{jsonc,yaml,cjs,mjs} or .markdownlint.{jsonc,json,yaml,yml,cjs,mjs} configuration file in the root of the workspace. If none of these files exist, a new .markdownlint.json containing the default rule configuration will be opened in the editor in the "pending save" state.

Note: Because JavaScript is cached by VS Code after being loaded, edits to .markdownlint.cjs/.markdownlint.mjs/.markdownlint-cli2.cjs/.markdownlint-cli2.mjs require a restart of VS Code.

markdownlint.config

The markdownlint.config property has been deprecated; please use a configuration file instead (as outlined in the Configure section).

When markdownlint.config is present in workspace context, replacing it can be done by creating a .markdownlint.json file in the root of the workspace with the value of the setting as its content. For example, removing this setting from the project's .vscode/settings.json:

{
    "editor.someSetting": true,
    "markdownlint.config": {
        "MD003": { "style": "atx_closed" },
        "MD007": { "indent": 4 },
        "no-hard-tabs": false
    }
}

Leaving just:

{
    "editor.someSetting": true
}

And adding a .markdownlint.json file with the corresponding configuration to the root of the project:

{
    "MD003": { "style": "atx_closed" },
    "MD007": { "indent": 4 },
    "no-hard-tabs": false
}

When markdownlint.config is present in user context, replacing it can be done by creating a .markdownlint.json file (as above) in the user's home directory and setting markdownlint.configFile to the corresponding path (for example, ${userHome}/.markdownlint.json). Similar to the scenario above, the user setting from something like ~/Library/Application Support/Code/User/settings.json would become:

{
    "editor.someSetting": true,
    "markdownlint.configFile": "${userHome}/.markdownlint.json"
}

markdownlint.configFile

The default behavior of storing configuration files in the root of a project works well most of the time. However, projects that need to store configuration files in a different location can set configFile to the project-relative path of that file. All markdownlint-cli2 configuration files used with --config are supported (including TOML files). VS Code's predefined variables ${userHome} and ${workspaceFolder} are supported (and the latter can be scoped per workspace folder).

This looks like the following in VS Code's user settings:

{
    "editor.someSetting": true,
    "markdownlint.configFile": "./config/.markdownlint.jsonc"
}

If markdownlint.config is also set, the settings from configFile take precedence.

markdownlint.configPointer

When configFile (above) is set, the configuration object is assumed to be the object represented by that file. The configPointer property can be used to identify a sub-object - typically in cases where a configuration file is shared by multiple tools.

For example, a package.json file with an embedded configuration object like this:

{
  "...": "...",
  "markdownlint-config": {
    "no-multiple-blanks": false
  }
}

Could be used by setting configFile to package.json and configPointer to /markdownlint-config.

Similarly, a pyproject.toml file like this:

[project]
# ...

[tool.markdownlint-cli2]
noProgress = true

[tool.markdownlint-cli2.config]
no-multiple-blanks = false

Could be used by setting configFile to pyproject.toml and configPointer to /tool/markdownlint-cli2.

markdownlint.appliesTo

By default, all files that VS Code identifies as being Markdown are scanned when they're open in the editor.

To avoid reporting issues in some cases, appliesTo can be set to any of the following values to lint (✅) or ignore (❌) certain kinds of files:

Customizing this setting can be useful if it's common to have a mix of files open from inside and outside a workspace - and especially if external files are not consistent with the workspace's lint policies. This looks like the following in VS Code's user settings:

{
    "editor.someSetting": true,
    "markdownlint.appliesTo": "workspaceFiles"
}

markdownlint.focusMode

By default, all linting issues are logged and highlighted as you type or edit a document. This includes "transient" issues like MD009/no-trailing-spaces such as when typing at the end of a line.

If you find this distracting, linting can be configured to ignore issues on the same line as the cursor. This looks like the following in VS Code's user settings:

{
    "editor.someSetting": true,
    "markdownlint.focusMode": true
}

To ignore issues on the N lines above and below the cursor, set focusMode to a positive integer representing the number of lines to ignore in each direction:

{
    "editor.someSetting": true,
    "markdownlint.focusMode": 2
}

The value of 2 in the example above will ignore issues on the line with the cursor, the 2 lines above it, and the 2 lines below it.

markdownlint.run

By default, linting is performed as you type or edit a document. Linting is fast and efficient and should not interfere with typical workflows.

If you find this distracting, linting can be configured to run only when the document is saved. This looks like the following in VS Code's user settings:

{
    "editor.someSetting": true,
    "markdownlint.run": "onSave"
}

Note: When configured to run onSave, the list of reported issues will become outdated while the document is edited and will update when the document is saved.

markdownlint.severityForError

By default, the markdownlint library reports violations at severity level error and they are displayed in VS Code at Diagnostic Severity Warning.

If you want to change the Diagnostic Severity shown by VS Code to something else, the markdownlint.severityForError configuration property can be set to any of the following values:

For example:

{
    "editor.someSetting": true,
    "markdownlint.severityForError": "Information"
}

markdownlint.severityForWarning

This configuration property behaves the same as markdownlint.severityForError (see above) and is used for violations reported by the markdownlint library at severity level warning.

By default, such violations are displayed in VS Code at Diagnostic Severity Information.

The value of severityForWarning can be the same as the value of severityForError.

markdownlint.customRules

The markdownlint.customRules property has been deprecated; please use a configuration file instead (as outlined in the Configure section).

Paths of the form {extension}/path (which allowed custom rules to be included within another extension's package) were previously discouraged and will no longer be supported.

The migration process is similar to what's outlined in the markdownlint.configFile section. For more, see the documentation about using the customRules property in .markdownlint-cli2.{jsonc,yaml,cjs,mjs}. The modulePaths property can be used in conjunction with customRules to specify one or more additional paths for resolving module references. Setting modulePaths to the location of the global module path (typically /usr/local/lib on macOS/Linux or ~/AppData/Roaming/npm on Windows) can be used to work around the VS Code limitation that globally-installed Node modules are not available by default.

markdownlint.lintWorkspaceGlobs

This property specifies the list of globs used when linting a workspace with the markdownlint.lintWorkspace command.

Note: The lintWorkspaceGlobs setting is only used when running the lintWorkspace command. To customize files that are linted by the standard editing experience, refer to the Configure section above.

The default list of globs matches VS Code's concept of "Markdown files that matter":

[
    // Source: https://github.com/microsoft/vscode/blob/main/extensions/markdown-basics/package.json
    "**/*.{md,mkd,mdwn,mdown,markdown,markdn,mdtxt,mdtext,workbook}",
    // Source: https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/search/browser/search.contribution.ts
    "!**/*.code-search",
    "!**/bower_components",
    "!**/node_modules",
    // Additional exclusions
    "!**/.git",
    "!**/vendor"
]

This list can be customized at workspace and user scope to include or exclude additional files and directories. For more information about syntax, see the "Command Line" section of the markdownlint-cli2 documentation.

Suppress

Individual warnings can be suppressed with comments in the Markdown file itself:

<!-- markdownlint-disable MD037 -->
deliberate space * in * emphasis
<!-- markdownlint-enable MD037 -->

More information about inline suppressions can be found in the Configuration section of the markdownlint README.md.

Snippets

The following snippets are available when editing a Markdown document (press Ctrl+Space/Ctrl+Space/⌃Space for IntelliSense suggestions):

• markdownlint-disable
• markdownlint-enable
• markdownlint-disable-line
• markdownlint-disable-next-line
• markdownlint-capture
• markdownlint-restore
• markdownlint-disable-file
• markdownlint-enable-file
• markdownlint-configure-file

Interoperability

For scenarios like continuous integration workflows where a project will be using the markdownlint VS Code extension along with the markdownlint-cli2 CLI, the recommended approach is to set everything up using the CLI and configuration files like .markdownlint-cli2.jsonc. Once everything works as intended with the CLI, no other changes should be needed to get the same behavior when opening that project's files within VS Code. (For example, extension-specific user/workspace settings like config and customRules are redundant and unnecessary for a shared workflow.)

Security

Running JavaScript from custom rules, markdown-it plugins, or configuration files (such as .markdownlint.cjs/.markdownlint.mjs/.markdownlint-cli2.cjs/.markdownlint-cli2.mjs) could be a security risk, so VS Code's Workspace Trust setting is honored to block JavaScript for untrusted workspaces.

History

See CHANGELOG.md.