I deleted the saved login for this site, cleared the form fields, and saved the correct username again, but autofill still inserts an older account. I have 7 saved entries across related subdomains, and the wrong one appears even after I manually select the right login once.
What should I check to make autofill consistently choose the correct login without deleting the accounts I still use on the other subdomains?
Open each saved entry and check its URI matching rule. If it is set to “base domain,” every related subdomain may be treated as the same site. Change the entries to “host” or “exact” matching so each login only appears where intended. Manually choosing the correct account once usually does not teach autofill a permanent preference.
If you use Bitwarden, its free password manager supports per-entry URI matching. Keep all seven accounts, but give each one the specific subdomain it belongs to. Remove any extra broad URI such as example.com from an entry unless that login genuinely works everywhere.
Check whether the browser’s built-in password manager is active at the same time, too. Two autofill systems can overlap, making an old browser-saved login appear even after you fixed the vault entry. Disable autofill in one of them, then lock and unlock the vault or restart the browser before testing again.
Deleting the saved password may not remove a username stored separately in the browser’s form history. Clear saved form/autofill data for that site, then test in a private window to see whether the old account is coming from cached browser data.
Be careful deleting all seven entries, since the subdomains may need separate credentials. In Bitwarden, check the wrong item’s URI matching setting and change it from the broad base domain to an exact host match so it stops appearing on related subdomains.
If the old username still appears with every password manager disabled, autofill is not the culprit. The site may be restoring a remembered account from a cookie, local storage, or its own account chooser.
Sign out fully, remove the old account from any “choose an account” screen, then clear site data for that specific subdomain. That is different from clearing form history, as @logictiger2445 suggested. Form history belongs to the browser. Site data belongs to the website and can put the username back before the password extension even runs.
After clearing it, close every tab for that site and reopen the browser. Test with all autofill tools disabled. If the fields stay empty, enable only your preferred password manager and try again. If the old login immediately returns, then the URI matching advice above is the right path.
A less elegant workaround is to disable automatic filling for those seven entries and select the correct account manually. Slightly annoying, but still less annoying than logging into the wrong subdomain repeatedly.
Nobody’s asked whether your vault or browser profile syncs across more than one device. If it does, that matters a lot. You can delete the wrong entry on your laptop, fix everything, close the browser, and then your phone or a second machine quietly pushes the old copy back the next time sync runs. Same thing with browser account sync restoring saved passwords. So before you go deep on URI matching, confirm you’re not fighting a copy that lives somewhere else.
The URI matching advice up top is solid and it’s probably your real fix if seven entries all sit under one base domain. No argument there. But @m3g4_root’s point is the one I’d test first, because it’s faster to rule out. Sign out of the site fully, clear that subdomain’s site data, and reopen. If the username is gone with everything disabled, the extension was never the problem. Bitwarden matching only decides which of your saved logins gets offered, it can’t stop the site itself from remembering an account through its own storage.
Honest expectation: you may find it’s two problems stacked, a broad base-domain match plus the site’s own account chooser. Fixing one and assuming you’re done is how this drags on. I’d tighten the matching to host or exact, clear the site data, then check sync last so nothing you deleted comes back.
Make sure you’re editing the same vault copy that is doing the filling.
This confused me at first because I assumed changing an item in the web vault meant the browser extension saw the change immediately. The extension can still be working from its locally cached data. Open the extension itself, run a manual sync, lock it, then unlock it again. After that, search for the old username inside the extension rather than checking only the web vault.
If the old account still shows up there, look for duplicates outside your personal entries. It might be in a shared collection or under another folder with a slightly different name. Searching by the username is more reliable than searching by the site, especially when several subdomains and broad URI rules are involved. A duplicate can look unrelated until you open it and notice that it contains the base domain.
@greengeekpoint is right about sync restoring an item from another device, but I would first check the simpler local version of that problem. Confirm which Bitwarden account the extension is signed into and which browser profile you are using. It is easy to edit the vault in one profile while another profile’s extension is the thing filling the page.
Once you know the extension contains only the current entries, then test the host matching and site-data suggestions already mentioned. Otherwise, you can spend time fixing URI rules on the correct item while an old duplicate in the extension keeps winning the autofill match.
Don’t change all seven entries to exact matching in one sweep. That can create the opposite problem if those subdomains send you to a shared login page such as login.example.com. Password managers match the URL where the fields actually appear, not necessarily the app URL you started from.
Watch the address bar during a login attempt. If app.example.com redirects to a central authentication host, several accounts may correctly match that same page. In that setup, host matching cannot know which app you intend to enter after signing in. Exact matching may simply hide credentials you still need.
I’d turn off automatic filling on page load for the entries that share the authentication page, while leaving them available in the extension’s account picker. Give each item a clear name such as “Billing app,” “Admin portal,” or “Support account,” rather than relying on similar usernames to tell them apart. That is less automatic, but much safer than having the wrong account submitted before you notice.
The URI and sync checks already mentioned are still worth doing. Just verify the redirect path first, because if all seven logins end up on one central sign-in host, the behavior may be ambiguous rather than broken.
Deleting the password entry may not delete the credential that is actually being offered. Check whether the old account has a saved passkey in your browser or operating system, especially if the account chooser appears before the password manager fills anything.
Remove or disable that old passkey, close the login tab, then retry with autofill turned off. If the username no longer appears, you can leave the seven password entries alone and re-enable your preferred autofill tool.