Whitelisting or blacklisting forms



This is a draft. It’s better than nothing but is based upon an imperfect example and lacking screenshots so a lot more work is required. Feel free to suggest a better example if you work through one before we have time to complete this document.

Kee tries to estimate which forms are login forms and which are not. It’s technically impossible to get this right every time on every website so we try to strike a balance between offering to fill and save passwords on nearly all login forms while avoiding doing so on too many other forms such as search boxes, contact forms or surveys.

If one of your regularly visited sites contains a form that Kee does not correctly identify as a login form (or vice-versa), you can usually override Kee’s behaviour by using the advanced functionality within the Kee Options tab.

The following example walks through marking a form as a login form by utilising the whitelist functionality. You can do the opposite by using the blacklist functionality.

Note that this configuration affects the detection of forms rather than the selection of login entries to be filled into a form. Just because Kee identifies a login form, does not necessarily mean that it will find a suitable entry to fill into that form, nor that it will be able to identify exactly how to automatically fill or submit that form. These are separate concerns so you will occasionally find that even by following these steps, the full Kee functionality may not be available on the website for the whole host of reasons discussed elsewhere on this forum (most commonly that the website uses custom Javascript which prevents password managers from interacting correctly with the login form).

To add a form to the whitelist, you first need to find one of four identifiers for the form:

  1. The form ID
  2. The form name
  3. The ID of one of the fields within the form
  4. The name of one of the fields within the form

Usually you would do this by right-clicking on the username box and selecting “Inspect element” to open the browser developer tools. The item you right-clicked on should already be selected but if not, you may need to navigate the source code of the page to find a suitable form field or the form that contains the field.

Once you have found a suitable form field or the form itself, look at the attributes in the source code and try to find one called “id” (preferably) or “name” and make a note of it. In this example we will use the ID of a form field “MainContent_txtMembershipNumber”.

Now go to Kee Options and select the radio button to switch into “specific website” mode.

Type the part of the URL that you want this setting to apply to. In this case, we will use “nationaldental.co.uk” and change the option on the popup panel to “domain” which will enable this configuration to apply to all web pages that are part of the nationaldental.co.uk domain name (including, for example, https://www.nationaldental.co.uk). You can be more specific if necessary, or adjust how accurately the address of a web page must match the text you enter for the “target”. Very advanced users may want to change the weight from the default of 100 but for most people you can just click “Save”.

Next, enable the checkbox next to the relevant part of the “Finding forms” configuration section and paste the identifier you found earlier into the box. In this case, we’re whitelisting a “Text field ID”.

NB: It appears that a bug in the options page on some versions of Chrome means that you must click outside of the box once you have entered the identifier or your change will not be saved. We’ll try to develop a workaround for this in the coming months and remove this notice when that is done or when Google fix the underlying bug in their browser.

List of sites where Kee should be improved
Specific Website Settings
Placeholder handling
Potential feature: Ignore some fields
How to configure the new Contextual Kee buttons

Hi luckyrat,

first of all thank you for your helpful instructions! Using form or field id’s or names in the whitelist or blacklist works pretty well.

Jobwise I have to login to lots of websites based on content management systems the ones of which contain lots of forms for all kinds of options and settings. I experimented with different options on Kee’s URL panel within KeePass to prevent Kee from mingling with every form it finds - to no avail. So your suggestion helped me a lot, only there are a lot of form/field id’s I have to blacklist.

Wouldn’t it be much easier if Kee would offer an option to ignore the current form or field (provided Kee finds a respective id or name) in that field entry menu like so …


… and automatically add the form/field id/name to the blacklist?


Also see: Potential feature: Ignore some fields


Hi luckyrat,

Thank you for this help !

I have seen lot of issues about blacklists but I think whitelists are very important tools too. It would be really nice to detect the name or id of the field without looking at the browser inspector directly (as an option in Kee to add the fields id in the whitelist). Editing the whitelist is indeed quite painful because everything is on the same line.

Some details are also hard to find like no space after comma (once you know, it works really well but I did not undertand why it was not working before I found this).

I was wondering if it was possible to fill the fields specified in KeePassRPC automatically without using whitelist, there are case where you need to specified the field in whitelist to have the Kee logo in it, this is not expected by the average user I would say. But I think you talked about a related security issue ?

The typical use case of whitelist is the one in this issue (google TOTP) : https://github.com/kee-org/keepassrpc/issues/45 . I think it deserves a place in the documentation of whitelists (the screenshots of pyro-dev are really nice) because you are confronted to it as soon as you activate 2FA.



Thanks both for your comments and links.

I agree that it’s worth linking the concepts of placeholders and whitelisting because Kee will only attempt to fill in forms it’s reasonably sure are username or password fields (TOTP fields therefore are often ignored when not part of a single username/password form). I’ve added a note to this effect in the placeholder documentation.

Developing a more user-friendly way to manage the lists is something I’ve wanted to do for as long as the feature has existed but have yet to have enough time to work on it. It’s a case of having the feature at all being better than no ability to override the behaviour but I know it’s a very involved process, especially for people with little technical knowledge.


I guess you added the condition of having a username/password in the form to activate Kee because it would fill any field in any page elsewhere. The note on TOTP in placeholder documentation is very helping by the way.

To manage the lists I would say that optimally, Kee should fill the forms as soon as there is a corresponding entry for the webpage and one of the field name or id specified in the KeePassRPC tab appears in it. It solves the current problem which is that you have to write the field name/id two times : in KeePassRPC and in Kee whitelist. According to me, if you write it in KeePassRPC and enable placeholder it somehow means that the user is already aware about security issues and rare bad filling attempts. Maybe you can find a security issue in my argument because I am not really well aware of everything.

Also, it could be very nice to have a field selector as in KeePassHttp to complete the KeePassRPC without the inspector (but yeah, lot of work, it can wait)

I bet all of this is a really big work given the time you have and that maybe you have to rewrite some core part of Kee. So if you lack of time, maybe you can improve the presentation of whitelist in Kee for now.

I think that you should use a textbox rather than just a big line to show what fields are in the list, we can’t see currently entirely the whitelist in one look it is really annoying.
You can index the list with the output of the field : one whitelist for username, one for password, one for otp … without changing anything in the current field management ! It just allow to structure the different parts and remember what this field is for (in the global whitelist especially).
And you should give the user to add output type as before in the list and filling it with the good fields name/id.

Hope this help !