Base domain versus host: best of both worlds

For the Auto Fill option I like choosing Host here. But when I chose Base Domain, I got more choices. I want the best of both worlds. I just want my Host choices first and then the remaining Base Domain choices tacked on at the end.

By the way, you will notice the extra small font in the pop-up menu in the middle of the screen. Also there ought to be a help button as a third button and pressing it will bring us to the familiar web page that explains all this.

1 Like

Actually, why in the world, are not the best matches presented first in the Base Name list? Apparently just all the matches are just thrown one after another, with no ordering at all. Oh okay maybe they’re alphabetically ordered. But why not have the best matches first? I mean if we are on a site that is a perfect match that match should not be way down at the bottom of the list just because it starts with a w.

If we are logging in to W.B.C that should be the first that we seen the list and not A.B.C, B.B.C, C.B.C…

In fact, we get about 8 or 9 choices deep and that seems to be the limit and then the final choice is the Bitwarden vault. So even the perfect choice (100% match) might be too far down the list and won’t even show and we have to tap the vault to get to them.

Yes I’m talking about the behavior when one has Base Name selected as one preferred Auto Fill method.

It is not clear what you are asking for, or you may have misunderstood the purpose of the setting, which has nothing to do with sorting of vault items.

For each URI stored in every login item in the vault, you have the ability to specify the match detection method, which is used only for the purpose of determining whether it will be possible for associated the login credentials to be auto-filled at the URI in question.

The setting that you are playing with in the screenshot you posted specifies which of the available match detection methods should be used by default, for any stored URIs that do not have a customized match detection option. The default value can really only be one of the available options, so your request doesn’t make sense. If you want to customize the auto-fill behavior for specific sites, you would change the match detection option for those specific URIs, not the global default.

Your follow-up post makes even less sense to me, but perhaps that is because I don’t use the mobile app. But in my time on the forum, I have never heard of a “base name list”, nor any option to have “base name selected as one preferred Auto Fill method.” Certainly the browser extension, desktop, and web vault apps have no such features, and the Help Center documentation also does not describe anything of the kind. Apologies if this is an undocumented feature in the mobile app that I am not familiar with.

Okay! Let me Express this in terms that probably are applicable to the desktop experience too. I’m using totally default settings in my example here. Okay let’s say you’re on this webmail website and you choose to go to the vault:

Okay now we are in the vault, and where is the website that we were just on? It’s way down at the very bottom. Because it started with a “w” .

I am just saying that instead of always just giving alphabetical order, some sensitivity should be applied here by noticing that the site we have just come from is indeed right there on the list and should be elevated to the top. That would also benefit cell phone users because their lists are limited in length and less accessible.

Not only could they be moved to the top, they could also be in some different color or have a star added to them or be highlighted or something, because they are perfect matches. I’m talking about the last two entries in the immediately above photo.

Well, none of the above looks anything like the desktop or browser extension, but by reviewing the documentation for Android, I’ve determined that your last screenshot is a list of vault items that have at least one URI matching the site that you are visiting.

This begs the question: why do you have so many matching items for a single site? Do you really have a dozen different login accounts on the same website? This is not a standard use-case, so perhaps if you explain a little why you need to have so many different accounts for the same site, that would be helpful.

Also helpful would be if you could share the full URL of these web sites (substituting private information using aliases, if necessary).

1 Like

Well, sure, the user might have,,,,,, etc. And then he might even have a different test account, jimmy-test@, in addition to jimmy@ on one of those too.

Anyway, even if there’s only two matches at least the first one should be the exact match of the site we’re already on. And add a little color to show that it’s not just thrown at the top by accident.

Yes you might say it’s the user’s own fault and he needs to clean up duplicates. How can I delete multiple duplicates of account data? - #12 by jidanni
But that’s not the case I’m talking about.


Do all of those URL access the same (set of) services? For example, if you log in to, is this equivalent to logging in to

If you change the password for the jimmy@ account on, does this automatically change the password on all the sites (,,,,, etc.)?

Just like is for different things than and has different passwords, so no.

1 Like

OK, now I have a better idea of your situation. You are not using Bitwarden the way it is intended to be used. When you’ve browsed to a specific site and then access your vault to auto-fill, it should only display login accounts for that particular site. So in your example, when you go to, you should only see two vault items: the webmail login for jimmy@... and the webmail login for jimmy-test@.... Thus, there should be no need for sorting of the list, unless you have more than a dozen different test accounts for the same site.

