Erratic handling of nested square brackets

There are bug reports of people not liking the way things in non-escaped single square brackets are highlighted (see this and this). I don’t think they should be highlighted either, but I realise that’s just a personal preference!

But preference aside, live preview is currently handling nested non-escaped square brackets erratically. Reading view displays everything perfectly sensibly and consistently so I’d describe this as a bug/set of bugs rather than personal preference. I hope I’ve managed to document this well!

Steps to reproduce

Here’s a test note in a brand new vault that has had nothing doing to it other than toggling live preview on:

Square bracket (1.6 KB)

Here’s a screenshot of live preview:

Expected result

  1. Works fine.
  2. Works fine.
  3. Opening internal link brackets hidden; closing single bracket should be grey.
  4. Works fine.
  5. Single square brackets should be visible; the text that’s not a link shouldn’t be underlined; the external link should be displayed as usual.

Actual result

  1. Works fine.
  2. Works fine.
  3. You can still see the opening double brackets for the internal link; the closing single bracket is black when it should be grey to match the opening bracket and to match the behaviour in examples 1 and 2.
  4. Works fine.
  5. Single square brackets not visible; text that isn’t a link is underlined; the external link is displayed as raw text, not in its live preview form.


Obsidian version: v0.14.5
Installer version: v0.14.2
Operating system: #1 SMP Debian 5.15.15-1 (2022-01-18) 5.15.0-3-amd64
Login status: logged in
Catalyst license: insider
Insider build toggle: on
Live preview: on
Legacy editor: off
Base theme: light
Community theme: none
Snippets enabled: 0
Safe mode: on


Actual result / 5. Single square brackets not visible; text that isn’t a link is underlined; the external link is displayed as raw text, not in its live preview form.

and it’s not clickable now on 1.1.9.

Filed another report:

Thanks! I edited the title and post to specify that the brackets are in the link text (since links always have brackets).



Steps to reproduce

With the Wikilinks setting turned off, type


Expected result

I would expect it to display


and upon clicking, for it to open “”.

Actual result

Displays “link(/”, and opens a new file called “link”.


	Operating system: ios 15.6.1 (Apple iPhone)
	Obsidian version: 1.4.3 (95)
	API version: v1.1.16
	Login status: not logged in
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on


Additional information

Some things I have tried:

  • Inserting spaces like this [ [link] ](/ . This simply displays the whole thing in plain text in the reading mode and the link doesn’t work at all.
  • Turning wikilinks back on. This doesn’t seem to change anything. I still see “link(/” in the reading mode, and it still opens a new note called “link”.

Also (thanks to a recent discussion in the Help section: Markdown links rendering strangely when [ ] is in the linking text )

  • It looks the same in the reading and the writing mode.
  • Removing the leading slash on the path doesn’t help.
  • Adding the brackets to the text of a working link produces the same behavior.
  • Escaping the inner and outer brackets doesn’t help.

The syntax for Markdown links requires single square brackets for the display text, and single round brackets for the url:



[display text](notes)

[display text](

display text

Respectfully I disagree. Single square brackets seems to be required by the current implementation in Obsidian, which prioritizes Wikilinks over original markdown links, but it is by no means a requirement for Markdown links in general.

For example, the following

[[example]]( "Title")

is rendered to the html

<p>An <a href="" title="Title">[example]</a></p>.

by the original markdown converter tool: Daring Fireball: Markdown Web Dingus

So it does look like a bug to me. I started the discussion in the Help section initially instead of a bug report, because it was not obvious to me if there was a further setting I needed to click to get the standard behavior.



Perhaps I have misunderstood. We are talking about regular Markdown links and using either single or double square brackets, yes?

The dingus you linked to shows a sample link with one square bracket only:

And in Gruber’s own words: ‘square brackets’, not double square brackets.

EDIT: You can also see the difference in this example:

Hope this helps and that I have understood the issue correctly. Apologies if I haven’t.

Yes we are talking about regular markdown links.

Standard markdown behavior would render the inner set of square brackets in the output, as shown in my last post. I am aware of what the original spec says - I want to see that second set of square brackets! That is what I would expect and how I like to use links. Obsidian does not do this even with Wikilinks disabled.

Okay, so maybe this shouldn’t be classed as a bug, but a feature request. For interoperability I think this should be supported.


If you want square brackets around the display text, you can use:

[[display text](]

[display text]

Not exactly what you want … hopefully someone else will have a better answer.

EDIT: Escaping the brackets also parses:




1 Like

Neither of those works in Obsidian, at least for me on iOS.

They do on my iPhone running iOS 1.4.3.

Have you got a TestFlight build?

EDIT: Tried with Wikilinks off and on; both work on iOS for me. Curious.

No. I’m also not testing with plugins and snippets off, tho, which I should do (tho I wouldn’t expect it to affect this). I’m testing on an iPad, which shouldn’t matter but it is a difference.

Oh wait, I see — looks like they work in Reading View. They don’t work in Live Preview.

1 Like

Great. I work in source and read so hadn’t looked at live preview. Checking now, I see the links in live preview but they aren’t displayed as cleanly as in read mode.

Hopefully this all adds to the pot for the OP and developers.

This might be relevant here: Live Preview image links


Before opening a new bug report, please search the forum for duplicates and follow the Troubleshooting Guide.

  • We only consider bugs that are reproducible in the sandbox vault or a vault with no third-party plugins/no css snippets/default theme.
  • For Linux, we only accept bug reports that are reproducible with our Appimage package under Gnome or KDE.
  • Developer issues with the API should go here

Once you’ve done the above, delete everything above this line.

Steps to reproduce

  1. Create a new note
  2. Type [name \[with brackets\]](link)
  3. Open the link

Did you follow the troubleshooting guide? [Y/N]


Expected result

Expected: The text should show name [with brackets] and opening the hyperlink should create a note

Actual result

Actual: The text shows [name [with brackets]] where square brackets belonging to hyperlink formatting are shown in the hyperlink text and nothing happens when opening the link.


Additional information

Yep, I just experienced this too! In the editor mode view only.


My test file

[link name without brackets](

[[link name] with brackets at start](

[link name with [brackets] in the middle](

Same behavior here (1.6.2 Mac):

CleanShot 2024-06-05 at 17.01.50

Expected behavior: Obsidian should treat the outer square brackets as part of the standard Markdown link syntax in all three cases. They should appear, when the cursor enters the link. The should disappear, when the cursor leaves the link.

I’d expect Markdown to be first priority in rendering Markdown. Wiki links should have second priority.

I think we’re talking here about Obsidian Flavored Markdown. Obsidian’s help pages state:

Obsidian supports CommonMark, GitHub Flavored Markdown, and LaTeX.

CommonMark Specs Version 0.31.2 specify in example 511 and following, how to format the “link text” of “inline links”:

  • The link text may contain balanced brackets, but not unbalanced ones, unless they are escaped.
  • The link text may contain inline content. However, links may not contain other links, at any level of nesting.

I interpret CommonMark as saying, that paired squared brackets in link text are just square brackets.