[GH-ISSUE #1154] MD013 false positive when url contains #

kerem commented

2026-03-03 01:28:35 +03:00

Owner

Originally created by @SimonMarynissen on GitHub (Mar 19, 2024).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1154

When the .markdownlint.yaml contains the following

MD013:
  line_length: 80
  heading_line_length: 80
  code_block_line_length: 80
  code_blocks: true
  tables: true
  headings: true
  strict: false
  stern: true

and my markdown contains the following 2 lines:

[Ok](https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml)
[Not ok](https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml#L61-L77)

eventhough both lines are more than 80. Of course links can't be made shorter and as such both links should not be reported.

Originally created by @SimonMarynissen on GitHub (Mar 19, 2024). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1154 When the `.markdownlint.yaml` contains the following ```yaml MD013: line_length: 80 heading_line_length: 80 code_block_line_length: 80 code_blocks: true tables: true headings: true strict: false stern: true ``` and my markdown contains the following 2 lines: ```md [Ok](https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml) [Not ok](https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml#L61-L77) ``` eventhough both lines are more than `80`. Of course links can't be made shorter and as such both links should not be reported.

kerem

2026-03-03 01:28:35 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-03 01:28:36 +03:00

Author

Owner

@DavidAnson commented on GitHub (Mar 20, 2024):

The "Not ok" example above CAN be shortened by removing the space character or turned into a non-breakable line by replacing the space with a newline character. If either is done, MD013 does not report a violation:

https://dlaa.me/markdownlint/#%25m%23%20Issue%201154%0A%0A%5BOk%5D(https%3A%2F%2Fgithub.com%2FDavidAnson%2Fmarkdownlint%2Fblob%2Fmain%2Fschema%2F.markdownlint.yaml)%0A%5BNot%20ok%5D(https%3A%2F%2Fgithub.com%2FDavidAnson%2Fmarkdownlint%2Fblob%2Fmain%2Fschema%2F.markdownlint.yaml%23L61-L77)%0A%5BNot_ok%5D(https%3A%2F%2Fgithub.com%2FDavidAnson%2Fmarkdownlint%2Fblob%2Fmain%2Fschema%2F.markdownlint.yaml%23L61-L77)%0A%5BNot%0Aok%5D(https%3A%2F%2Fgithub.com%2FDavidAnson%2Fmarkdownlint%2Fblob%2Fmain%2Fschema%2F.markdownlint.yaml%23L61-L77)%0A%0A%3C!--%20markdownlint-configure-file%20%7B%0A%20%20%22line-length%22%3A%20%7B%0A%20%20%20%20%22line_length%22%3A%2080%2C%0A%20%20%20%20%22heading_line_length%22%3A%2080%2C%0A%20%20%20%20%22code_block_line_length%22%3A%2080%2C%0A%20%20%20%20%22code_blocks%22%3A%20true%2C%0A%20%20%20%20%22tables%22%3A%20true%2C%0A%20%20%20%20%22headings%22%3A%20true%2C%0A%20%20%20%20%22strict%22%3A%20false%2C%0A%20%20%20%20%22stern%22%3A%20true%0A%20%20%7D%0A%7D%20--%3E%0A

@DavidAnson commented on GitHub (Mar 20, 2024): The "Not ok" example above CAN be shortened by removing the space character or turned into a non-breakable line by replacing the space with a newline character. If either is done, MD013 does not report a violation: https://dlaa.me/markdownlint/#%25m%23%20Issue%201154%0A%0A%5BOk%5D(https%3A%2F%2Fgithub.com%2FDavidAnson%2Fmarkdownlint%2Fblob%2Fmain%2Fschema%2F.markdownlint.yaml)%0A%5BNot%20ok%5D(https%3A%2F%2Fgithub.com%2FDavidAnson%2Fmarkdownlint%2Fblob%2Fmain%2Fschema%2F.markdownlint.yaml%23L61-L77)%0A%5BNot_ok%5D(https%3A%2F%2Fgithub.com%2FDavidAnson%2Fmarkdownlint%2Fblob%2Fmain%2Fschema%2F.markdownlint.yaml%23L61-L77)%0A%5BNot%0Aok%5D(https%3A%2F%2Fgithub.com%2FDavidAnson%2Fmarkdownlint%2Fblob%2Fmain%2Fschema%2F.markdownlint.yaml%23L61-L77)%0A%0A%3C!--%20markdownlint-configure-file%20%7B%0A%20%20%22line-length%22%3A%20%7B%0A%20%20%20%20%22line_length%22%3A%2080%2C%0A%20%20%20%20%22heading_line_length%22%3A%2080%2C%0A%20%20%20%20%22code_block_line_length%22%3A%2080%2C%0A%20%20%20%20%22code_blocks%22%3A%20true%2C%0A%20%20%20%20%22tables%22%3A%20true%2C%0A%20%20%20%20%22headings%22%3A%20true%2C%0A%20%20%20%20%22strict%22%3A%20false%2C%0A%20%20%20%20%22stern%22%3A%20true%0A%20%20%7D%0A%7D%20--%3E%0A

kerem commented

2026-03-03 01:28:36 +03:00

Author

Owner

@SimonMarynissen commented on GitHub (Mar 20, 2024):

That's indeed the case, but there is still an inconsistency: both lines are over the limit, but only the URL with the # in it is reported. I would suspect either both of them or neither of them to be reported.

Since both lines have no spaces in them and I run with strict = false and stern = true it should report none of them.

@SimonMarynissen commented on GitHub (Mar 20, 2024): That's indeed the case, but there is still an inconsistency: both lines are over the limit, but only the URL with the # in it is reported. I would suspect either both of them or neither of them to be reported. Since both lines have no spaces in them and I run with `strict = false` and `stern = true` it should report none of them.

kerem commented

2026-03-03 01:28:36 +03:00

Author

Owner

@DavidAnson commented on GitHub (Mar 20, 2024):

I updated the documentation for this rule last night to try to clarify two points (see link above), but this is the relevant part from the published package documentation and was not changed:

To warn for lines that are too long and could be fixed but allow long lines without spaces, set the stern parameter to true.

The first line of your example is too long without spaces, so is allowed; the second line of your example is too long and could be shortened, so is reported. The behavior you report is behaving as documented for for your configuration.

@DavidAnson commented on GitHub (Mar 20, 2024): I updated the documentation for this rule last night to try to clarify two points (see link above), but this is the relevant part from the published package documentation and was not changed: > To warn for lines that are too long and could be fixed but allow long lines without spaces, set the stern parameter to true. The first line of your example is too long without spaces, so is allowed; the second line of your example is too long and could be shortened, so is reported. The behavior you report is behaving as documented for for your configuration.

kerem commented

2026-03-03 01:28:36 +03:00

Author

Owner

@SimonMarynissen commented on GitHub (Mar 21, 2024):

With the following configuration

MD013:
  line_length: 30
  heading_line_length: 30
  code_block_line_length: 30
  code_blocks: true
  tables: true
  headings: true
  strict: false
  stern: true

and markdown document:

## Title with size equal limit

[ok](https://example.com)
[also ok](https://example.com)
[ok](https://example.com/extra)
[not ok](https://example.com/extra)
[also_ok](https://example.com/extra)

What I don't like about this behavior is that the one that is not ok, cannot be broken at the space that causes it to be reported. You can only break the link after ( and before ).
The most logical handling (in my opinion) would be the same behaviour for the last three lines. Because all three lines can be broken at the parentheses to get inside the limit:

## Title with size equal limit

[ok](
https://example.com/extra)
[not ok](
https://example.com/extra)
[also_ok](
https://example.com/extra)

I would suggest to report neither of the three with the current settings. Every line that has no breakable spaces should not be reported when stern = true and strict = false.

@SimonMarynissen commented on GitHub (Mar 21, 2024): With the following configuration ```yaml MD013: line_length: 30 heading_line_length: 30 code_block_line_length: 30 code_blocks: true tables: true headings: true strict: false stern: true ``` and markdown document: ```md ## Title with size equal limit [ok](https://example.com) [also ok](https://example.com) [ok](https://example.com/extra) [not ok](https://example.com/extra) [also_ok](https://example.com/extra) ``` What I don't like about this behavior is that the one that is not ok, cannot be broken at the space that causes it to be reported. You can only break the link after `(` and before `)`. The most logical handling (in my opinion) would be the same behaviour for the last three lines. Because all three lines can be broken at the parentheses to get inside the limit: ```md ## Title with size equal limit [ok]( https://example.com/extra) [not ok]( https://example.com/extra) [also_ok]( https://example.com/extra) ``` I would suggest to report neither of the three with the current settings. Every line that has no *breakable* spaces should not be reported when `stern = true` and `strict = false`.

kerem commented

2026-03-03 01:28:36 +03:00

Author

Owner

@DavidAnson commented on GitHub (Mar 23, 2024):

This rule is based on line-breaking via whitespace - a technique pretty much everybody knows about. I think very few people know about breaking within the link destination as you show above and I would not want to confuse people. In the case of links, I think reference links (i.e., [link][reference]) are a better approach than inline links because their shorter length tends to make discussions like the above unnecessary.

Also, it IS acceptable to include a line break in the link text:
https://dlaa.me/markdownlint/#%25m%23%20Heading%0A%0A%5Bperfectly%0Afine%5D(https%3A%2F%2Fexample.com%2F)%0A

@DavidAnson commented on GitHub (Mar 23, 2024): This rule is based on line-breaking via whitespace - a technique pretty much everybody knows about. I think very few people know about breaking within the link destination as you show above and I would not want to confuse people. In the case of links, I think reference links (i.e., `[link][reference]`) are a better approach than inline links because their shorter length tends to make discussions like the above unnecessary. Also, it IS acceptable to include a line break in the link text: https://dlaa.me/markdownlint/#%25m%23%20Heading%0A%0A%5Bperfectly%0Afine%5D(https%3A%2F%2Fexample.com%2F)%0A

kerem commented

2026-03-03 01:28:36 +03:00

Author

Owner

@SimonMarynissen commented on GitHub (Mar 23, 2024):

I didn't know you could break in the link text. There are downsides to reference links as well though, and I suppose that markdownlint is meant to lint all kind of markdown files. But for this issue, I guess I'll format my links differently then to avoid this situation, but it doesn't feel ideal.

@SimonMarynissen commented on GitHub (Mar 23, 2024): I didn't know you could break in the link text. There are downsides to reference links as well though, and I suppose that markdownlint is meant to lint all kind of markdown files. But for this issue, I guess I'll format my links differently then to avoid this situation, but it doesn't feel ideal.

kerem commented

2026-03-03 01:28:37 +03:00

Author

Owner

@DavidAnson commented on GitHub (Mar 27, 2024):

(Deleted SPAM comment)

@DavidAnson commented on GitHub (Mar 27, 2024): (Deleted SPAM comment)

kerem commented

2026-03-03 01:28:37 +03:00

Author

Owner

@SimonMarynissen commented on GitHub (Mar 27, 2024):