How To Search Within Notes and Custom Fields

Ask the Community Password Manager
, , ,
1

Basic Search

The default search on all the Bitwarden apps and clients uses a “Basic Search” format – just type in a string of text, and Bitwarden will look for that string within important fields in your vault entries, such as an item’s Name, a Folder name, a Username, or URI. For such fields, it does not matter if you type in the entire string exactly or if you just type in part of the string into the search bar. For example, if you use your email address [email protected] as the username for a login item in your vault, you can search by typing either the full email address or just the substring gmail and Bitwarden will find it.

Image1

Basic Search also works for Notes entries and Custom Fields as well, but with a caveat. Strings stored within these fields will not be searched by a sub-string search by default. For example, if you had a Custom Field defined in an item with the name SecondaryEmail and the value was [email protected], entering only hotmail in the search bar will not find the item. Instead, you must either type in the entire email address exactly as it was stored or use a Full-text Search to find the item.

Image2

Image3
.

Full-text Search (available in web vault, desktop apps, and browser extensions only)

The most reliable way to search for matching values in Notes or Custom Fields is with a full-text search. Using the above example of a Custom Field named SecondaryEmail, one could find all entries containing the string hotmail using this search term:

>*hotmail*

Note the leading > symbol, which tells Bitwarden to use full-text search, as well as the asterisk (*) characters surrounding the word hotmail, which tells the search engine to look for that sub-string anywhere in any entry.

Image4

If you are certain that the email ends in hotmail.com, then you could also just use one wildcard character by typing in your search term like this:

>*hotmail.com

Image5
.

See a video demonstration of searching within Notes below:

.

Other Capabilities of Full-text Searches

With full-text searchers, you also have some control over which folders or collections to search, you can build AND, OR, and NOT Boolean searches, or you can specify to search only within certain fields, such as an item’s Name, Notes, or a specific custom field, if you like. More information on wielding full-text searches can be found here:

.

Helpful References:

Search your Vault | Bitwarden Help Center

Custom Fields | Bitwarden Help Center

Search within and inside all notes

11 Likes
2

But why do not Bitwarden use full-text search by default, letting us type: hotm and get the exptected resaults?

If there is good reasoning for this, please add a an option in settings, giving users the ability to set their Bitwarden to full-text search by default, giving info on consequences.

2 Likes
3

Exactly, this is what I am thinking right now. Clearly, they need to improve the user friendliness and user ability of this application.

1 Like
4

Nah. If the default search was the advanced, full-text search, even more users would complain it was too difficult, You can’t please everyone,

Besides, is it really all that hard to type in one character to activate the full-text search? Seriously guys.

5

Lastpass does this.

I have multiple accounts signed up with the same email, the only variation being +1,+2,+3 etc.

I have to search:

myemail99+1*
myemail99+2*

So I have press two additional keys on the keyboard (1 more backspace and 1 more star) to go through and search the last email I signed and add 1 on top.

Why not just make the search just like any other Ctrl + F search? not sure what the point of the * wildcard adds other than an extra key to press and it’s not intuitive that users will know that. People want to see any and all matches and then they can select the one that is useful to them. Rather than not showing anything at all, it’s not intuitive.

1 Like
6

Rather than complain about the search workaround I posted here to try to help other users who were stuck searching inside of notes, please add your comments and vote to this feature request that seeks to add basic search functions to note fields and custom fields:

7

@agamon - FWIW, I agree with you that basic search should be extended to at least custom fields by default. I don’t understand, either, why searching inside of custom fields or notes requires a full-text search using special syntax. Your use-case is a good one - I hope you will add it to the feature request thread, along with your vote.

2 Likes
8

@dh024 In the wildcard searches shown in the video demonstration, why is the leading > character not needed?

9

Honestly, I don’t understand it either. My guess is that sub-string searches are disabled when using basic search inside notes and custom fields, so adding the asterisk enables it, without having to enter a full-text search with the > character. Makes little sense to me, but at least there is a workaround, albeit non-elegant.

1 Like
11

