Images with Spaces #160

New Issue

claunia · 2026-01-29T14:29:13Z

claunia commented

2026-01-29 14:29:13 +00:00

Originally created by @RickStrahl on GitHub (Nov 10, 2017).

When embedding image urls with spaces the images are not parsed and the raw markdown is embedded:

This doesn't work (doesn't parse just embeds the markdown):
![](Markdown Monster.png)

This works:
![](Markdown%20Monster.png)

This works:
<img src="Markdown Monster.png" />

Looks like other parsers are split on handling this - some work some don't:

https://babelmark.github.io/?text=This+doesn%27t+work+(doesn%27t+parse+just+embeds+the+markdown)%3A%0A!%5B%5D(Markdown+Monster.png)%0A%0AThis+works%3A%0A!%5B%5D(Markdown%2520Monster.png)%0A%0AThis+works%3A%0A%3Cimg+src%3D%22Markdown+Monster.png%22+%2F%3E

Originally created by @RickStrahl on GitHub (Nov 10, 2017). When embedding image urls with spaces the images are not parsed and the raw markdown is embedded: ```md This doesn't work (doesn't parse just embeds the markdown): ![](Markdown Monster.png) This works: ![](Markdown%20Monster.png) This works: <img src="Markdown Monster.png" /> ``` Looks like other parsers are split on handling this - some work some don't: https://babelmark.github.io/?text=This+doesn%27t+work+(doesn%27t+parse+just+embeds+the+markdown)%3A%0A!%5B%5D(Markdown+Monster.png)%0A%0AThis+works%3A%0A!%5B%5D(Markdown%2520Monster.png)%0A%0AThis+works%3A%0A%3Cimg+src%3D%22Markdown+Monster.png%22+%2F%3E

claunia added the enhancement label 2026-01-29 14:29:13 +00:00

claunia closed this issue

2026-01-29 14:29:13 +00:00

claunia commented

2026-01-29 14:29:14 +00:00

@xoofx commented on GitHub (Nov 10, 2017):

Yes, that's part of the CommonMark spec (link destination)

a nonempty sequence of characters that does not include ASCII space or control characters, and includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses. (Implementations may impose limits on parentheses nesting to avoid performance issues, but at least three levels of nesting should be supported.)

@xoofx commented on GitHub (Nov 10, 2017): Yes, that's part of the CommonMark spec ([link destination](http://spec.commonmark.org/0.28/#link-destination)) > a nonempty sequence of characters that does not include ASCII space or control characters, and includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses. (Implementations may impose limits on parentheses nesting to avoid performance issues, but at least three levels of nesting should be supported.)

claunia commented

2026-01-29 14:29:14 +00:00

@RickStrahl commented on GitHub (Nov 11, 2017):

Thanks for clarifying.

Still think this would be a nice thing to have work (and other parsers including PanDoc are putting it in), particularly because the underlying HTML supports it.

Understand sticking to the spec though :-(

FWIW, I can fix this on my end when images get embedded which is easy enough - just looks ugly. OTOH, if people decide to put spaces in their asset paths they deserve what they sow :-)

@RickStrahl commented on GitHub (Nov 11, 2017): Thanks for clarifying. Still think this would be a nice thing to have work (and other parsers including PanDoc are putting it in), particularly because the underlying HTML supports it. Understand sticking to the spec though :-( FWIW, I can fix this on my end when images get embedded which is easy enough - just looks ugly. OTOH, if people decide to put spaces in their asset paths they deserve what they sow :-)

claunia commented

2026-01-29 14:29:14 +00:00

@xoofx commented on GitHub (Nov 11, 2017):

Still think this would be a nice thing to have work (and other parsers including PanDoc are putting it in), particularly because the underlying HTML supports it.

It is only the browsers that support them, but the HTML specs (i.e. with the underlying RFC for URI) actually don't allow spaces. CommonMark allow also to specify a title attribute separated by a space right after the url like [This is an example](http://example.com/ "Title Example") which would fight against what you are looking for.

Moreover when you look at GitHub that is migrating to CommonMark, or in the .NET world, docfx also going to CommonMark, that's really not a good idea to encourage to replicate the legacy inconsistencies of browser behaviors.

@xoofx commented on GitHub (Nov 11, 2017): > Still think this would be a nice thing to have work (and other parsers including PanDoc are putting it in), particularly because the underlying HTML supports it. It is only the browsers that support them, but the HTML specs (i.e. with the underlying RFC for URI) actually don't allow spaces. CommonMark allow also to specify a title attribute separated by a space right after the url like `[This is an example](http://example.com/ "Title Example")` which would fight against what you are looking for. Moreover when you look at GitHub that is migrating to CommonMark, or in the .NET world, docfx also going to CommonMark, that's really not a good idea to encourage to replicate the legacy inconsistencies of browser behaviors.

claunia commented

2026-01-29 14:29:14 +00:00

@RickStrahl commented on GitHub (Nov 15, 2017):

Fair enough. Thanks Alexandre.

@RickStrahl commented on GitHub (Nov 15, 2017): Fair enough. Thanks Alexandre.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#160