`, etc. used for formatting.
Example:
```auto
übersetzen
```
Searching for `übersetzen` does **not return a match** , even though the word is there – just split across HTML tags.
Worse, in more complex formatting like:
```auto
gestresst
```
I cannot find the word `gestresst` at all, because it’s broken into several HTML segments. This makes browsing inconsistent and frustrating.
* * *
**Describe the solution you’d like.**
I’d love to have a search modifier like:
```auto
plain:gestresst
```
That would search the **text content only** , ignoring all HTML tags and formatting. It should match:
- `gestresst`
- `gestresst`
- `gestresst`
- or even more broken-up versions
Alternatively, a simple checkbox in the Browse UI like:
**[✓] Ignore HTML in search**
would make this much easier to handle.
* * *
**Describe alternatives you’ve considered.**
- Using wildcards:
e.g. `Back:*>ge<* OR Back:ge` helps **if the prefix is entirely in a tag** , but fails when tags are split mid-word.
- Adding a duplicate “clean” field (no HTML) to each note just for searching — works, but is clunky, adds overhead, and makes note editing prone to errors.
- Regular expressions don’t help either because the word is no longer contiguous in the raw HTML.
* * *
**Why this matters**
For learners of languages like German, highlighting stems/prefixes (e.g. `ab`, `un`, `ge`) using bold or color helps with memorization — but it completely breaks search.
Adding a simple option to search **the plain text only** would greatly improve the experience and eliminate confusion when browsing existing notes.
Thank you for considering this!
---
**Author:**  [@Anon\_0000](https://forums.ankiweb.net/u/Anon_0000)\
**Post date:** [January 24, 2026, 8:54pm UTC](https://forums.ankiweb.net/t/feature-request-option-to-ignore-html-tags-in-browse-search/68423/2 "2026-01-24T20:54:58Z")
You should configure that field to be a sort field. It should then work just fine, see [Searching - Anki Manual](https://docs.ankiweb.net/searching.html) :
> Anki is only able to search within formatting in the sort field you’ve configured. For example, if you add “ **exa** mple” to one of your fields, with the “exa” part in bold, this will not be matched when searching for `example` unless that field is the sort field. If a word is not formatted, or the formatting does not change in the middle of the word, then Anki will be able to find it in any field.
**Edit:** For completeness, to learn how to set a field as a sort field, see [Adding/Editing - Anki Manual](https://docs.ankiweb.net/editing.html?highlight=sort%20field#customizing-fields).
---
**Author:**  [@kaiu](https://forums.ankiweb.net/u/kaiu)\
**Post date:** [January 25, 2026, 12:28am UTC](https://forums.ankiweb.net/t/feature-request-option-to-ignore-html-tags-in-browse-search/68423/3 "2026-01-25T00:28:34Z")
> [@PeterBE](#):
>
> Regular expressions don’t help either because the word is no longer contiguous in the raw HTML.
You can find it using a Regular expressions search, but it will strictly remove everything in \<\>, and the query is long and cumbersome to type. The speed isn’t as great, but overall, it’s possible to implement this with an add-on.
---
**Author:**  [@kaiu](https://forums.ankiweb.net/u/kaiu)\
**Post date:** [January 25, 2026, 1:50pm UTC](https://forums.ankiweb.net/t/feature-request-option-to-ignore-html-tags-in-browse-search/68423/4 "2026-01-25T13:50:21Z")
I found this useful for my own use as well. Although I’ve long since gotten used to not using formatting, as it’s beautiful and convenient, it wastes my time. Still, someone really needs it and will find it important to search for. And for myself, we also have accent marks on some characters, and finding these was problematic.
So you can try all this in the add-on:
[https://ankiweb.net/shared/info/1334324384](https://ankiweb.net/shared/info/1334324384)
**Added since version 3.9.2b, date: 2026-01-25**
The “$:text” search type is now supported. This will find all words, even if each character is followed by an diacritic (a mark that changes the sound) or if there are tags between letters (bold, etc.) – it will find everything.
The search is not case-sensitive.
To perform this search within a regular expression `("re:")`, you must write it as a call to the $(text) function.
How it works: instead of `$:abc`, the search will be `"re:a[\u0300-\u036F]*(<[^>]*>)*"b[\u0300-\u036F]*(<[^>]*>)*c"`
---
**Author:**  [@waschmaschine](https://forums.ankiweb.net/u/waschmaschine)\
**Post date:** [June 1, 2026, 5:26pm UTC](https://forums.ankiweb.net/t/feature-request-option-to-ignore-html-tags-in-browse-search/68423/5 "2026-06-01T17:26:28Z")
**Problem**
I’m using Anki to learn vocabulary and use HTML tags to highlight parts of words whose pronounciation differs from the standard way of how to pronounce words.
Example: (please ignore the whitespaces around the tags, I’m not able to post this otherwise)
> wor\< span style=“color: rgb(255, 0, 0);” \>r\< /span \>d
Here I’m using tags to highlight the “r” as red to show that it’s pronounced differently (made up example).
However, using tags this way (in the middle of a word) means that seaches for this word (here: “word”) don’t show the entry above.
**Proposed solution**
“Tools \> Preferences \> Editing \> Browsing” aready has the option
- “Ignore accents in search (slower)”.
The following option could be added:
- “Ignore tags in search (slower)”.
**Alternatives I have considered**
At the moment, for each field in a note which can contain words which may need highlighting (i.e., words in the language I want to learn) I added another field which will contain the same information; and only one of those otherwise identical fields will have the highlighting using tags. This way, the search still workds. However, this leads to duplication of information and more fields in notes.
**More information**
This seems to have been already implemented in this add-on: [https://ankiweb.net/shared/info/1334324384](https://ankiweb.net/shared/info/1334324384)
> This will find all words, even if […] there are tags between letters (bold, etc.) – it will find everything.
---
**Author:**  [@Danika\_Dakika](https://forums.ankiweb.net/u/Danika_Dakika)\
**Post date:** [June 1, 2026, 5:44pm UTC](https://forums.ankiweb.net/t/feature-request-option-to-ignore-html-tags-in-browse-search/68423/6 "2026-06-01T17:44:13Z")
I merged your post into an existing thread.
---
**Author:**  [@waschmaschine](https://forums.ankiweb.net/u/waschmaschine)\
**Post date:** [June 1, 2026, 6:16pm UTC](https://forums.ankiweb.net/t/feature-request-option-to-ignore-html-tags-in-browse-search/68423/7 "2026-06-01T18:16:14Z")
> [@Anon\_0000](#):
>
> You should configure that field to be a sort field.
I don’t think this is a sustainable solution, because one might want to search multiple fields and afaik Anki allows only one field to be the sort field.
---
**Author:**  [@abdo](https://forums.ankiweb.net/u/abdo)\
**Post date:** [June 1, 2026, 6:22pm UTC](https://forums.ankiweb.net/t/feature-request-option-to-ignore-html-tags-in-browse-search/68423/8 "2026-06-01T18:22:22Z")
There’s an old issue for that, but it was never prioritized:
>
>
> Currently the sort field stores the contents of a single field with HTML strippe…d. This enables faster sorting, and allows the user to find text that has embedded HTML in it, if that text occurs in the sort field.
>
> There are some downsides to the current approach:
>
> \- if the user tries to search for text with embedded HTML that is not in the sort field, it is not found
> \- substring matches require a full table scan
> \- the current HTML stripping replaces tags with an empty string, so \`foo\bar\` becomes \`foobar\`. Because the lack of spaces is hard to read, the browse screen currently loads the full field content and uses a different HTML stripping routine that replaces the tags with a space, which is more expensive.
>
> If instead of inserting just a single field into the sort field, we inserted sort\_field + all\_other\_fields, using the standard field separator, it would solve the searching issue, at the cost of extra disk space.
>
> A more comprehensive alternative would be to use sqlite's FTS, which is something I haven't really looked into yet. I gather it does quite well with space-separated text, but it may not be as useful for languages like Japanese? I'm also a bit concerned by the previous security issues it had, which could be triggered with malformed databases.