Do links in markdown files compromise the long-term use of a zettelkasten?

Currently I’m starting to create a zettelkasten using of course DTP and I’m confronted with a fundamental thinking.

While markdown is supposed to ensure the long-term use of notes, regardless of the application in which they were created, I seem to completely lose this advantage as soon as I use WikiLinks or item links.

Indeed these links (for example x-devonthink-item://…) point only to DTP. How can I continue to use the zettelkasten if one day I decide to stop using DTP? Of course this is not going to happen, but before I start creating hundreds or even thousands of notes, I want to make sure I choose the best solution in terms of format, architecture and application.

Thank you for your feedback and advice.

1 Like

This is not entirely true. Markdown makes no claim of “ensuring long-term use of notes”, nor is it even possible for it to as it’s just a file forrmat, not a platform.

The validity of links of any kind depends on the continued existence of the item or site linked to, not just in DEVONthink. You could easily link to a web page that doesn’t exist in the future. You could link to a file in the Finder that gets moved or deleted at some point.

If you are going to use links, you need to be aware of these things and be diligent in how you handle the linked items, wherever possible.


Hi Claude,

I use Markdown for the same reason you do.

X-item links are not the only way to link to files. I think one should think about how long this note will live before choosing the link syntax.

1.) X-item links

X-devonthink-item link are good as long as you use DEVONthink and they are powerful and work independent from the acutally location of the linked file. But they are broken if you leave DEVONthink.

2.) Relative file link

A relative file link works independent from DEVONthink but is needs a strong folder structure:




From DEVONthink help:

Linking: You can reference local images, scripts, and other resources using item links, downward-relative (traveling subgroups; it’s not possible to travel up with ‘…’ as documents can have multiple parents) or absolute (start with a forward slash) paths.

You see that your file structure has to be strong for this relative file links to stay alive. It would be great to have a x-item-link at the OS level for whole MacOS.

3.) iCloud file links

Did anybody say OS level file links? Yeah, it is not exactly that, but something comparable. If you got your files in the iCloud (many other Cloud providers got the same functionality) you can share them through the Finder-APP and link to the URL in Markdown.

Not hot, but another option.

I think you go best longterm with #2. Build a strong folder structure and use relative file links.

For me the best would be some exporting script, which would transform the x-devonthink-item links of all text files in the exported folders to valid relative file links just before exporting to the file system. As I think DEVONthink will not vanish tomorrow you will be able to export your databases to the macOS file system.

@BLUEFROG Maybe something like this script will be included ?

1 Like

I’ve taken to using the kind of UID suggested by the guys at It works pretty well. They have thought about this a lot, and their methods are worth trying. As always there are pros and cons.

1 Like

The difficulty in this approach is the linked items could be in any location in any database. So what wouldyou propose would happen in the filesystem?

1 Like

Yes, links to files in other databases could not be transformed, but as this script has to determine where the file is located in relation to the databases root, files from other databases could be detected and ignored. I think this would be a powerful solution to prevent a lock in.

Hi Z4ck,

Thank you very much for your explanations.

I had focused on wiki-links and item links and hadn’t thought about relative file links. Of course this is the best solution to be able to use the zettlekasten independently of DTP.

I’ll quickly try it out!

I think that DT’s item links (x-devonthink-item://…) are more robust compared to regular file links (relative or absolute) since they’ll continue to function even if a file gets moved/renamed. IMHO, that‘s a big advantage.

In my view, the best option for you would be to:

  1. in your Markdown notes, use Markdown links with DT item links: [link title](x-devonthink-item://…)
  2. for each Markdown note, include the note‘s own DT item link in the note body itself, eg. like this:
ID: x-devonthink-item://…

That way, should you ever need to use your notes archive w/o DEVONthink, you can simply search for the item link‘s UUID. This would return the original note plus any notes that link to it. I.e., your link connections will still be valid. And this will work with any tool that supports search (even in the Finder).

Since your links consist of unique IDs, you could always transform your links into a new link formal (like e.g. [[link ID]]), using a simple batch search & replace action. With a small script, you could also transform your entire notes archive to use date-based IDs instead.

So IMO using DT‘s item links together with item links in the body of the note gives you stable links that provide enough options to reuse or transform your notes archive if necessary.


I agree with saving the DT item link
I use the comments (Finder) section
It will be accessible in exported notes

I agree, you are building a database with notes that might be linked to each other. The only way to keep this consistent is using a Unique Identifier for your notes. You can use the DT ItemID for this, even if you would stop using DT. (the link will not work anymore off-course)

With modern tools the ID does not need to be human-readable because of indexing and tagging possibilities in. If you decide to print your notes for post-apocalypse times then the ID will be a bit harder to use and decipher :wink: .

I do see benefits in using an identifier with more context like Luhmann did because it organises related notes together which a system generated ID does not, at least not based on filename for example. The system Luhmann used was a bit more complex and will take more effort, but it is probably also the reason why he was so efficient in using his notes.

I just noticed this interesting thread, and reached the conclusion that I’ll stick with item-links ("x-devonthink-item://…) but was recognizing that should I ever need to leave the platform I would be hosed.

Then I see this brilliant and easy hack! Fabulous! Thanks for sharing, but I have to go script something now…

1 Like

My plan is to switch to text search
That’s why it’s important to preserve a notes’s note-id
I’m using this plan for my imported Evernote notes - the links are still useful