Allowing special characters in note name breaks link functionality

We strongly recommend you to search the forum with possible keywords before submitting a new bug report. Please also try your repro steps with third-party plugins and custom CSS disabled and see if it’s still reproducible. If it’s an issue with third-party plugins or themes, try contacting the author for help. Once you’ve done the above, delete this line.

Steps to reproduce

Problem 1

Create a note name that ends in a right-square-bracket:
test results [version 3]

Now create a link to that note using [[ and selecting from list.
Link does not work because it cannot be parsed correctly. Hover over the link:
“test results [version 3” is not created yet
Note the loss of the ending bracket

Problem 2

Create a note with a number-sign (#):
test results version #three

Now create a link to that note using [[ and selecting from list.
Link does not work because it cannot be parsed correctly. Hover over the link:
“test results version #three” is not created yet.

Problem 3

Create a note name with a pipe:
test using either a | b

Link name is incorrectly aliased to “b”, and link does not work because it cannot be parsed correctly. Hover over the link:
“test using either a” is not created yet.

Problem 4

Try to create a note name with a colon to force display of the character restrictions:
“File name cannot contain any of the following characters: : / /”

This is confusing; not sure why forward slash is listed twice, and is visually confusing to list colon as first, after colon as part of sentence grammar.

Expected result

Links should work, and display properly.
The character restriction notice should be clearer.

Actual result

Links broken.
Character restriction notice is odd.


  • Operating system: Linux Mint 20.1
  • Obsidian version: 0.11.0

Additional information

These special characters were previously not allowed in note names. Purely just my opinion, but if allowing them was intentional, it’s a bad idea. If a part of the design philosophy of Obsidian is that our notes are our own, and we can work with them outside of Obsidian, allowing special characters in file name will create unexpected issues. Even if the parsing is fixed, it will likely cause users problems outside of Obsidian, getting the escaping right, and other tools may not be as receptive to these characters.

we forgot to add a warning for [ ] | ^ #

1 Like

Yay! I’m glad it could be resolved quickly. Given the mangled restriction notice, I was thinking that might be the case. Thank you!

not sure this is a resolution, we decided to move to allow but warn (we didn’t add the warn part). Long term the real resolution is to really manage these cases with escape sequences.

1 Like

If I understand correctly, Obsidian will allow their use, but they’ll have to be escaped in a link for the link to work correctly. Functionally this makes sense. But if this interpretation is correct, then I would think that when I create a link ( [[ ) and select the note name from the list, Obsidian should escape those characters prior to insertion, or it’s creating a broken link. I don’t know if that’s in the pipeline, but wanted to point it out. Thanks.

yes, this is the long term idea. Not sure if/when it will happen.
Something like: filename note#name will become [[note\#name]]

For the time being, it’s going to be allow+warn.

1 Like

What about the & ? It seems that obsidian can’t correctly process it either (even when you replace it with 26%). As a result, [](ML & can not be recognized as a link in the preview mode, while []( is wrongly linked to the file ML 26% DL.

& is not special character for filenames or our link system.
The url generated when you set markdown links is [](ML%20& and it works.

Thanks for your reply. I rechecked it again, it does work! I definitely tried your replied link string this afternoon, but it just didn’t work. And one possible reason is that I may misuse the full angle symbol by accident.

I do think however that []( should work too and point to the same file as [](ML%20&

1 Like

warning added in 0.11.4

1 Like

Hi, I found a parsing error while $ sign containing internal links in same line.

This bug report is in the graveyard, so you might want to just open a new bug report.