Links including a colon in the domain/path component do not work

Steps to reproduce

If I use Link beginning with addressbook:// i.e. [Test Person](addressbook://8644A04D-6FB4-4F3E-B228-EBAAA83D6686:ABPerson) on macOS the link is not clickable.

Expected result

A clickable link opening the adressbook.

Actual result

Looks like a link, but nothing happens clicking it. Using links in markdown documents in other apps like iA Writer, DEVONthink, etc., successfully launches macOS Contacts with the focus on that contact.


  • Operating system: macOS
  • Obsidian version: v 0.9.11

Additional information

The link is created by the app Hook on macOS to be able to link to single contacts inside the addressbook.

1 Like

I find this odd, as other kinds of URL schemes work fine (e.g., I use DEVONthink links all the time). I wonder what the pattern is here.

is it the : in the middle?

Oh, right, I think it is. This issue came up before, probably on Discord. I can’t recall what the resolution was!

1 Like

Yes. That seems to be it.
If I replace the colon with %3A the link works. Would be cool if the colon would be accepted.

Why was this put into the Bug graveyard? A colon is a legit part of a URL, so a URL with colon should be clickable. We have the same problem with URLs including username:password like in .htaccess-secured sides.

sorry it was a mouse slip.
Does it work in preview?

1 Like

No. It’s shown as a link, but does not do anything in edit and preview-mode.


I’m not seeing any issues on my side:

Try inspecting the link with developer tools. Mine shows up correctly:

Run Obsidian from the command line to see the debug output:

The HTML looks like yours. If I copy/paste the HTML into a .html file and open it in any Browser the link works like it should. Only in Obsidian nothing happens clicking on it.

Sorry for the command line I need some guidance.


Steps to reproduce

Enter a bibdesk link such as


Expected result

BibDesk should open with that item. It does so from all sorts of other applications.

Actual result

Doesn’t work from within Obsidian. Other custom links like DevonThink Pro or plain URLs work.


  • Operating system: Big sur

  • Obsidian version: 0.11.0

We can’t see the contents of the example link. Can you paste it with preformatted text? e.g.,

`your link here`

This is a sample link that isn’t working from inside Obisidan:

[{How to Take Smart Notes}](x-bdsk://Ahrens:2017aa)

It is working perfectly well if I preview the document in some other markdown editor like MacDown.

Ah, I think it’s the colon in the URL’s “domain” or “path” components. I think you need to URL-encode those for now—replace : with %3A. Combining this with another bug report.

Confirmed. Works with %3A. Do you expect to fix that within the program? I’d rather prefer that since those links work like everywhere else unmodified. BibDesk uses those citation keys like Author:Year, and it would be quite awkward having them differently.

Man I just ran into this yesterday and worked on it a bit.

I made an Alfred workflow to copy an Obsidian-friendly addressbook:// URL from my contacts for easy pasting into Obsidian. I may put it up on GitHub in a bit after polishing. But until then, here’s the basic premise:

#!/usr/bin/env bash

_urlenc() {
  python3 -c 'import sys; from urllib.parse import quote,unquote; print(quote(unquote(sys.argv[1])));' "$STRING"

# pass the .abcdp filename as a parameter to this script...
# e.g. fullpath='/path/to/whatever/XXXXXXXXXXXXXXX:ABPerson.abcdp'
safe=$(urlenc "$abcdp")
name=$(mdls -raw -name kMDItemTitle "$fullpath")
echo "[$name](addressbook://$safe)"

I wonder how I’d make something like this work for BibDesk. It’s a pity as it breaks the integration if I’m to use bibdesk generated keys within Obsidian.

Posted this on the hook forum:

I’ve had a problem using those links from obsidian, which didn’t like the : I had in all my cite keys, like Nathan:2021. Obsidian would just not launch such urls. I ended up changing all of them by dashes, like Nathan-2021, which is kind of annoying wrt all the old stuff I wrote, but until obsidian has fixed it on their end, I’m good.

I ran into this problem today, so I created a simple Alfred workflow that allows me to paste URL encoded links, including BibDesk links, into Obsidian so that they don’t break.

It’s a very simple workflow, which uses a keyboard trigger (I’ve set mine up to be bound to shift-alt-command-U) to retrieve the contents of the clipboard, pass it through a small Python script and place the result back into the clipboard, while pasting it into the frontmost application, e.g., Obsidian.

It looks like this:

If you want to recreate something like this, here’s how I set it up.

The Hotkey component is set up with the following parameters:

  • Action: “Pass through to workflow”
  • Argument: “macOS Clipboard Contents”

The Copy to Clipboard component is set up with the following:

  • Type: “Plain Text”
  • [x]: Automatically paste to front most app
  • [x]: Mark item as transient in clipboard

The bulk of the work is done by the Run Script component:

  • Language: “/usr/bin/python”, “with input as argv”
  • running instances: “Sequentially”
  • Script:
# encoding: utf-8
import sys
from urllib import quote, unquote
uri = sys.argv[1]
delim = uri.find("://")
if delim == -1:
  # if protocol delimiter not found simple urlencode string
  # use position of delim to separate protocol and address
  sys.stdout.write(uri[:delim+3] + quote(unquote(uri[delim+3:])))

This script first tries to determine whether the clipboard contents contains a protocol delimiter. If this can’t be found it URL encodes the whole string. (This is helpful if you just want to transform some text, say a BibDesk cite key, for use in a URL.)

If the script discovers a protocol delimiter, however, it slices the string into the protocol and address, URL encodes the address only, and puts them back together again.

Either way the result is written to the standard output, so that it is passed to the Copy to Clipboard component.

I hope this helps.

Edit: Looking through @luckman212’s code for addessbook:// URIs, I realised that I should wrap the url encoding in quote(unquote(..)) instead of quote(..) to avoid mangling already encoded text. So I’ve updated the script.


This is in the graveyard, but the problem still persists. Are there any plans to fix it?
(I do realize there’s a workaround of replacing the colon with %3a, but it is kind of a hassle, and I have a lot of bibdesk entries with :'s that I’m trying to link to.)