Change Default Search to Wildcard Rather Than Exact Match

Great to see the much improved search functionality in Bitwarden.

I have read the linked article for search options but I suspect a lot of users won’t and either won’t get the results they want or will think it’s not working properly when doing a partial search.

I would suggest that the search option defaults to a wildcard search, for example, if you enter “pass” in the search field, it actually searches for “pass*”. When I think of any software applications I use, they all produce a wildcard search result and this change would make Bitwarden behave much more like the “standard” and give people the results they expect.

This is already the way search works:

The following fields automatically include trailing wildcard searches while performing normal search queries:


It is not necessary to provide trailing wildcards if you are searching these fields.

1 Like

Yes, but not other fields. Is there a reason that you don’t use wildcard on all fields?

We use notes extensively and are really pleased to have the enhanced search capabilities. Personally I’m not that bothered as I know how to perform a wildcard search on those fields but I do think it will confuse users, who mostly don’t read the documentation!

performance. A wildcard search is an expensive operation.

1 Like

Ah. Well it probably makes sense then.

Personally, we are using a self-hosted server with only a few users so performance isn’t an issue but I can understand it could be significant for the public server.

Search is performed on the clients, the server has zero knowledge on what’s stored in your vault. So it all depends on the device you’re using, not how well your server performs or how many users exist :wink:

I can understand that for an app where you have a copy of the data on the device and do’t necessarily have an internet connection but I would be surprised if that were the case for the web vault. Otherwise you would have to download a copy of the data every time you did a search.

I’m not a programmer so I haven’t looked at the code. I am prepared to be completely wrong!

Unfortunately our team doesn’t find much with the new full-text search either. They are used to the filtering search like 1Password does:

For example, lets say we have the following entries:

[AlphaCom] [] [LiveConfig] admin  
[2ndCompany] [LiveConfig] [email protected]  
[AnotherCustomer] [LiveConfig] [email protected]

My coworkers would intuitively just type alpha livec to find the first one - live mail.2nd for the second or another [email protected] for the 3rd one. To accomplish this, right now they would use a syntax like this:

>+*alpha* +*livec*
>+*live* +*mail.2nd*
>+*another* +*[email protected]*

Is there any way to make the search behaviour more intuitive without the need to use advanced Lunr search queries?


If I’m not mistaken (@kspearrin ?), the web vault uses your browser’s local storage to store your data. It performs all operations in this storage, locally to your browser. Only encrypted data is transmitted back to the server for sync.

Yes, all searches happen local to the device. There is no query back to the server.

@frdmn We intend to perform leading wildcard searches too which would hopefully make this even better, but we’re blocked by a bug in Lunr at the moment:


Well there you go, I did say I was prepared to be completely wrong!

Hello ! Any way to search in the other way ? It’s absolutely destabilizing when you search for example “Doctor CityA” and all the entry for Doctor and CitiyA are displayed.

I would like to ask to set default search in exact match but I will ask How to make a exact match please?

Sounds like you want to use an advanced term presence search.

Adding + before each terms seems to do the job… thanks

Should this issue be fixed in the latest (2.5.0) release? I just did some tests and do not notice any difference regarding search behaviour.

We also get lots of complains of users who can not get used to the (rather complex) Lunr search syntax.

Leading and trailing wildcard searches will automatically happen with the title. You don’t need to perform an advanced Lunr search query.

Hmm - it doesn’t look like it. Take a look at the example scenario here…

Disclaimer: As mentioned in another post, we use a “naming scheme” to add certain tags to the title of each password entry. This includes the customers name and allows us (in theory) to quickly find all related entries associated to a certain customer (customerXYZ in the example below).

All data/entries for customerYZX

For easier understanding, here’s the available entries / passwords that we have in our database related to the customer in question - basically just to depict the structure of the customers password entries:

Search term
Search result

Current search behaviour/result

Now, the goal in this search scenario is to only list entries that also contains the beta keyword in the title (which shouldn’t be much of a problem, since their hostname contains “beta” and the hostname is a tag in our naming scheme). Based on alternative password managers, I would try the following search keywords to accomplish this:

Search term
customerXYZ beta
Search result

As you can see, this only yields a single result, but skips all the other beta-related entries.

Desired search behaviour/result

To actuall make all the (desired) “beta” related entries show up, I (or our users) have to use a very complex search syntax like this:

Search term
>+*customerXZY* +*beta*
Search result

Sorry for nagging about this, but is there any way to adapt a more intuitive way to search/filter results without using LunrJS’s syntax?

Our users keep complaining about this and in fact still stick to the old password manager (which actually is read-only nowadays for a migration to BW) because “they never find anything they actually looking for” in BW - I’m slowly running out of ideas to make it more palatable for them :frowning:

@frdmn Does the following work for what you are looking for? I don’t think you need the inclusion +


Unfortunately no. It doesn’t yield any result at all:

I see. Since “customerXYZ” and “beta” are in two different words (delimited by space), they are searched as separate terms. The following should work though. Maybe we can adjust the default search to wildcard each search word like this.

*customerXYZ* *beta*
1 Like