Paths with space break the markdown parser

Steps to reproduce

insert an image with a path to a folder containing spaces like with “The Lich” being a directory.

![tests](The Lich.assets/a462e628b5391637c65da984abf659da.jpg)

Expected result

The image should appear

Actual result

The following message appears :
“The” is not yet created. Click here to create

note : enclosing the path in quotes, simple or double, does not change anything, the parser still gets it wrong.

Of course as fate wants it I just read in the doc here Internal links - Obsidian Help, that spaces should be escaped with %20, but read below, this is not entirely true.

This like, a few other things I will try to collect below, are defeating compatibility with other tools (prominently Typora) and the whole point of being based on markdown.

Since Oberon is really “dry” in the editing user interface department, having a good Typora / markdown capability seems crucial to me, on top of allowing migration between tools.

For instance :

Relative paths are not working right

The img html tag does not respect relative paths ./asset/todo does not find the image

Neither this

<img src="assets/8b195586d10d49993edc4af4680ec6f2.jpg" alt="8b195586d10d49993edc4af4680ec6f2" style="zoom: 50%;" />
nor this
<img src="./assets/8b195586d10d49993edc4af4680ec6f2.jpg" alt="8b195586d10d49993edc4af4680ec6f2" style="zoom: 50%;" />

inconsistency in space handling in path

This does not work

![test](PNJs/The Lich.assets/a462e628b5391637c65da984abf659da.jpg)

but this works,

![[PNJs/The Lich.assets/a462e628b5391637c65da984abf659da.jpg]]

as does this (here relative paths are working)

![[./The Lich.assets/a462e628b5391637c65da984abf659da.jpg]]

and that seems inconsistent.

On the other hand invalid paths are working

or this
are working perfectly fine although no other markdown editor will be able to render this.
(the image file was not moved)

I suppose Obsidian is relying on its internal database and finding the asset by “id/base name” but that is not markdown.

And by the way, the following link produced by drag and drop of the image on a markdown file is incorrect too :

![test](PNJs/The Lich.assets/a462e628b5391637c65da984abf659da.jpg)

It is a relative path from the root of the vault and not the including file, another markdown editor will not find the asset and fail to render it.

All this little things make it hard to migrate from or to another tool, opening a file into obsidian shows a lot of broken links, and the links once repaired will often not work in other tools.

As enthusiastic as I am with many of Obsidian capabilities, these problems make the jump problematic and testing the water harder than it should be, onboarding is important.

(I’m not a dev. I’m not evaluating your bug report. I’m just replying to a few points.)

You linked to the help docs that explain this. Obsidian wiki links and Markdown links are not handled the same way. Markdown links need to be URL encoded.

If you Ctrl-drag, you’ll get an absolute path to the image on your filesystem. If you drag, yes you get a relative path in the vault. That’s how Obsidian works. Relative filesystem paths is an open feature request, iirc.

I don’t know about every other point you made about compatibility. But here is a statement that WhiteNoise provided about compatibility issues. In particular, wikilinks are addition above Commonmark:

And if you open a feature request, please search the forums first to make sure it doesn’t already exist.

Did you search the forum? There are many posts about this.

You can also wrap the path in angle brackets, which I believe is standard Markdown (tho I’m not sure if Markdown specifies how spaces are to be handled).

![tests](<The Lich.assets/a462e628b5391637c65da984abf659da.jpg>)

1 Like

Thanks for all the answers although I probably did not make myself clear.

First yes I did use the search button with image and path and did not see anything relevant in the first 10 or 15 hits.

My point is not that Obsidian does anything “wrong” or “right” my main point is that by default :

  • Obsidian will not open markdown file that are valid for many other tools (and produced by them) and that is probably a low hanging fruit to onboard people that have already lots of markdown files and notes and are interested in testing Obsidian capabilities.

  • Obsidian will produce files that can’t be open properly by other tools for the same kind of path issues.

Now, I dug further into the docs and options and if you

  • disable wiki notation but use it to create links and
  • set “new link format” to “relative to path file”


You can write [[something with space that you select in the select box]] and have Obsidian produce [something with space that you select in the select box](something%20with%20space%20that%20you%20select%20in%20the%20select%20box)

