A little setup.
Every detail, covered.

01 / THE SETUP FLOWILLUSTRATION

CSV

Bring your CSVSynthetic test accounts

→

QA workspaceAMJC

Review your groupVerify, then confirm import

→

◎qa.example.comUsername + password

Set up the loginMatch fields, save & authorize

Choose a group at the top of Settings. Each group keeps its own accounts, authorized domains, login profile, and history. The popup’s group picker chooses which catalog you search and fill from.

Import CSV

1. Name your group or choose Create new group.
2. Select a UTF-8 CSV with account_id, username, and password headers. Extra columns become searchable metadata. Use the built-in three-row sample as a starting point.
3. Enter your authorized domains. Choose Merge & Update to preserve omitted accounts, or Wipe & Replace to replace the selected group.
4. Verify the file, review valid/invalid counts, then confirm. Invalid rows are excluded; Replace may therefore remove existing accounts corresponding to those rows.

Indexed accounts

Search the imported catalog, copy individual account details, delete an account, or export the entire selected group. Export includes synthetic passwords even when the account list is filtered. Individual deletion offers a 30-second Undo; group purge requires confirmation and cannot be undone.

Login page setup

Name the profile, configure its login domains, select how to match the two inputs, and decide whether to track successful login. Finish with Save & authorize website. Unsaved detection choices and common selectors are only a draft.

Import limits: 2 MiB per file, 10,000 rows, and 100 columns. IDs are case-sensitive and must be unique within a group. Duplicate IDs in the same CSV are rejected.

02 / ANATOMY OF AN ORIGINILLUSTRATION

https://SCHEME

qa.example.comHOSTNAME

:8443PORT

/loginPATH

These three must match exactly Path does not limit authorization

✓ Same originhttps://qa.example.com:8443/dashboard

↗ Different originhttps://qa.example.com:9443/login

Use a full https:// or http:// URL. Both schemes are accepted on regular hosts and local development hosts. Prefer HTTPS: HTTP does not encrypt traffic to the target site. Use synthetic accounts only.

What exactly matches?

The scheme, hostname, and port must match. HTTP and HTTPS are separate. Subdomains are separate. localhost:3000 and localhost:4000 are separate. Paths, query parameters, and fragments do not restrict autofill authorization: adding /login does not limit access to only that page.

One group, several environments

Enter up to 20 distinct domains separated by commas or whitespace. A login profile may cover domains already authorized for that group, using the same field rules. Use separate groups when different sites need different rules. URLs containing embedded usernames or passwords are not accepted.

After changing a group’s domains, save and authorize its login profile again. Existing accounts can stay in the group; you do not need to reimport the CSV just to update the domains.

03 / FROM FORM TO MATCHING RULEILLUSTRATION

qa.example.com/login

Welcome backUsername 01

Empty input

Password 02

Empty input

→

DETECTED ATTRIBUTES

01

Username fieldMatch by input IDemail

02

Password fieldMatch by autocompletecurrent-password

Review → Save & authorize

1. Open the actual sign-in form in another browser tab. Leave the username and password inputs visible.
2. In Settings → Login page setup, check that the login domain belongs to your selected group.
3. Choose Detect fields from the login page. Review the site-access explanation and approve Chrome’s request if permission is missing.
4. Choose a tab from the list of up to three recently used tabs on the group’s authorized domains. Check the URL and path to distinguish similar tabs.
5. Select the detected username and password candidates. The extension suggests a matching method from attributes such as ID, name, or autocomplete.
6. Review the choices and click Save & authorize website. Detection does not save the profile or fill an account by itself.

What can detection see?

It inspects visible, writable text, email, and password inputs in the top-level page, including open shadow roots used by web components. It returns identifying attributes and labels, never input values. Embedded frames and closed shadow roots cannot be inspected.

If no fields appear

Confirm you picked the right tab and the form is already on screen. Open the login step before detecting again. A page may keep its form in an embedded frame; the extension can name visible frame hosts to explain that limitation, but it cannot fill inside those frames.

Choose a method independently for username and password. Each must resolve to exactly one visible, writable input of the appropriate type. Ambiguous matches stop the fill instead of guessing.

Input ID or name

Enter the exact attribute value, such as email. With ID matching, omit the CSS # prefix. These matches are case-sensitive.

Autocomplete

Use a token such as username or current-password.

Label, placeholder, or aria-label

Enter the field’s text. Matching ignores case and extra whitespace. Label matching also considers visible text referenced by aria-labelledby.

CSS selector

Use a selector such as input[name="email"] or input[type="password"]. Comma-separated alternatives are allowed, but their combined result must identify exactly one input.

Use common selectors restores broad starting rules. Review them on your site before saving; multiple matching fields require a more specific rule. Re-detect fields if a website redesign changes its form.

Filling fields and signing in are different events. Recent records a successful fill. Last successful changes only when your configured success condition is observed within two minutes.

Do not track successful logins

Use autofill without a success condition. No success URL is required.

URL changes to success page

Set the exact post-login URL. Its route must differ from the login URL. Matching checks origin, path, and fragment; query parameters are ignored.

A success element becomes visible

Set the observation URL and a CSS selector for an element that appears after login, such as a signed-in account menu.

Configure a success URL on the same origin as the first login domain in your profile. When one profile covers multiple environments, verify tracking on the configured success origin rather than assuming it applies to every environment.

You still submit the website’s form manually. Failed login leaves the previous successful account unchanged. Editing the filled fields cancels attribution, and an already-satisfied success condition is not counted as a new success.

What stays on this computer?

Imported accounts, settings, and history use extension-local storage. There is no application server, cloud sync, or telemetry. The extension’s own features and assets do not need an internet connection. A remote login page and its authentication service still need to be reachable.

Is this password-protected storage?

No. The local snapshot uses encryption, but its key is stored alongside it so the catalog can open automatically. There is no master password or lock prompt. Use synthetic accounts only. Original and exported CSV files remain ordinary files on your disk.

“No open tab” or no permission

Open the authorized origin in another tab, including the correct scheme and port. Check Chrome’s Site access settings, then run detection or save and authorize the profile again.

Autofill is blocked

Choose the correct group, check the page against the profile’s domains, and re-save the profile after a domain change. Make the username and password rules unique. Embedded-frame logins, closed shadow roots, SSO handoffs, and multi-step flows are outside this version’s scope.

Backup and reset

Export the selected group before a destructive operation if you need to retain its accounts. Exported CSV files include synthetic passwords. Purge removes a group’s accounts while preserving its setup; Reset also removes its profile and session state. Neither is a substitute for a backup.