# Make tag:X/\* include the parent tag in search results

**URL:** <https://discourse.joplinapp.org/t/make-tag-x-include-the-parent-tag-in-search-results/51018>\
**Category:** Features\
**Created:** [19 September 2026 19:34 UTC](https://discourse.joplinapp.org/t/make-tag-x-include-the-parent-tag-in-search-results/51018 "2026-09-19T19:34:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![imsardine](https://yyz2.discourse-cdn.com/flex028/user_avatar/discourse.joplinapp.org/imsardine/32/16851_2.png) [@imsardine](https://discourse.joplinapp.org/u/imsardine)\
**Post date:** [19 September 2026 19:34 UTC](https://discourse.joplinapp.org/t/make-tag-x-include-the-parent-tag-in-search-results/51018/1 "2026-09-19T19:34:07Z")

</div>

I've been using `/` in tag names as a lightweight convention for grouping related tags, and I noticed a small limitation in the current search behavior.

For example, suppose I have these independent tags:

```plaintext
browser
browser/foo
browser/foo/bar
browserbase

```

Currently:

```plaintext
tag:browser

```

matches `browser` itself.

And:

```plaintext
tag:browser/*

```

matches tags such as `browser/foo` and `browser/foo/bar`, but doesn't match `browser` itself.

I could use:

```plaintext
tag:browser*

```

but that is broader than intended, since it can also match tags such as `browserbase`.

### My current workaround

At the moment, I work around this by explicitly adding a trailing `/` to tag names where the prefix could otherwise be ambiguous.

For example, instead of having:

```plaintext
browser
browser/foo
browserbase

```

I might use:

```plaintext
browser/
browser/foo
browserbase

```

so that searching with the `/` boundary avoids accidentally matching `browserbase`.

However, this doesn't feel like the right solution. It means some of my tags need to end in `/` while others don't, depending on whether their prefix happens to conflict with another tag. This makes tag naming inconsistent and exposes a search limitation in the tag names themselves.

Also, as far as Joplin is concerned, `browser` and `browser/` are two different tags, so adding the trailing slash isn't merely a search convention — it changes the actual tag name.

### Would it make sense for `tag:X/*` to include `X` itself?

In other words:

```plaintext
tag:X

```

would continue to mean **exactly `X`** , while:

```plaintext
tag:X/*

```

would mean **`X` itself plus everything under the `X/` prefix**.

So:

```plaintext
tag:browser/*

```

would match:

```plaintext
browser
browser/foo
browser/foo/bar

```

but not:

```plaintext
browserbase

```

And the same rule could work at any depth:

```plaintext
tag:browser/foo/*

```

would include `browser/foo` itself as well as tags beginning with `browser/foo/`.

This would remove the need to modify the actual parent tag name just to make subtree searches unambiguous.

### Not a request for hierarchical tags

I came across [PR #2572 — Added hierarchical/nested tags](https://github.com/laurent22/joplin/pull/2572), which previously implemented actual hierarchical/nested tags and was later reverted.

That's not quite what I'm suggesting here.

`browser`, `browser/foo`, etc. could remain completely independent flat tags. I'm only wondering whether `/` could act as a useful boundary for wildcard searches, with `/*` meaning "this tag and tags below this prefix".

That would give a fairly simple distinction:

```plaintext
tag:X → exact tag only
tag:X/* → X + tags under X/

```

For people who already use `/` as a naming convention, this would make it possible to search the whole group without the false matches that can result from `tag:X*`, and without having to add `/` to the actual parent tag name as a workaround.

There has also been some previous discussion around searching hierarchical tags, for example [Synonymous tags](https://discourse.joplinapp.org/t/synonymous-tags/20700), where `tag:birds*` was suggested as a possible way of searching a whole tag tree.

The [Inline Tag Navigator plugin](https://discourse.joplinapp.org/t/plugin-inline-tag-navigator-v2-12-1-2026-09-14/35726) also implements a similar idea for inline tags: searching a parent tag can find its nested child tags.

Would this search behavior make sense in Joplin, even without formal hierarchical-tag support?

---

<div class="post-metadata">

**Author:** ![imsardine](https://yyz2.discourse-cdn.com/flex028/user_avatar/discourse.joplinapp.org/imsardine/32/16851_2.png) [@imsardine](https://discourse.joplinapp.org/u/imsardine)\
**Post date:** [20 September 2026 04:10 UTC](https://discourse.joplinapp.org/t/make-tag-x-include-the-parent-tag-in-search-results/51018/2 "2026-09-20T04:10:59Z")

</div>

One more note: this can technically be worked around with:

```plaintext
any:1 tag:git tag:git/*

```

However, besides being unintuitive, `any:1` turns the whole query into OR logic, so it's no longer possible to express:

```plaintext
(tag:git OR tag:git/*) AND <another condition>

```

This is another reason why having `tag:git/*` represent the whole group (`git` + `git/*`) would be useful.

---

<div class="post-metadata">

**Author:** ![laurent](https://avatars.discourse-cdn.com/v4/letter/l/ce7236/32.png) [@laurent](https://discourse.joplinapp.org/u/laurent)\
**Post date:** [20 September 2026 16:30 UTC](https://discourse.joplinapp.org/t/make-tag-x-include-the-parent-tag-in-search-results/51018/3 "2026-09-20T16:30:53Z")

</div>

That would be a breaking change unfortunately so it's unlikely we can add this

---

<div class="post-metadata">

**Author:** ![imsardine](https://yyz2.discourse-cdn.com/flex028/user_avatar/discourse.joplinapp.org/imsardine/32/16851_2.png) [@imsardine](https://discourse.joplinapp.org/u/imsardine)\
**Post date:** [20 September 2026 17:41 UTC](https://discourse.joplinapp.org/t/make-tag-x-include-the-parent-tag-in-search-results/51018/4 "2026-09-20T17:41:44Z")

</div>

That makes sense. Perhaps this could be an opt-in search option instead, so the existing behavior remains unchanged?

The main goal is simply to have a way to include the exact parent tag when doing a wildcard tag search, while still being able to combine it with other conditions using AND logic.