It appears that setting the global default URI match detection option (the setting you were messing with in the screenshot in the OP) to Host is a more appropriate option for you. If the default setting mostly works as intended (i.e., narrows the list of vault items only to the set of login credentials that can be used on the current web page), but does not always produce the desired result (e.g., sometimes shows irrelevant vault items, or sometimes fails to show a relevant vault item), then you can (and should) customize the URI match detection option for the individual URI stored in the problematic vault items.

To customize the match detection method for a specific URI, open the corresponding vault item for editing, and click the gear icon (:gear:) shown to the right of the URI. This should bring up a drop-down menu, where you can change the option from Default (i.e., use the default match detection rule that was specified in the global settings) to something specific to use for that URI only (e.g., Base domain, Host, Starts with, Exact, Regex, or Never). If the vault item is being offered in the autofill list when it isn’t relevant, select a match detection method that is more restrictive than the method specified in the global default setting. If the vault item is not being offered in the autofill list when it should, select a match detection method that is more permissive than the global default method. In a few cases (e.g., if using the Starts with option), you may also need to edit the URI itself.

If you are having trouble getting this to work for a specific site, you can request help in the Ask the Community forum.


Yes, I know about the setting to restrict it to exact matches,
but I don’t want to do that. Yes I know that I can even do that

I love the default setting, even for just this * site group. I’m just saying
that it could be enhanced (or optionally enhanced via a setting),
so that it could show the exact matches first at top (marked slightly
differently too.)

Wouldn’t that be a great added value, instead of just throwing them all
at the user, merely alphabetically sorted?

Indeed, being the default option, less users would “not be using the app
as intended, thus getting frustrated” because in more cases they would
see what they were looking for, right at top.

Thus they needn’t research Settings right away to make the app do what
they want, as the defaults will be working fine for them in even more cases.

You are trying to take an existing function (listing all accounts that can be auto-filled on a given login form) and change it into something entirely different (listing all services available under a given web domain).

For your needs, I would suggest using other available methods to organize and view your vault content (e.g., the vault search function, folders, or favorites). The “Matching Items” list is strictly for listing different login accounts that are available to autofill on the current site, not for suggesting related services.

For most users, this works as intended when leaving the individual match detection option as Default on each saved URI, and leaving the global default match detection method as Base Domain. Adjustments to these standard settings are necessary only in special cases (e.g., if different subdomains are used for different services on the same base domain).

1 Like

Apparently what I need to do is go into each and every single one of these 12 matching items. And set them all to “exact” . Otherwise whichever I leave as default is still going to interfere when it comes time to match, meaning I still would have to need an extra step of selecting which which one I want.

Yes even if I only use one of them very often, and the others once in 5 years. Because the others still match, I can’t just get away with changing one. I sure wish they didn’t bury the way to change one of these so deep. It’s about as deep as you can get in the vault for each one of them. So many clicks needed.

Maybe I can do it by scripting the CLI.

Or you could set the Default match detection method to “Exact” (and leave the individual match detection options as “Default”).


A post was merged into an existing topic: URI matching preference order

This is a good idea. Most restaurants use the same app/rewards base domain (e.g.,,, etc.) but each account has its own subdomain / password combination. Account proliferation is also common at universities, where you might have a central university account, but additional ones within your department, research lab, or other miscellaneous university resources.

Then you have instances where you have the same credentials for,, and So if you set to match Host to avoid matching with, then you might need to add all of the subdomains,, etc. Not only this, but you probably also want to set to Host matching so it doesn’t match with, so you also need to worry about adding every possible other subdomain that shares credentials with, even though it’s probably a good default assumption.

I appreciate that Bitwarden gives you a number of ways to handle this, but a default sorting based on the number of matched subdomains when base domain is selected would be great for most users compared to adding every possible subdomain or some abstruse regex command.

@Tahlor Welcome to the forum!

You deal with this by changing the URI match detection setting to something other than the default “Based Domain” setting.

Same. You can set the URI match detection to “Host”, Starts With", or “Exact” so that each set of login credentials is matched only to the relevant web page and not to other websites in the university’s web domain.

Is this a real example? I find it implausible. Most universities use SSO these days, so there would be a single set of credentials common to all password-protected services on the university domain. But no matter how many different sets of login credentials you have on a specific domain, you can set up URI match detection to deal with it.

If the example above is real, then I would suggest using “Exact” as your default URI Match Detection (which you can set in Settings > Auto-fill). If you come upon a web page that doesn’t get matched by the extension, but that has the same login credentials as one of the login items stored in your vault, then use the Search function to bring up the stored credentials, and use the “Auto-fill and Save” button; next time that you visit this web page, it will match.