it still only work when typing, many plugins will insert [[name]] instead of the proper markdown but link will be relative to the including file and the escaping will be done my Obsidian.

Moreover having to escape spaces when typing common mark links but not when typing wiki links is inconsistent as a user experience, and it is annoying and slowing entry down.

And as I said by default, drag and dropping or linking file will create links that are invalid for most other parsers since the path is relative to the vault root.

Now if you set “new link format” to “relative to path file” and ask for attachments to be put in a subfolder of the note folder, you can have a more “sane/compatible” experience and that is great, it should be the default IMHO.

On a more general note, Markdown is not a great semantic/rich text format, it only allows metadata at the block level (through tricks with the preformatted text notation) and commit the same cardinal sin as HTML of confusing what you see and what you mean. Its only advantage is the plethora of engines that parses it, its simplicity for direct user entry and the fact it can be a lightweight common file format.
Not taking advantage of that last point feels like a missed opportunity to convert users, It would be of great benefit to Obsidian, being a relative newcomer, to be more compatible by default with the markdown file produced by other tools to give a better transition experience.

I am probably not alone in having quite few markdown files around and wanting to take advantage of the organizational capabilities of Obsidian but not enthusiastic about correcting hundreds of relative image link (could probably write a python script to do it, yes) or having Obsidian produce files that, by default, will require the same kind of work in another tool.

And It would also be great to be able to use a markdown editor like Typora when doing some complex table work or mermaid edition and move seamlessly to Obsidian for the organisational part.

I agree it’d be nice if Obsidian handled spaces in Markdown link paths more gracefully, and others would like it too (see for example this closed feature request: Reconsider requirement for markdown links to be urlencoded).

Try something with “space” or “spaces” in it (spaces path, space link), since that’s central to the problem.

Unfortunately they’re inconsistent in general (for example you add an alias to the front of one and the back of the other). This is at least partly because they’re preexisting syntaxes that were made for different purposes.

That’s 3 advantages :slightly_smiling_face:, and they’re not small ones.

It wasn’t designed to handle everything — it’s a light markup for writers, with HTML as a fallback. Like HTML, it’s flawed but has historical momentum. This is the imperfect world we live in.

1 Like


You didn’t spend much effort, or ask in help before coming in hot with notes. There are existing feature requests, and workarounds for people who ask with a bit of curiosity or willingness to learn.

You’re free to post a bug or feature request related to compatibility, but please search first. I’ll close this bug since the original post you made isn’t a bug. And the rest of the points are either covered in other places, or personal preference. I’ll leave the topic open for your discussion.

All excellent points @CawlinTeffid, thanks.

Can you explain what you mean by “slowing entry down”? If you set Wikilinks OFF in your settings, Markdown links will auto-complete and include %20. You don’t have to type these characters manually.

