Local images with links are not clickable, and have the external link icon offset when in Reading mode

[AlanG]

Demo using Sandbox vault

Steps to reproduce

1. Open the Sandbox vault.

2. Add any image to the vault. I have tested this with JPG and PNG.

3. Create an image link in this format:

[![](local_image.png)](https://obsidian.md/)

This format is in the CommonMark spec, example 516:

https://spec.commonmark.org/0.30/#example-516

Expected result

Actual result

Environment

SYSTEM INFO:
Obsidian version: v1.1.9
Installer version: v1.1.9
Operating system: Windows 10 Pro 10.0.19045
Login status: logged in
Catalyst license: vip
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

[AlanG]

Can anyone reproduce? This is happening for me with all images in all vaults on all platforms.

[rigmarole]

Yes I can reproduce. When I test it, it works with an html linked image. It also works with an absolute file:///path image. But not a local vault image.

I don’t personally know if it supposed to be supported. Do you know of any example or documentation that suggests this format is supported using local vault paths? Or did it used to work for you?

[ariehen]

Obsidian v0.15.9 has the same behavior for vault images.

[AlanG]

@rigmarole

Do you know of any example or documentation that suggests this format is supported using local vault paths?

It’s in the CommonMark spec with a local path, v0.30 example 516:

https://spec.commonmark.org/0.30/#example-516

@rigmarole

It also works with an absolute file:///path image. But not a local vault image.

This is very interesting, thanks for noticing this!

[rigmarole]

@AlanG

It’s in the CommonMark spec with a local path, v0.30 example 516:

I know it’s valid syntax for html. Have you seen any evidence in Obsidian documentation that a local vault path would be recognized?

An html relative filesystem path on a server and a local Vault path aren’t equivalent. They just look identical in syntax.

I agree it would be great if it worked. I’m just brainstorming why it might not be.

Example, relative images have never worked in html syntax for text links. I don’t know if that has ever changed:

Embed images with HTML and relative path

Hello! I already had read the documentation, forum, discord, and I did not find a solution to my problem. Here it goes: I need to handle more attributes of an image than just size, for example “center” the image, etc. Thus I need to use HTML tag [image] . So far, so good. I just need a URI. But I want to use images stored inside the vault. So far, so good, because right now I can use the file:/// to define an absolute path. BUT, because I’m a PUBLISH OBSIDIAN user, I cannot use absolute paths…

[AlanG]

@rigmarole

Have you seen any evidence in Obsidian documentation that a local vault path would be recognized?

I’m not exactly sure what you mean. Everything functions correctly, as in there is an image and there is also a functional link. So it’s clearly supported. It’s only the visual output which is a bit messed up.

[rigmarole]

You can’t click on the image as a link either. Only the little arrow. The fact it works at all might just be a coincidence. I’m not getting “clearly supported” vibes.

[AlanG]

I think we’re talking about different things. Your question which I quoted was about a local vault path being recognised. My reply was to say that the local vault path is indeed being parsed and turned into an image.

In the help docs there is an image with a local path (“og-image.png”):

https://help.obsidian.md/How+to/Format+your+notes#Images

And the CommonMark spec says that this is valid Markdown to encapsulate an image with a link in this way, so going back to my first post it looks like there is a bug with the conversion to HTML elements in the reading view.

(Obsidian supports CommonMark)

[WhiteNoise]

Ok, I get that the link icon is in the wrong spot, however it does work (a least for me). If I click on it, I can open the link.

[AlanG]

For a remote image, the entire item wrapped in the link is clickable as a link which is what you’d expect:

For a local image, the item which is wrapped in the link is not a clickable as a link:

You can click the little link icon which is handy as it means they’re still partially usable.

I don’t believe that the expected behaviour for a wrapped local item should be that only the little icon is clickable. I assume it should be the same as a remote image in that the whole wrapped item is clickable.

[WhiteNoise]

ok, right.