How to Automatically Log In to Websites with 1Password and Browser Automation

There are two different ways to use 1Password with website sign-in. For everyday browsing, use the 1Password browser extension to choose a saved Login item and fill the matching site. For repeatable, authorized browser tests, authenticate during Playwright setup and save browser storage state for later test contexts. The documented workflows do not establish a supported direct connection that lets Playwright retrieve 1Password Login-item secrets or operate an unlocked extension unattended.

Use the extension when a person is signing in. Use Playwright storage state when tests need to reuse an authenticated session. In either case, verify the site and account are appropriate, and treat credentials and saved session state as secrets.

1. Sign in interactively with the 1Password browser extension

1Password’s browser extension matches saved Login items to website addresses. A user selects the sign-in prompt or uses Open & Fill; the extension fills the chosen Login. The extension can submit the filled form automatically by default, and its settings let you turn that behavior off. A user action is still required to Autofill.

1. Install the 1Password extension for your supported browser and sign in to the extension.
2. Open the site’s sign-in page and check the address bar. Confirm the domain is the site you intended to visit.
3. Select the 1Password sign-in prompt and choose the correct Login item. If the prompt is not shown, open the extension and choose the matching item, or use Open & Fill to open its saved website and fill the Login.
4. Review the result. If the site has a multi-step sign-in, complete any remaining step yourself. Confirm that the expected account page opens.

Check the saved website address

A Login item needs the correct website address to match the intended sign-in page. If the item does not appear, edit the item in 1Password and check its website field. Avoid broad or unrelated addresses that could make a credential match a deceptive page. URL matching is a security control as well as a convenience.

Choose whether the extension submits the form

Automatic form submission is configurable in the extension’s Autofill & save settings. Leave it enabled if it works predictably for the site and you want the shorter flow. Disable it if you want to inspect the filled form and submit deliberately, or if the site’s form behaves unexpectedly. Check the destination and outcome either way; sites can use unusual or multi-step forms.

1Password’s security documentation says it will not Autofill without user input, even when there is one suggested item. It also warns that deceptive pages can try to trick people into interacting with Autofill. Keep the site visible, check the domain, and do not approve a credential fill just because a page asks.

2. Reuse an authenticated session in Playwright

Playwright’s documented pattern is to sign in once in a setup project, save the browser context’s storage state, and load that state into contexts used by later tests. This saves repeating the login steps for each test. The example below uses a dedicated test account and credentials provided outside the source file.

This is a Playwright pattern, not a direct 1Password integration. The code does not control the 1Password extension or fetch secrets from a Login item. Use your team’s approved secret-management process to provide test credentials. Environment variables keep secrets out of the test source, but they do not by themselves address access control, logging, or runner security.

Install Playwright and configure authentication

In an existing Playwright Test project, create playwright.config.ts with a setup project and a dependent test project. The example assumes the site has email and password fields with accessible labels and a link named “Account”; adapt those locators and the success condition to the site under test.

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  projects: [
    {
      name: 'setup',
      testMatch: /auth\.setup\.ts/,
    },
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        storageState: 'playwright/.auth/user.json',
      },
      dependencies: ['setup'],
      testIgnore: /auth\.setup\.ts/,
    },
  ],
});

Create tests/auth.setup.ts. The setup test reads credentials from its process environment, signs in, checks a site-specific success condition, and saves the context state.

// tests/auth.setup.ts
import { test as setup, expect } from '@playwright/test';
import fs from 'node:fs';
import path from 'node:path';

const statePath = path.join('playwright', '.auth', 'user.json');

setup('authenticate', async ({ page }) => {
  const email = process.env.E2E_EMAIL;
  const password = process.env.E2E_PASSWORD;
  if (!email || !password) {
    throw new Error('Set E2E_EMAIL and E2E_PASSWORD for the test runner.');
  }

  await page.goto('https://example.com/login');
  await page.getByLabel('Email').fill(email);
  await page.getByLabel('Password').fill(password);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('link', { name: 'Account' })).toBeVisible();

  fs.mkdirSync(path.dirname(statePath), { recursive: true });
  await page.context().storageState({ path: statePath });
});

Replace https://example.com/login, the field labels, button name, and success check with the actual site’s sign-in flow. Do not weaken the success check to merely “the page loaded”: confirm an element or URL that indicates the intended test account is authenticated.

Load the saved state in tests

With the configured storageState, each test context starts with the saved state. For example:

// tests/account.spec.ts
import { test, expect } from '@playwright/test';

test('opens the signed-in account page', async ({ page }) => {
  await page.goto('https://example.com/account');
  await expect(page.getByRole('heading', { name: 'Account' })).toBeVisible();
});

Run the configured projects with npx playwright test. The setup project runs first because the test project depends on it. If the state expires or the site invalidates the session, rerun setup to create fresh state.

Protect the state file

Storage state may include cookies and headers that let someone impersonate the account. Playwright strongly discourages checking authentication state files into private or public repositories. Ignore the generated directory and keep it access-controlled:

# .gitignore
playwright/.auth/

