What autocomplete value should a password field use?

Use autocomplete=current-password on a sign-in form so managers fill the saved password, and autocomplete=new-password on registration and change-password forms so they offer to generate and save a strong one. Mark a confirm-password field with new-password as well.

Why does my custom login form not trigger autofill?

Password managers look for a genuine input with type=password, ideally paired with an identifiable username or email field. A masked text input, a contenteditable div, or a JavaScript widget is usually not recognised, so the manager never offers to fill or save.

Does autocomplete=off actually disable autofill?

For password fields most modern browsers ignore autocomplete=off and still offer autofill, but it signals an intent to block it and some managers honour it. The checker flags it because it adds friction with no security benefit and should be removed from auth forms.

What is the readonly focus trick the tool warns about?

Some sites set a password field to readonly and only make it editable on focus to stop browser autofill. This is an anti-pattern that breaks legitimate password managers and frustrates users; the checker flags readonly password fields so you can remove the workaround.

Is my HTML uploaded anywhere?

No. The tool parses your markup locally using the browser's built-in DOMParser, so nothing you paste is sent to a server. You can safely test private or pre-release sign-in forms.

Password Manager Readiness Checker

When a password manager fails to offer autofill, users fall back to typing or reusing weak passwords — hurting both security and sign-in conversion. The fix is almost always in the form markup. Paste your login or registration HTML here and the tool checks it against the rules managers actually rely on, and flags the anti-patterns that quietly break them.

How it works

The checker parses your markup with the browser’s native DOMParser, so it reads the real attributes rather than guessing with text matching. It then runs a series of checks:

A genuine input type="password" exists — the primary signal managers use to detect a login form.
A username or email field is present (type="email", autocomplete="username", or a name like login) so the manager knows what to save as the account identifier.
Each password field declares autocomplete="current-password" (login) or "new-password" (registration / change), and nothing unexpected.
Anti-autofill patterns are absent: autocomplete="off" on the form or password field, readonly (the focus-to-unlock trick), disabled fields, and password fields with no stable name/id.
A heads-up if the form sits inside an <iframe>, which often blocks cross-origin autofill.

Findings are graded FAIL (blocking), WARN (should fix), or OK (informational), each with a specific remediation.

Example

The default sample has a password field typed as type="text", so it is flagged FAIL — managers will not recognise it. Change it to type="password" and add autocomplete="current-password" and the form passes.

Notes and tips

The two tokens that matter most are current-password and new-password. Getting them right lets managers fill the correct value on login and offer to generate a strong one on signup.
Keep the username and password fields in the same <form>; splitting them across separate forms or steps can require extra hints (an off-screen username field) to keep autofill working.
Never use the readonly-on-load trick to fight autofill. It breaks password managers and accessibility tooling, and modern browsers already mitigate the autofill behaviour it was meant to stop.