Whether you use Wikilinks or Markdown format, the trigger to begin auto-completion of a link is to type “[[” or run the command “Add internal link”, which can be mapped to a hotkey.

1 Like

And you did not spend much time being nice or think before passing judgements based on counters that do not measure what you think they do.

I created my account on the forum WHEN I wanted to post, did my search before. I then discovered that the account I created on the main website days before was not synchronized with the forum, to the point that I even used a different mail address on both and had to correct it to get my “badge”, since I did contribute monetarily, having a long time interest in tools like obsidian.

Basically : The Treachery of Images - Wikipedia. “This is not a pipe”, your counter does not measure what you think it does and is obviously wrong since it took me more than 1 hour to write my messages in this thread but whatever.

I have been toying with Obsidian for a week, perusing the doc and the forum, mostly the docs and tutorial on the web.

Your tone also clearly indicate that you think end users should work to deserve “your” software although we are talking about basic feature like opening or saving a file with links.

On the other hand I did, when someone first levelled the “you did not search” argument, give my search terms and you can use them to check that they do not bring useful links, if you doubt my words.

By contrast using the indeed smarter keywords of @CawlinTeffid, indeed leads to several threads pointing to the same problems… that should indicate that this is a serious recurrent problem.

Especially if one consider that people coming in the forum to ask about such things that should “work out of the box” are probably a low, very low percentage compared to the number of users that will open some of their markdown files, see that their image/links are not working (because of a relative path or spaces in the path) and decide that “this tool is not ready”. Or the number prospective users that will drop an image into a file, open that file in another editor and see the broken link (because path are by default relative to the vault root or because Obsidian by default will accept a link with a reference to a file anywhere in the vault, regardless of path), and conclude the same.

And that is all that I was saying : the fact that Obsidian has nonsensical defaults options and some minor quirks in the way it handles path in links who greatly diminish the onboarding experience and make interoperability harder than it should be even before using Obsidian powerful and advanced features, greatly reducing the chance someone would go further with the tool, or into the forum.

And even if one does, the question remains : do I (the user) want to commit to Obsidian and have trouble editing my markdown files with a more user friendly (but less powerful) editor or not ?

You can perfectly consider that having, by default, Obsidian producing incorrect links in markdown files or being unable to properly open files that are perfectly valid in zettlr or Typora is not a bug, I felt it was… and with more consequences for new (and maybe old) users, even if workaround exists (and I found those by myself as reported in my posts).

Thanks, I found those settings and posted about this and other configuration changes that bring Obsidian closer to more interoperable settings, they probably should be the default.

I don’t have completion on markdown links tough, typing ![ does not trigger completion, only [[ does.
That means one must disable Wikilinks but use them to get completion and proper expansion …

By the way, many plugins still inserts [[ even when the setting to disable those links is set. I understand this is the plugin responsibility but that’s a consequence of having two different ways of doing the same things => There should be one-- and preferably only one --obvious way to do it., sorry could not resist :wink:

Ok enough, I am sorry I bothered the community, I though understanding the path of a newbie in Obsedian would be useful, was wrong or more probably did it wrong.

@CawlinTeffid: you deserves your own answer given the time you took to answer me, it is late and I exhausted all my energy responding to @rigmarole but I will try to answer you tomorrow although I am afraid some of the topics will go “off tangent” (about the role of markdown notably :slight_smile: ) and would probably be more suited for a discord discussion that a forum one :slight_smile:

Thanks for the better search links, as I posted, I found most of the workarounds by myself, but my whole point was about the “newbie” / “other tool user” experience and the missed interop opportunities that seems to come from these quirks.

Experienced user stop to see these problems (until they want to migrate to another tool or temporarily use another one) and if I decide to use Obsidian I will get used to the way Obsidian does things, probably, but that’s also self blindsiding.


You’re right, my reply wasn’t as nice and welcoming as it could be. I apologize to you for that.

To be fair, you told us you search for extremely generic words. You could search “local paths in html”, or other more descriptive phrases. Or ask for help and suggestions.

That’s why I’m asking you to come into the forum with a bit of curiosity. If you ask for help, we’re more than willing to give our help and suggestions and workarounds. I still am.

I am not a dev. This is not my software. I’m a volunteer mod here on the forum. And again I apologize for giving you an unwelcoming experience here. I can’t speak on behalf of the devs, but thanks for supporting Obsidian.

All that said, I’m not saying you must work to deserve help. I’m saying if you aren’t sure, please consider asking for help before posting bugs and saying things are broken, inconsistent, incorrect, and nonsensical.

You are not a bother here at all. Besides my inappropriate judgment of your searches, (which again apologies) I have been in this thread trying to help with suggestions and context. Me moving your Bug Report to Help is a matter of keeping this forum tidy, not a judgment against the points you’re making.

If you like; you don’t owe me anything. :slightly_smiling_face: You’re welcome to ping me on Discord if you like.

I realize most of my answer probably wasn’t very satisfying. I wasn’t trying to say we shouldn’t want more, just explaining why things are the way they are and why we might be stuck with them sometimes.

And I apologize for my tone, I should be more constructive and was quite tired yesterday when answering (it was between 0:30 and 2 am after a late work event, those sucks).

I understand your point on searching and I should probably have searched more and better (to the point that I did found some answers in the documentation after posting, clear indication that I did not search enough or right).

My post would probably then have been more clear about my frustration that a tool that seems has promising has Obisidian “shoot itself in the foot” (in my opinion that is absolutely worthless since I am not helping with the code) on these tiny quirks and miss the opportunity to collaborate with other tools while it is growing has an IDE for thought :wink:

I will try to do better next time.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.