Support real Markdown links between notes

Hey guys, this is my first post and I’m just joining the beta. I’m excited for the app!

The feature request: Obsidian use support standard Markdown links to navigate between notes.

Use case: My Vault (imported) includes links between notes. The links have been written using the standard Markdown link format [link title](link dest). This format is natively understood by all Markdown readers and my main Markdown editor, Typora, even allows you to click between them to open other notes in the app (Typora treats it as a relative link and automatically adds .md to the end of the filename). [1]

Furthermore, potentially less popular opinion: The [[WikiLinks]]syntax should be a shorthand that is translated to a standard Markdown link. In vim-zet [1] , typing [[ opens the normal note search interface, but after selecting a note, the generated text is a standard Markdown link. This keyboard shortcut to insert a link is natural to type but results in Markdown files that are standard to every reader.

I believe that the standard Markdown link syntax should be the preferred syntax because one of the stated goals of the Obsidian project is that it stores data as Markdown, and while there are many extensions to Markdown, a custom link syntax doesn’t add anything that Markdown doesn’t already have.

OK thanks for reading. Let me know what you think about this suggestion!

[1] My current knowledge base is a combination of vim-zet and Typora, and I’d like to replace both of these with just Obsidian.


Couple of points!

  1. Obsidian supports the standard markdown notation
    the new notation is a shorthand, to maintain links compact.
    It follow the standard used by wikipedia for its links, and other software are adopting it too.

  2. we are planning a plugin to export a note into “standard markdown” format, i.e. it replaces the [[ ]] with []().


Thanks for the reply! Just a quick note: Obsidian does not support the standard markdown link format to link to notes.

Given a vault with a file and, where contains:

- [relative implied link](foo)
- [relative short link](./
- [absolute link](file:///full/path/to/
- [[foo]]

The 4th link “works as intended”, the 3rd link opens the file in my system-configured Markdown editor, and the first two links are unclickable.

Sadly, this renders my entire note collection unnavigable within Obsidian.


The first two work in preview mode.
Anyway, we’ll try to handle these things better in the future.
I do undestand it will facilitate people with large collection of md files like you or even importing from other software.


I can confirm that the links work in preview mode. However, they are not recognised for backlinks or graph view. Only when I change/add links to look like the fourth, I get links in graph view between notes.
This kills of some of the main features of Obisdian for me at the moment. All my notes are disconnected.

So yeah… would love to see full support for standard markdown links


Ah, thanks for the correction. I was actually not aware of “preview mode” at all, since I’m just getting used to the software. I can confirm that in preview mode the links I’m using are working.

I don’t fully understand why the links work in preview mode but not edit mode. I don’t care for the mentality of “reading a note is a fundamentally different action than editing a note”, so I wish that the edit mode links were also recognized.

Thanks for the responses!

1 Like

don’t worry, in the future there will be a single mode.


I am assuming there would be also an option/plugin to export all notes to this format?

yes, correct!

the only obstacle for me to adopt Obsidian is this, i really want my “plain text” is really “plain” ie [name/title file](file location) so even without using Obsidian i (or another software) still can see “where the exact (relative/absolut) path is this file/note/page belong” (also for image/pdf/attachment), if obsidian create this standard at the .md file and still use [[]] for easiness it will be great (and also recognize this to graph view)


@WhiteNoise thank you letting us know about the upcoming ‘export’ plugin.

I’d prefer to use ‘standard’ markdown notation whenever possible - really avoid using the double-bracket notation. Would it be possible to have a preference that would turn off the double-bracket notation altogether?..


This seems to work now, as others have pointed out. Even in graphing. However, the first two formats only work on one word links

[foo](foo) works but [foo](foo bar) does not work - only [[foo bar]] works.

It works, with caveats - as you found out. There is no autocomplete suggestions, either, on standard links and images.

It makes it feel as is the standard markdown syntax is a second-class citizen here, as the user is being encouraged to use (non-standard) double-bracket WikiLink notation instead - and with syntax additions which are particular to Obsidian. This feels as if it’s going against the developers’ principle of letting the user “own their own data” - i.e., avoiding vendor lock-in. I’m certain that is not the intention - much the opposite: the developers are trying to create an app that is as helpful as possible for the user.


[foo](foo bar) is not standard markdown
[foo](foo%20bar) is standard markdown

1 Like

This is a topic which I also find very, very important. I have a few things to say about it, but I don’t want to create a duplicate thread. It is maybe a little too long for a reply, but I hope it gets seen by the developers.

First principle

The [[]] Wiki-Links Feature is very nice, but I think native Markdown Links should be the default. Markdown links do much more comply with the first principle of the developers - To own my data. To be platform-independent.


Writing native Markdown-Links should behave the same way as writing Wiki-Links:

  • AutoComplete Path
  • AutoUpdate Path ( After Location Change )
  • Creates connections in the Graph

Alias for notes

This would also solve the Alias for notes problem since you can just display a different text for a link. But it would default to the file-name.


Thanks, I was not aware of this. Is there any way to work around this while also adhering to markdown standards? I’m never going to type %20 between every word in a link). Nibru’s suggestion above seems reasonable

1 Like

My preference remains the wikilink [[]] format, which is increasingly used. Programs like Obsidian have developed from outliners and wikis and most of them use this style of link.

You do according to the plaintext conceit of the markdown being readable on any OS, without any program.
And I’m sure you are aware that there’s little consistency in markdown across different programs. Apart from the range of different ‘standards’, most programs have some custom extensions and compliance to the ‘standard’ they claim to follow tends to be somewhat variable.
The functions being developed in new programs are well beyond anything that was originally conceived. Developers have to make the best choices they can between usability (often by users who have little interest in markdown and would strongly prefer wysiwyg), usual practice in similar programs and some compatible markdown core standard. Those choices often displease plaintext purists.

We can certainly improve the way we work with standard markdown links, however I don’t see them becoming the default due to limitations of the standard and its verbosity.

If we start easing the inconveniences of the standard (e.g. supporting whitespaces) we are effectively breaking the standard, and we don’t want that, do we?

Our position is that if you want full convenience, you should use the [[ ]] notation (which btw is gaining popularity).

At some point, beyond better support for standard markdown links, we will have a plugin that converts wiki-links [[ ]] to markdown links .

@nixsee: another option is to use [](<foo bar>)

@nibru: we already support that type of alias [[name | alias]]


Thanks for the tip - that should work for me! And I agree on the rest.

@WhiteNoise you are already very close to providing the functionality that is needed. Consider that in order to provide the WikiLinks, Obsidian now does this:

Creating WikiLinks Internal Links

  1. user types a trigger ([[) which activates the system
  2. system offers user with a dropdown to choose from internal files, from which it will derive the link path
  3. system allows the user to extend the path with an internal document link, by watching for another trigger ("#"). If trigger is used, show possible internal headings, adding link to the path.
  4. last of all, system allows the user to define the link text, by watching for another trigger ("|"). If the trigger is used, then any text that follows will be used as the clickable text for the link.
  5. once everything is entered, Obsidian automatically creates and enters the WikiLink

In order to create an internal link using standard markdown, however, the only help the user needs is in entering the file path - as the user will manually enter the link text anyway. So, all we need is a shortcut help for adding internal file paths., in the standard syntax. Here is a possible workflow:

Creating an Internal Link with Standard Markdown

  1. user types in the link text (e.g., [my link]() or link reference (e.g., [link]:) stopping just before a path needs to be entered.
  2. The user types in a trigger - something like “((”, or “\\”, or even “[[[”,
  3. Obsidian shows a dropdown menu allowing user to choose files - just like it does now for WikiLinks
  4. Once the file (and optionally the heading) have been selected, Obsidian outputs the path - in standard format (so a file titled “my” would be output as “” automatically).

This makes Obsidian super helpful also in building standard markdown links. Obsidian would still continue to make sure, that if the user decides to change the filename, such paths would be updated automatically, too (as it already does now).

Longevity vs Convenience

Most users are going to be very thankful that Obsidian provides such great features, which go beyond what is supported by the standard markdown syntax - or even by MultiMarkdown - such as WikiLinks, links to headers, and file embeds. These features are, indeed, extremely useful and convenient.

There are many users that are finding Obsidian when looking for a good Zettelkasten app. A key principle of Zettelkasten is to strive for longevity in our notes, and this is why many “Zettelkasten pro users” advocate using the simplest tools we can find - like text files, and nothing more than standard markdown for text structuring. There are, indeed, a myriad of other ways to keep our notes, which would indeed be much more helpful than just plain text - e.g., rich text, or full-blown HTML, .docx or even proprietary file formats offered by other apps. But from the Zettelkastener perspective, all these formats are ‘a risk’ of sorts, because we don’t know how much they will change (or whether they will even exist) 10 or 20 years from now.

So, while it’s awesome that Obsidian offers great ‘extended’ features, the most important feature of all, for a Zettelkastener, is longevity of their notes. And that means full support to the standard markdown syntax, as first-class citizen, and not as an optional afterthought. As soon as the app starts encouraging users to adopt non-standard syntax, it’s encouraging dependency and vendor lock-in.

I believe this is not the intention of Obsidian, because you guys go through great lengths to show users that one of your core values is that “the user should own their own data”. But what you might not realise, is that by encouraging non-standard syntax as a primary feature of your system, you are actually encouraging users to lock-in, and going against your own principle.

Non-Standard Syntax for Basic Features vs Add-On Extras

You are right in stating that markdown is limited - it is so by design. It is intended as a human-readable format, meant to be understood even if not parsed at all. Its intention is to provide essential structuring (h1-h6, lists, quotes, images), highlighting (bold, code) and a way to provide hyperlinking in plain text documents. It is reasonable for any user to expect that a program that ‘supports markdown’ would support these basic features well, and work with them in a reliable way, and with very little surprises.

If an app offers extended features that go beyond the basic markdown, those features will necessarily require their own syntax. By using them, the user understands that they are choosing to lock themselves into an app, and that specific feature set. If my notes absolutely NEED tables, I know that I’ll need to use multimarkdown syntax - and I’m going to be locked-in to apps that support it. If I cannot live without embeds, I’ll use Obsidian’s ‘embed’ syntax - and I’m willingly and happily locking myself into it.

Using proprietary syntax for ‘extended’, non-standard features is expected - and the user does it at their own peril. This is significantly different to encouraging the user to use non-standard syntax for basic markdown features, such as images and links. This is encouraging lock-in - and simply not necessary.

IMMHO, an app that has the motto “the user should own their own data” as its core, should encourage users to avoid lock-in, by encouraging the use of standard syntax whenever possible. I’m pretty sure that this is still Obsidian’s intention, but in the effort of being ‘as helpful as possible’ to the user, perhaps this principle is being forgotten - or, at least, ‘diluted’…