I’d like to share some feedback regarding the search functionality, specifically around how item names containing special characters (dots, underscores, hyphens) are handled.
I manage a vault with 500+ entries, many of which follow structured naming conventions like “example.host.local” or “server_name_prod”. This includes multiple client collections, where consistent naming conventions are essential for quick access. On the mobile app, searching for any part of these names works perfectly. On the web vault, desktop app and browser extension however, the Lunr-based full-text search tokenizes these names in ways that make everyday searching unreliable and inconsistent.
Concrete examples from my vault:
Entry name: example ILO-ESXi
Search example ilo → found
Search example esx → not found
Search example esxi → not found
Expected: searching for esx or ESX should return an entry named ESXi
Entry name: example contact.ma.iphones
Search example contact → found
Search example ma → not found
Search example iphones → not found
This means partial token matches (e.g. esx within ESXi) are not supported, and dot-separated segments are not reliably indexed as individual searchable tokens — making structured names like hostnames, FQDNs or categorized entries very difficult to find.
The frustrating part: based on community advice suggesting underscores were safer than dots for search, I renamed 200+ entries — only to discover that underscores are also treated as token separators. That was a significant amount of wasted effort, especially across multiple client collections where naming had to be coordinated carefully.
I completely understand that Lunr is a powerful search engine with real advantages, and I appreciate the advanced query syntax (>+name:example +name:host) — though even that doesn’t reliably surface all entries. For everyday use, the mobile app’s simple substring search is genuinely more practical for structured item names. The current inconsistency between mobile and all other clients is confusing and hard to work around without memorizing query syntax.
A few suggestions:
Fall back to a substring match when Lunr returns zero results
Support partial token matching (e.g. esx should match ESXi)
Treat dots, underscores and hyphens as part of the token rather than separators — or at least make this configurable
Add a note in the documentation clarifying which characters cause tokenization, so users don’t rename hundreds of entries unnecessarily
Thanks for building a great product overall — this is meant as constructive feedback from a user who genuinely relies on Bitwarden daily.
If possible, download version 2026.4.0 of the portable Desktop app, and see if any of your problems are fixed. The portable version of the app will not affect your current installation — when first launched, it will create a subfolder named bitwarden-appdata in the same folder where you saved the Bitwarden-Portable-2026.4.0.exe file; to uninstall after you are done testing, simply delete the .exe file and its subfolder.
The Lunr search engine tokenizes using space and hyphen characters as separators. However, by default, searching in the browser extension, desktop app, and web app will insert leading and trailing wildcards for each of your search terms (although this is one function that may not be working reliably in version 2026.5.0). Thus, all of your “not found” examples should be found (in version 2026.4.0 and earlier).
In addition, normally, search terms separated by spaces are combined using boolean OR, so in your examples, the example token should have been sufficient to find both of the entries, and adding the second term (ilo, ma, etc.) should only surface additional entries, not hide the entries that you were trying to find. I have confirmed that in version 2026.5.0 of the desktop app, the search behaves as you have described, which is not the expected behavior.
I think that what you have described is a new bug, different from the ones that I listed above (although it bears some similarity to Issue #21062). Bugs should generally be reported on Github.