Is this a real example?

No, I just like to troll devs by posting obscure counterfactuals I’ve never experienced. :upside_down_face:

Corporations have SSOs. Universities do for some core services, but not for clubs, labs, or dozens of other miscellaneous organizations with ad hoc websites run by students, nor necessarily for different departments, or e.g., high-performance compute resources that have different security requirements (mine has SSO and all of the above still apply to me).

The point is not that BitWarden can’t handle these scenarios with sufficient configuration (e.g., why offer anything besides regex), but I suspect many users do not find URL matching particularly accessible. But more to the point, there seems to be very little downside with having the matches be sorted even slightly intelligently. Is the reason not to do this primarily because it is too much work to implement or because it is somehow counter to BitWarden’s intended functionality? In principle, it seems like it could be layered onto BitWarden’s existing domain matching fairly simply.

I can’t speak for the devs, but as I already explained earlier in the thread, sorting matches based on the URI would run counter to the intended functionality. The list of matches is supposed to represent every set of credentials that can be used to log in on the active web page. If your list of matching items also includes irrelevant login credentials that cannot be used for logging in on the active web site, then your URI Match Detection settings are incorrectly configured.

For the vast majority of users, the default URI Match Detection method (“Base Domain”) works fine. For users such as yourself, setting the default URI Match Detection method to “Exact” will solve 90% of your problems. The remaining 10% are fixable with a little bit of customization, and if you work in the Computer Science department at, then it should not be difficult.

Not even sure I understand what you are proposing. If you want to further promote some proposed implementation of this feature request, please provide a more detailed description of what you are suggesting.

This is a deal breaker for me. I can’t understand why this kind of feature gets so much pushback and hate. I’ve seen it proposed multiple times and always there are excuses and cop-outs to not implement it.

Some websites offer different services on different subdomains, and you need different credentials for them. Some sites even offer different login forms on different URIs on the same domain.

For example: may be a personal blog or ecommerce shop or something, and users can log in. myblogexample[dot]com/admin could be some sort of admin panel with a different set of credentials. myblogexample[dot]com/phpmyadmin could be an instance of phpmyadmin where one can log into the database (insecure, I know, but these do exist and are fairly common). cpanel.myblogexample[dot]com could be where the owner can log into a cPanel instance to manage the hosting parameters for the site. dev.myblogexample[dot]com could be a testing instance of the site where developers implement and validate new features before enabling them on the live site. All these login pages have different sets of credentials. If I happen to be a developer working on the site, I’ll have accounts on all of them. This is actually a real scenario that I have to deal every day. I have around 10-20 credentials for each site I work on, but only 2-3 of them are relevant on each page of the site. I would like Bitwarden to be smart enough to recommend the right accounts for the right page.

I know you can tweak the URI and the match detection on an individual basis, but come on, who does that? Especially when, in fact, I do not need custom matching rules. I need THE SAME RULE FOR ALL MY LOGINS, just a smarter one. I just want to click Save on the prompt and have the password manager figure out what to do with my credentials.

This is how the matching should work: If I have credentials that match the exact URI, then obviously I want those suggested first. If I have credentials that start with the same subdomain, just happen to have something different at the end, those should come after the exact matches. If I have credentials that match the same subdomain, I want those suggested immediately after. If I have credentials matching only the base domain, those should come last. If there are multiple credentials matching the same level of priority, they should be sorted by history, the ones I used last time should be first.

This would be the ideal URI matching. In fact, this is what google already does with their password manager, and it works great. It always recommends exactly the credentials I need. Too bad it lacks all the other features… But it can’t be that hard to implement something like this…

I’ve kept trying Bitwarden over the years, and I always go back to just saving passwords on google or having them both at the same time, for this one reason alone. Google is so much more convenient in regards to recommending the proper credentials for each page. And it’s frustrating because this is not some kind of super-smart or complex algorithm that only Google could figure out. They just prioritize the URIs in a way that makes sense.

EDIT: Why can’t I use exact matching? Because I want just one global matching rule for everything. I do not want to configure matching rules on an individual or group/folder basis. If I switch to exact matching with all my logins, then services that have the same credentials on multiple domains will no longer work. I think google does this. And there are many other sites that sometimes ask you to login on app.domain[dot]com and account.domain[dot]com and so on.


In which case, scroll all the way to the top of the topic and in the top-left corner, click “vote”. ATM, this has zero votes, so it appears to be a priority for nobody.