Autofill matching

This page is for the decision an org admin actually has to make: configuring an equivalent-domain group changes when a credential is offered across two domains. It does not change when the extension fills one in without you clicking anything. Those are separate questions, and the second one is deliberately narrow.

When a fill needs a click, and when it doesn’t

Every fill the extension performs starts from an explicit gesture — clicking the inline key over a field, choosing a login from the popup, the fill keyboard shortcut, or the context-menu item. That covers the large majority of fills, including ones that cross a subdomain or an equivalent-domain group (see below).

There is exactly one exception: fill on page load, an opt-in setting (“Fill on page load” in the extension’s settings, off by default) that fills a password field automatically when the page loads, with no click. Because that path acts with no signal from the user that this page and this credential belong together, it is held to a stricter rule than every other fill: it only fires when the page’s host is exactly the host the credential was saved on. A credential saved on app.example.com will not fill on load on example.com, on other.example.com, or on a domain in the same equivalent-domain group — even though all three are legitimate one-click matches. It will still appear as an offer; it just will not type itself in.

What an equivalent-domain group does

An org admin can declare two or more domains as an equivalent-domain group (for example, amazon.com and amazon.co.uk) when the same organization genuinely operates logins across domains that don’t share a registrable name. Membership in a group means a credential saved on one domain in the group is offered — as a one-click match — on every other domain in the group.

What it does not do: it does not enable fill on page load across the group. A group is a statement that two domains belong to the same organization, not a licence for either domain’s markup to have a credential typed into it before anyone has looked at the page. If you configure a group expecting a silent cross-domain fill, that is deliberate — it is out of scope for what the group controls, not a bug in the group.

A domain can belong to only one group, and a group member must be a bare registrable domain — not a subdomain, a URL, or a pattern. Subdomains are handled separately, and automatically (next section), so they are not something you add to a group.

How subdomains are treated

Subdomain reach is baseline behavior, not something you configure. A credential captured on login.example.com is, by default, a one-click match on example.com, on other.example.com, and on any other subdomain of example.com — the extension matches by registrable domain (the example.com in all of those), not by exact host. This is why login.example.com isn’t a valid equivalent-domain-group member: the matcher already reaches every subdomain under example.com without one.

The same boundary that stops fill-on-load also bounds this: a lookalike domain like example.com.evil.test registers as evil.test, not example.com, so it is never a subdomain match for an example.com credential, in or out of a group.

Why fill on page load doesn’t follow the wider match

A page can be made to look like it belongs to a domain it doesn’t — injected content on any subdomain, or a domain sharing a group with the one a credential was saved on. Offering a credential on that basis is safe: a person still has to recognize the page and choose to fill it. Filling it automatically is not — it hands a credential to whatever is on the page the moment it loads, with nobody having confirmed the page is the one they meant. Keeping fill-on-load to an exact host match, while leaving every one-click path as wide as subdomains and equivalent-domain groups reach, is what keeps that gap closed without narrowing what a deliberate fill can reach.

Where to go next

• Browser extension overview — what the extension does and where secrets live.
• Settings and security dashboard — where “Fill on page load” and other extension settings live.
• Teams and organizations — org-level administration in general.