How does Suggestions Work?

When I open 1Password from the browser plugin, how does 1Password determine which secret entry to show in "Suggestions" based on the URL in the browser? I'm trying to limit the number of duplicates in my database by putting the URLs of each internal company website in my "Domain Credentials" secret, but other secrets with unrelated URLs keep showing up in "Suggestions".

I remember in older versions of 1Password there was a configuration option for something like "strict URL matching in Suggestions" but I can't find anything similar now.

Basically, I'd like info on how to customize the Suggestions experience when using the browser plugin. Help?

1Password Version: 7.3.1
Extension Version:
OS Version: 10.14.6
Sync Type: 1Password Cloud
Referrer: forum-search:how do suggestions work



  • ag_anaag_ana

    Team Member

    Hi @bigfriggin!

    The main thing that 1Password looks at is the website fields in your 1Password items to know what to suggest to you. If you store the URLs for your entries in a different field ("Domain Credentials" in your case, if I understood correctly), 1Password will not be able to suggest the correct items for the website you are in, and will default to showing you even unrelated items.

  • bigfrigginbigfriggin Junior Member

    That was my understanding too. However, let's say I have one secret with exact website entries and another with similar websites, but far from the exact site I'm looking at in my browser. It will still show me both under "Suggestions" when using the browser. Can you fill me in on the minutia of the rules behind what "Suggestions" shows me so I can better use 1Password?

  • brentybrenty

    Team Member
    edited July 2019

    @bigfriggin: While we're not going to be able to share the code that does the rest as far as intelligently suggesting (non-Login) item based on the actual webpage, it's actually pretty simple, as far as website URLs: 1Password suggests Login matches for the current domain.tld; it will not show Logins which are for a different one. Otherwise a malicious website could trick you into filling credentials for another: your Login will not be offered for filling at, as an example. I hope this helps! :)

  • bigfrigginbigfriggin Junior Member

    Thanks @brenty I wasn't specifically asking about code, but thanks for the vote of confidence!

    I was hoping for info on more granular control -- currently it seems like 1Password is suggesting items based on more than just the domain.tld. Here are 2 screenshots that show what I mean. Descriptions follow each:

    In the above screenshot, taken from this very page, we see that the domain.tld in the browser is The 1Password plugin is showing an item intended only for Plus, there are all these non-login items like identities and credit cards, when none of these field of fields appear on the page.

    In this screenshot, we see that that *.domain.tld is yet a bunch of items are being suggested. I'd be expecting that the only suggestions to show up here would be the ones with green arrows. These are the only items in my Vault that actually have in the website field of the 1Password record. All the others show different subdomains on our main domain.tld, (which may be ignored by design since you specifically said domain.tld not *.domain.tld, above) but some of my items' website entries _only_ have IP addresses.

    Didn't there used to be a "strict" option for suggestions? I've got over 2k login items in this Vault and I really need to be able to enforce an exact suggestion match on *.domain.tld, not just domain.tld, and right now I can’t do that. Plus I'm confused about including the suggestions that only have IP-address based URLs.

    Any suggestions?

  • BenBen AWS Team

    Team Member

    Hi @bigfriggin

    The item you've highlighted does have in a website field on it... it is in website 5. It is nearly cut off in the screenshot, but that's why it is being suggested. Any Login items that have website fields where the "root" domain matches will be suggested, but ones more closely matching should be given higher priority. If you had one login item with a website field containing in this case that should be listed as the first match.

    I really need to be able to enforce an exact suggestion match on *.domain.tld, not just domain.tld

    That isn't something that we currently offer, but I'll suggest to the team that we investigate how to improve this type of situation going forward. It would be great if we could account for this without hurting folks who need it to work the way it currently does. For example, I have an account on the domain. Those credentials work on all sorts of hosts on that domain (e.g.,,, etc). I wouldn't want to have to save (and thus update) those credentials for every host, when one Login should cover it. Essentially just as many if not more systems are setup just the opposite of what you're asking for.

    Plus, there are all these non-login items like identities and credit cards, when none of these field of fields appear on the page.

    Correct; identities and credit cards are always suggested on every page, but they should be at the bottom of the list.


  • bigfrigginbigfriggin Junior Member

    The item you've highlighted does have in a website field on it...

    Hi @Ben you're right - I did see that one of the entries had in it way down the list there, so I now get why that one showed up. But why did it show up above the entries that actually had the exact match of in them? Is it because it's marked as a favorite in 1P?

    What about the first screenshot with vs.

    It would be great if we could account for this without hurting folks who need it to work the way it currently does.

    With regards to the subdomain matching, I too have AD and RADIUS logins that work across hosts on the root domain, i.e.,, etc. but I also have some in legitimately different subdomains like where the part signifies a logical hierarchical split from the root domain.

    I know some organizations like to "abuse" hierarchical DNS to make things easier to understand (i.e. vs. vs. but for organizations like mine that have historically sync'd-up our naming conventions hierarchically with our policy scope & security boundaries, the current way 1P does matching is too inclusive.

    Essentially, if the Suggestions mapping had an option to pull only items based on the full hierarchical domain name host.[subdomain.domain.tld] instead of just host.[domain.tld] and host.subdomain.[domain.tld], many existing use-cases would be well-served.

  • bigfrigginbigfriggin Junior Member
    edited July 2019

    Thanks for the info @Ben I do see that the one is in there now. My bad.

    With regards to your example with - you're absolutely right, and should have the same login credentials because is the root domain. Showing these 1P logins in Suggestions at the same time makes perfect sense.

    But my organization aligns our policy & security boundaries with our naming conventions according to DNS's long-standing hierarchical formats. For me, and are two very different hosts (both named HOST1) in two different domains ( vs.

    @brenty above gave the vs. example for why the suggestion matching is done - it would be quite undesirable and dangerous from a security perspective to suggest a login item for an unrelated URL. We unequivocally agree on this point.

    I'm arguing that for me and any other "old timers" that follow strict DNS naming & usage conventions, showing logins for both and side-by-side in Suggestions is just as bad as showing and at the same time.

    It would be a really bad thing if I accidentally sent my credentials to a server in the management domain, and vice versa.

    Does that help with my ask?

  • bigfrigginbigfriggin Junior Member
    edited July 2019

    And to be clear, I do understand both use cases, which is why I was hoping there was a toggle I could hit.

    I get that modern naming conventions have moved towards DNS-as-description (i.e. vs. vs., but there are still a lot of shops out there properly following RFCs and defining their security & policy boundaries around DNS's original hierarchical namespace.

  • brentybrenty

    Team Member

    @bigfriggin: While Ben's example was a good one representative of what most users need (albeit not a domain I am familiar with -- versus would be a common example of where nearly everyone would expect the same Login to work on both), trust me: we also understand where you're coming from. We've got dozen of and Logins ourselves and know that can get confusing sometimes. ;) We do, however, need to advocate for what will benefit the greatest number of 1Password users, even when it may conflict with our own personal use cases at times. I don't know what the solution is, but it's definitely not a toggle. We had one for a related feature years ago and it hurt a lot more than it helped, so we removed it. But we'll see if there's something else we can do in the future that might do more good than harm. Question: In your case, might it work for you to be able to designate a specific domain be treated more strictly? I can't promise we'll add a feature like that, but maybe it's worth considering. :)

  • bigfrigginbigfriggin Junior Member

    @brenty I remember that feature change between 1Pv3 and 1Pv4, in fact it was the driver behind my first post here! I’m not claiming to know the perfect answer here. I just know that I’m either (a) finding myself needing to be very careful when choosing from suggestions or (b) spending time finding the appropriate suggestion that’s buried in the list.

    Both have the terrible effect of taking me out of my flow. I can’t ⌘\ nearly as much as I’d like to!

    My personal vote would be a per-item toggle that says something like “don’t include this login in Suggestions unless perfect FQDN match”. Maybe not even make the option visible without a master toggle in Advanced settings, I dunno.

  • bigfrigginbigfriggin Junior Member

    And yes, being able to treat a specific domain more strictly would also be very useful!

  • littlebobbytableslittlebobbytables 1Password Alumni

    Hello @bigfriggin,

    Let's say I have two Login items for Amazon. The Amazon sign-in page is on and one Login item correctly references while the other only mentions If I access 1Password mini both will appear as they're both matches for the registered domain If though I use the keyboard shortcut ⌘\ it will always pick the Login item as there is only one exact match.

    Although I haven't done any large scale tests, if you like to use ⌥⌘\ to access 1Password mini (keyboard equivalent to clicking the toolbar button) then the following is what I believe holds true.

    1. Any matches to at least the registered domain and our flagged as favourites. If more than one these will be ordered alphabetically.
    2. Exact matches to the FQDN and are not flagged as favourites. If more than one these will be ordered alphabetically.
    3. Matches to the registered domain and are not flagged as favourites. If more than one these will be ordered alphabetically.

    So potentially three groups depending on the numbers and each group will always appear in that order. If you're seeing something else please say but my current understanding is this is the expected behaviour.

    The trouble with adding extra options either at the global or individual item level is each new option increases the complexity of 1Password and we're painfully aware it already has a steep learning curve. We removed the option you're thinking of in 1Password 6 because all it did was cause confusion and I can't think I've ever interacted with a person that used it to good effect. Even if we claim something is an advanced option we have to weigh up the benefits from the support if it is misunderstood and misused. It's a delicate tightrope that if we get it wrong can make 1Password more difficult for a lot of people but with little gain. None of that helps but I hope you can understand why we sometimes need to be quite careful when adding new configurable settings.

  • bigfrigginbigfriggin Junior Member

    Thanks @littlebobbytables @brenty @Ben and @ag_ana , I appreciate your candor on this. In the meantime I’ve decided to segment the entries I’m worried about into a different Vault that I only activate when necessary. That, and cleaning up the multiple duplicates I have accumulated in the least 10 years.

    One last question: referring back to my very first screenshot in this thread, what's the expected logic around the website being but the 1Password login item having as the only websites item?

  • littlebobbytableslittlebobbytables 1Password Alumni

    Hi @bigfriggin,

    For some very specific cases we have what we call domain equivalency. If you have a Login item saved for you would like it to appear when you're on because that's another well known domain that Apple owns and uses. With the exception of Japan (I have no idea why I'm afraid) an Amazon account created on any of their domains works perfectly everywhere else. There are a few more but it isn't a large list at all. We have an entry on this list for ourselves as we own both of those domains. Now is before my time so I'm unsure what details there would make sense to associate with but I assume there must be a reason for its inclusion.

    So the match is intentional even though I cannot provide a clear explanation as to what credentials would be transferable between the two. Sorry I don't have anything more specific for that particular case although I hope the why puts you at some ease.

  • brentybrenty

    Team Member

    In 2011 I believe it was that we changed the company name from "Agile Web Solutions" to "AgileBits". Since we own these domains and moved to the newer one, accounts that referenced the old were migrated to the new one. So that's an "equivalent domain" in the most literal sense. Apple is a better example I think because it's one most people are aware of, using the same Apple ID login credentials for iCloud as well. And yeah, unlike those, I had to create a separate account. :lol:

  • It would be great if the best matching URL were sorted to the top. Right now I have separate credentials for and, and have these exact urls listed in the website field for the 1password entry. However the suggestions don't seem to show me the closest matching URL first.

    I understand the need to handle equivalent subdomains and the such, so I know it is going to show me more suggestions than I would like, but it would be great if they could at least be sorted better.

    And yes, I like the idea of marking certain domains as more strict. Not sure if that potential feature could also be applied to my example where it isn't exactly a subdomain.

  • bigfrigginbigfriggin Junior Member

    I’m still convinced that the philosophy behind the Suggestions feature is fundamentally broken. It encourages confusion for anything other than the standard host.domain.tld format. Even breaking things out into a different Vault doesn’t help as much as it should. Having to switch vaults takes me out of my flow and I continue to accidentally send the wrong credentials to the wrong servers.

    There needs to be an advanced toggle for strictness for this to work in a manner that is easy enough for casual users but powerful enough for advanced users, arguably the group that needs 1Password the most. Saying that it needs to work the same way across the board is a cop-out and is a disservice to all users.

    Have there been any discussions on this since July? @brenty @littlebobbytables @Ben @ag_ana

  • bigfrigginbigfriggin Junior Member
    edited January 2020

    I mean there’s already an advanced tab for JSON and such, how is that confusion OK but not here?

  • lando__lando__
    edited February 2020

    I have to jump on your bandwagon. The inability to isolate FQDN from basename is at best an annoyance, and at worst a basic feature whose absence is enough to warrant switching platforms entirely.

    At this point I would gladly use some interpreter or ruleset (PCRE?) nested deep in some advanced menu that would allow for this. As it stands, the advanced features specified in the Preferences leave a lot to be desired.

    @1Password, I truly mean this in the most positive way, if you intend to market this as an enterprise solution, FQDN segregation is a critical component. I can't tell you how many companies follow the URL scheme to access different resources. I'm quite surprised the demand has not yet reached a point where this implementation is not being seriously considered.

  • bigfrigginbigfriggin Junior Member

    @brenty @littlebobbytables @Ben @ag_ana if this isn’t the forum to make a serious push for this functionality, please let me know where I can start to drum up support.

  • ag_anaag_ana

    Team Member


    This forum is the right place :+1: Thank you for the feedback once again! We will certainly keep it in mind as we continue making 1Password even better.

  • I was searching for a solution to this and stumbled on this thread so let me add a massive "oh god yes" to the request that @bigfriggin is making.

    I have a bunch of devices on a network DMZ in a data center. All of them are which means that the suggestions are horrible for me when I'm trying to log on. As I have multiple logins for a lot of the machines (admin and general user), I have to pay very careful attention to whichever entry I've selected. Even worse, some of the machines are docker engines and have a ton of services, each with their own auth info.

    The ability to define some explicit FQDN base names to 1Password (i.e. "") that should never be fuzzy matched would be a great addition. That way, I can add my DMZ info for 1Password get the explicit match I need.

    By the way, whilst we're on the topic, the ability to specify that the tcp port should be in the match as well would be excellent. I accept that this is very much a "Pro" user request but the ability to be able to specify per-FQDN domain options ("Default, Match On Exact FQDN, Match on Exact FQDN + Port") would be amazing.


  • I'm a relatively new 1Password customer, and I'm casting another vote for the ability to segregate explicit FQDN in the suggestions. At my large institution, many of our web services are SSO, so I can use my domain credentials. But other services are unavailable to the general school population, so do not utilize SSO, and have their own discrete logins. I don't want 1Password yelling at me for re-using credentials, so I've generated unique, strong passwords for those stand-alone systems.... and then get over a dozen suggestions from the 1Password autofill, simply because the URL is I would love to see the ability to define explicit URL/FQDN matching in 1Password!

  • ag_anaag_ana

    Team Member

    Thank you to both of you for taking the time to join the discussion :+1::)

  • The original question above was "how are suggestions made" and then a discussion of various improvements. I'd still like to read something that describes how suggestions are made and in what order and how the key/value pairs are used to populate a login form. I'm often confused by the suggestions made and by the values inserted by 1password. Some of that is probably pilot error (i.e. me), so I'd like to fix that first before suggesting more fixes like the one's above.

    Then again I can't resist. In addition to @smackie's excellent suggestion to define a match, it would also be useful for the suggester to indicate how it matched, e.g. "Matched FQDN" and so forth.

  • How did the forum software figure out exactly what I look like? Spooky...

  • Then again I can't resist. In addition to @smackie's excellent suggestion to define a match, it would also be useful for the suggester to indicate how it matched, e.g. "Matched FQDN" and so forth.

    To expand on @mcarifio's point, some indication of matching (for an FQDN with optional matching rules) would be useful.

    And, altho I didn't really expand on it in the original suggestion but it would be helpful to see the explicit TCP port as a peer of the match too. For example, the two service URLs

    match to wildly different things and there's no point offering one as a suggestion to the other (if the domain is flagged for extra careful matching). I'm always careful to have the proper URL in the login entry for these sort of machines to make sure that things don't get confused.

    And the following

    are all different endpoints and shouldn't fuzzy match against each other. In these cases, it'd be helpful to have a setting like = Match on exact FQDN + Port

    as a setting. In that case, you'd have to match the URL locator completely to get a suggestion. For other environments, this would work = Match on exact FQDN

    and would match the exact machine name but ignore the port. It would be helpful here to sort the matches so that if there is a port match, it shows up at the top.

    Finally, the default is what we have right now = Match on Domain (Default)

    Right - that's about as exhaustive as I can make this.


  • It's probably related to this topic: I cannot search other website fields.

    I have multiple subdomains like, etc. When I search subdomain1 and press enter, 1Password will "open and fill". But It can't find subdomain2. So I can't "open and fill" other websites easily other than the first one.

  • It's probably related to this topic: I cannot search other website fields.

    I have multiple subdomains like, etc. When I search subdomain1 and press enter, 1Password will "open and fill". But It can't find subdomain2. So I can't "open and fill" other websites easily other than the first one.

  • @smackie I can only second that and I deeply wish that this feature gets included soon as I am in the same situation as you.
    Matching suggestions only with domain.tld while you have a passcard with the exact FQDN or even URL (with or without port) is ineffective.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file