Every app has different ways of specifying extended capabilities. Who can remember it all? It’s not that it is one key, it’s that there isn’t a key that would be intuitive enough to remember.

Since most people would expect a search to be across all fields, then that is what the default should be. This isn’t a supposition on my part, I had to do the market analyses for one of my apps and found this to be overwhelmingly the case (and then I changed my app accordingly).

12

This highlights my main gripe with Bitwarden and the reason I will churn away if/when a better alternative arises – an arbitrary lack of feature parity across apps and OS’s, and random implementation details hindering the UX in each. Consumers shouldn’t have to “read the manual” and learn a long list of idiosyncratic gotchas.

If a user searches for a string in your app, they will naturally expect to see the exact same results across devices, environments, and OS’s. I am a super user and I still often forget that the iOS app search doesn’t include anything within notes.

Same issue with backup. Users will naturally expect backup functionality to include attachment and password history – essentially all information to restore an account to the state at the point the backup was made – but they don’t, so Bitwarden’s implementation of backup isn’t a real backup, and the omissions render the use of Bitwarden largely useless for storing any sort of important document, destroying the value proposition and forcing users to use other alternatives (if/when they even become aware of this issue).

IMO Bitwarden needs to focus long and hard on unifying the experience across all apps, and ensuring existing functionality is “fully” implemented, before tackling new features; they also shouldn’t stagger new feature implementation across OS’s or devices, unless that feature is something inherent or specific to that OS/device.

2 Likes
13

Full text search should be the default without the need to add those special characters. I just got confused by this behavior of bitwarden and had to search it up.

The fact that you have to type the > character is very strange and unconventional, whereas the current behavior can be achieved by the existing and more conventional approach of specifying fields.

Analogously, it would be strange for Google search to search only the title of a webpage. And google could implement a feature where you specify something like title:xxx to search only within the title field.

1 Like
14

@toshiki Welcome to the forum!

In the Web Vault app, browser extensions, and Desktop app, Bitwarden does use full-text search by default, and it will search not only the vault item name. but also the URLs, usernames, notes, custom fields, among other fields.

1 Like
15

Thanks. Sorry I meant the “sub-string search” that people discussed above. Yes, it searches those fields but I need to type >*xxx* to search xxx. The “normal” search doesn’t apply to notes. I don’t understand why this distinction was made. It seems to have brought confusing complexity.

The problem I encountered was that for some websites I put the email in the notes, and the username in the Username field. Now I want to find all accounts using a certain email but it turns out the search string is not finding all accounts using that email because the email is written in the notes. If I didn’t noticed this strange behavior of bitwarden, I could have missed many accounts using that email. I feel this behavior is unexpected and can potentially cause problems.

16

It does, though (as long as you’re in the Web Vault, Desktop app, or a browser extension). You don’t need to use the “>” prefix to search for words that appear in the “Notes” section of a vault item.

For one of the accounts that is not found in your search, please show exactly how the email address has been recorded in the Notes section (you can redact the email address for privacy, but please show any characters that appear before or after the email address), and also show what search expression you are using.

17

> is not needed but * is needed.

The [email protected] in the note has to be searched by *xxx*.

18

You can search for this using either [email protected], or some variation of yx*, yxx*, y*@y.com, etc. Only if you wish to search notes for a substring that is both preceded and followed by non-whitespace characters will you both a leading and trailing wildcard (e.g., *x@y*).

19

Yes. But why making the note field special? It’s very confusing to make the search function work so differently in just the note field. I doubt if there’s any user who expect this without searching for the documentation first.

It’s about the design choice. The current behavior (1) doesn’t conform to the conventional search function (the browser search, most pdf readers’ search, etc); (2) can lead to problems such as missing accounts in the use case I wrote before.

20

It’s actually the Name, Username, and URI fields that are “special”, in that they can be searched using “Basic” search (which automatically uses leading and trailing wildcards for all search terms). All other fields (including notes, custom fields, and attachment file names) require wildcards to represent omitted non-whitespace text.