HTML inside Markdown links breaks it

Steps to reproduce

Write a link with some HTML in it, for example:

Expected result

The link text either renders with the HTML sanitized/escaped, or renders the HTML properly and shows the world superscript.

Actual result

The anchor element is stopped early at the start of the first HTML tag, renders the HTML (in this case a superscript), and then starts a new anchor after the closing tag. The former link has no href, the latter does. Due to Obsidian’s design quirk of not allowing Markdown inside HTML elements, this essentially makes it impossible to have non-Markdown elements inside a Markdown link, and impossible to have Markdown elements inside an HTML link. In my specific use case, I just want superscript…


  • Operating system: Windows 10 21H1 and Arch Linux
  • Debug info:
	Obsidian version: v1.1.9
	Installer version: v1.1.9
	Operating system: Windows 10 Enterprise N LTSC 2021 10.0.19044
	Login status: not logged in
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: none
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 3
	Plugins enabled: 0

Additional information

cursor in first hello:
cursor in world:
cursor in second hello:

I should note that internal links do render properly.

This isn’t a bug. This is how it works. You even linked to an explanation that it isn’t supported, so I don’t understand why you’ve posted this as a bug.

If you want to submit this superscript idea as a feature request, search the forum first before posting it to make sure it doesn’t exist already.

1 Like

The documentation reads:

We intentionally do not support parsing markdown syntax and blank lines within HTML blocks.

What I am doing here is HTML inside Markdown.

So either this edge-case should be listed as something also unsupported (and optimally the strange rendering resolved, like how it looks for internal links) or it should be fixed to render properly.

And yes, subscript/superscript has been discussed before, but never in this context. You can easily use <sub> or <sup> in most contexts so it’s not that much of a problem, but in situations like these there is simply no other alternative. As far as I can tell inline LaTeX does not work in Markdown links either, and it would be ugly even if it did work.

Ok, then for now I’ll reopen this and see what others say. Generally the two don’t mix.

For example, try making a basic <p></p> tag, and you’ll see no Markdown formatting works inside it.

I’m pretty sure this is not a bug. But I have enough doubt, I’ll leave it for now.

1 Like

Even if it isn’t intended to use HTML inside Markdown, and this sort of wonky functionality is to be expected, then it’s still a bug with the docs since it doesn’t mention it, unless I am not looking at the right page.

I’d still argue the HTML could be sanitized/encoded so that it looks the same as internal links:



Though it also has split anchors like the markdown link, it does work no matter where you click it.

Ah ok. Here is an answer. This is Markdown syntax. It is not supported in Markdown, so it isn’t supported in Obsidian. Daring Fireball: Markdown Syntax Documentation and How can I wrap my markdown in an HTML div? - Stack Overflow

I guess this would be a question of including all the Markdown specs in the Obsidian help, which is beyond the scope of the help docs.

I’ll close this again. And again if you have a specific request like superscript in a link, that can be a feature request (search first.)

You can use Markdown Attributes Plugin. :slightly_smiling_face:


  1. Create a new css file in the css snippets
  2. Copy the code below
  3. Save the file and activate it
  4. Bold the text you need and type {.sup}
.sup {
    vertical-align: super;
    font-size: smaller;
    font-weight: unset;
    color: var(--text-normal);

:slightly_smiling_face: :slightly_smiling_face: :slightly_smiling_face: :slightly_smiling_face:


I’m not sure what you are referencing from the original spec, and the StackOverflow answer is not related (Markdown inside HTML), but HTML inside Markdown is explicitly supported according to the original spec:

Span-level HTML tags — e.g. <span> , <cite> , or <del> — can be used anywhere in a Markdown paragraph, list item, or header. If you want, you can even use HTML tags instead of Markdown formatting

To show that Obsidian and its renderer does support this, the following works in the new editor and reader mode:




Now whether or not one should consider a link title to be within the “Markdown paragraph” is undefined, and the link section of the documentation does not specify what kind of text is allowed in a title. But other Markdown span-level elements work inside a link title, in every implementation of Markdown I’ve ever used, so I would assume span-level HTML to be in the same class. But this is splitting hairs.

I want to reiterate I am not talking about Markdown in HTML, I know that’s not supported. The fact that HTML in Markdown (something supported by Obsidian) has visual and functional inconsistencies that are not documented is what I am talking about here. Even if you want to say it’s not a bug, it’s still undefined functionality that produces unexpected output that messes with editor visuals in a way seemingly unintended. I would call that a bug, personally.

@KuiyueRO, thank you, that looks like it will work for me. Will give it a try soon.

Hopefully this post will serve to send people in the right direction if they encounter the same issue.

1 Like

Ok my bad, I’ll open it again. Sorry to flip flop, and sorry if I didn’t read carefully enough. I can see I got it totally backwards.

1 Like

I appreciate that. And I can see how I might have led to some of this confusion.

I mentioned “not allowing Markdown inside HTML elements” in the OP, just to stress that the situation was very limiting in what you could do with the markup, not that I was trying to put Markdown in HTML. I apologize for that, I should have been clearer.

I also somehow neglected to mention that the link works fine in reading view, just not live editing mode. That was where my insistence was coming from. Oops.

So for this text:
Here it is in live editing:
And here it is in reading view:
In live editing, the link is split at the boundaries of the brackets for both of the internal links:
But in reading view, the whole link is properly encapsulated for both internal links:

My bad for explaining myself poorly.