Forbidden tag characters are allowed in properties

Steps to reproduce

  1. In the sandbox vault, add the following to the top of the “Start Here” note:

    tags: []
  2. Search

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


Expected result

No results, because “.” Isn’t allowed in tags. Tags - Obsidian Help

Actual result

“Start Here” appears as a result.


Obsidian version: v1.3.5
Installer version: v1.3.5
Operating system: Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:19 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T8103 22.5.0
Login status: logged in
Catalyst license: none
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 0
Plugins enabled: 0


Additional information

To verify it’s not a false positive (matching tag:test because of word splitting or something), search tag:test — no results.

Tags in the note body automatically end at “.”.

This bug was discovered when @ClareMacrae was experimenting in the Insider build to see what constitutes a tag in Obsidian. The discussion starts at Discord.

This bug was reported before but closed in what looks like a misunderstanding. It is possible to create a tag with dot


Lots of other symbols validate as tags, including curly and straight quotes in the sample below.

Wonder what properties makes of them in 1.4.x

tags: [, work;ing, do:ing, lov*ing, say"ing, play'ing, hop’ing, slop”ing,]


Perhaps ties in with this:

Alias wrapped in quotation marks splitting at comma - Bug graveyard - Obsidian Forum

The same thing happens with tags.


YAML entry with commas within quotation marks should produce a single entry - Feature requests - Obsidian Forum

To repeat myself in the bug report, the current behavior is not standard.

(Not referring to tags directly but insinuated from the first link.)


YAML entry 1.4

In v1.4, this divergence from the standard is being addressed. We will begin with rewriting the incorrect form to a compliant one and eventually (at some point in the future) stop supporting the incorrect format.

(Not referring to tags directly but insinuated from the first link.)

1 Like

They appear as valid YAML/ Properties “tags” …

They’re accounted for and searchable too …

The #atag auto-completor suggests them when adding a #atag in the content of a note …

… But no, they’re not considered as valid / work as #atag once inserted in a note as they’re split at the invalid character (or inserted, as I tested this earlier, as a string for numerical Properties tags)

In other words, there’s still an inconsistency in how Obsidian treats YAML / Properties tags vs. note content #atag … which, from a user point of view, might generally be confusing :thinking:

I guess there might be some reasons to not restrict the use of forbidden characters in Properties / YAML for tags (as they’re valid YAML and these tags containing “forbidden” characters might be useful to some) but then I don’t really see the point of suggesting them in the content of a note (as they won’t work as such anyway) or simply not allowing “forbidden” characters in #atag all together… And by that I mean : if they’re valid Properties (YAML) tags, IMHO, they should also be valid or work as note content #atag as written/used in Properties

Unless, these characters are forbidden in note content #atag because other markdown processors might also not allow them ? :thinking:

In any cases, if the inconsistency can’t be fixed in a way or another, I agree with @ClareMacrae : The inconsistency could be highlighted/explained a little bit more in the documentation :innocent: .

(Take this with a grain of salt though, I’ve never been a big user of tags/#atag :innocent: … The conversation on Discord just got me curious :blush: )


Many thanks for the insight. Feel like I am anomaly tripping.

Hope it will all be rationalized one day.

1 Like

I think they’re forbidden for compatibility/simplicity. “Most or all platforms that support hashtags permit the inclusion of letters (without diacritics), numerals, and underscores. Other characters may be supported on a platform-by-platform basis. Some characters, such as & are generally not supported as they may already serve other search functions.” — Hashtag - Wikipedia

I’d guess the behavior in YAML is unintentional. Probably forbidden characters should be disallowed in the “tags” field and treated like body tags elsewhere.

1 Like

Interesting :grin: ! Thank you very much for these precisions :blush: !

will be fixed Desktop 1.4.6


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.