Use a dedicated, least-privilege test account. Keep state files out of build artifacts, logs, and shared workspaces unless those systems are approved to handle session secrets. Remove temporary state when it is no longer needed. For parallel workers that change shared server-side data, use separate accounts and state per worker so tests do not interfere with one another.

3. Decide which workflow fits

Approach	Best for	How sign-in happens	Main consideration
1Password extension	A person signing in while browsing	The person selects a matching Login item; form submission can be disabled in settings	Check the domain and handle any site-specific follow-up steps
Playwright storage state	Repeated, authorized browser tests	Setup authenticates and later contexts load saved state	State is sensitive, can expire, and must be refreshed and protected

Sites may require MFA, passkeys, CAPTCHA, or additional checks. These examples do not bypass those controls or establish that unattended sign-in is supported. Follow the site’s rules and your organization’s test authorization. Do not try to defeat anti-automation protections.

4. Security and reliability boundaries

• For interactive Autofill: verify the domain before selecting a Login item. 1Password warns that deceptive pages and overlays can try to induce Autofill interaction.
• For automatic submission: decide whether convenience or an additional review step fits your use. Form behavior differs across sites, so verify where the browser lands.
• For unattended or AI-assisted browsing: do not give an agent access to credentials or an unlocked extension without deliberate authorization and a trusted workflow. 1Password’s January 2026 advisory discusses risks from assistants with browser-level user permissions. Treat webpage content as untrusted input.
• For Playwright: use a dedicated test identity, limit access to the saved state, and refresh state when the site expires it. A stored session is effectively a credential while it remains valid.

1Password announced a universal sign-in experience in January 2026 that can choose among authentication methods and fill credentials across multiple steps. The announcement does not establish availability on every account, platform, or site; verify availability before depending on it.

5. Troubleshooting

Symptom	Likely cause	What to do
The 1Password prompt does not appear	The extension is not installed, unlocked, enabled for the page, or the Login’s website address does not match	Open the extension, check its state and browser permissions, then verify the Login item’s website address
The wrong Login item is suggested	Multiple items match, or the saved address is too broad	Check the domain and select the intended item; edit saved website addresses to match the correct site
Credentials fill but sign-in does not complete	The site uses a multi-step flow, a different form structure, or requires an additional factor	Complete the site’s next step manually; review whether automatic submission should be disabled
Playwright cannot find a field or button	The example locator does not match the site’s accessible label or role	Inspect the actual page and use locators that reflect its labels and button names; avoid relying on brittle positional selectors
Playwright redirects to sign-in in a test	Setup did not finish successfully, state was not saved or loaded, or the session expired	Check the setup test’s success assertion, state path, project dependency, and site session lifetime; rerun setup
Tests fail intermittently when run in parallel	Tests share one account and modify the same server-side data	Give each worker an isolated account and its own authentication state, or serialize the conflicting tests
Sign-in is blocked by MFA, CAPTCHA, or a passkey prompt	The site requires an interactive or policy-controlled step	Use an approved test arrangement and the site’s supported authentication flow; do not attempt to bypass the control

6. Performance, reliability, and cost

Playwright storage state avoids repeating the full login routine for every test, but setup still has to authenticate and the saved session may expire or be revoked. That means fewer repeated sign-in steps, not a guarantee that a session remains valid. Keep a clear authenticated-state assertion so a login failure does not silently turn into misleading test results.

For reliable suites, isolate accounts when tests mutate shared data, keep setup and tests within the site’s permitted usage, and avoid treating CAPTCHA or other bot checks as an obstacle to evade. The code shown has no 1Password API call or extra product cost specified by the cited documentation. Your 1Password plan, test infrastructure, and target site’s policies may affect your actual costs and options.

Or skip the browser setup

If your goal is to capture a website rather than test an authenticated workflow, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. It does not automate logging in to a private account, so do not send passwords or private session data to capture a page that requires authentication.

Example request (see the ScreenshotNeo API documentation for options):

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

• Cookie banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
• Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed. Response headers say the page verdict and whether the request was billed.
• An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
• 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

7. FAQ

Can Playwright use a 1Password Login item directly?

The cited documentation establishes extension-driven filling and Playwright’s saved-state workflow, but not a supported direct 1Password-to-Playwright credential integration. Do not assume the extension can be safely or reliably controlled as an unattended credential source.

Does saved Playwright state include every kind of browser storage?

Playwright’s authentication workflow saves browser storage state for reuse. Check the current Playwright documentation and the target application’s authentication design if your app relies on state beyond the documented workflow.

Can I use my personal account for automated tests?

Prefer a dedicated test account with only the permissions the tests need. This limits the impact of an exposed state file and reduces interference with personal or production data.

What if a website asks for another sign-in method after Autofill?

Complete the site’s supported next step and follow its policy. Autofill does not mean every authentication factor is handled or that the site permits unattended automation.

Sources

• 1Password Support: Save and fill passwords in your browser
• 1Password Support: About the security of 1Password Autofill in your browser
• 1Password: Security advisory for AI-assisted browsing interactions with the 1Password browser extension
• Playwright: Authentication
• Playwright: Parameterize tests
• 1Password: Introducing universal sign-in
• 1Password: Autofill