In one paragraph
Autocomplete off on a password field can interfere with useful password-manager hints, although many browsers ignore it for login credentials. Use current-password for sign-in and new-password for registration or replacement passwords. Check the field's real purpose before changing it: a masked API-secret input is not necessarily an account login. Verify behaviour with supported browsers and password managers.
Why it matters
Password managers help people use unique credentials without memorising every password. Login markup that clearly identifies the username and password gives these tools better information than generic field names or deliberately disabled autocomplete.
The attribute is a hint, not a guarantee that every browser will fill or save a value. Browsers and extensions use their own heuristics, settings, and security policies. Missing hints do not automatically prevent login, and adding a hint does not eliminate password reuse or implement secure authentication.
How WebAuditOS evaluates this finding
The supplied rule inspects password inputs inside forms in the server-returned HTML. autocomplete="off" or "false" produces an informational warning. If neither occurs but a password field lacks the attribute, that also warns. Other declared values pass; no eligible form is not graded.
Presence is not semantic correctness. A password input with autocomplete="username" can pass this rule despite being misleading. JavaScript-created inputs and password fields outside a form are not covered by the described test. A passing result therefore does not prove that a password manager identifies the form correctly.
How to fix it
- Classify every affected field. Distinguish sign-in, registration, existing-password confirmation, new-password creation, and non-login secrets. Use the quoted field count to locate all relevant instances, not only the first visible form.
- Mark sign-in fields with meaningful hints. A minimal fragment is:
<input name="email" type="email" autocomplete="username">
<input name="password" type="password" autocomplete="current-password">Provide associated visible labels and a proper form structure; these example inputs alone are not a complete accessible login form.
- Use autocomplete="new-password" for a newly created password and its confirmation. On a password-change page, the existing password can use current-password while the replacement uses new-password. Do not label both as the existing password merely because both are masked.
- Use an appropriate separate hint for a one-time code when supported, rather than calling it a reusable account password. Keep authentication factors and their validation distinct.
- Fix the shared form component or CMS template if it emits the same incorrect attribute everywhere. Inspect the rendered HTML as well as the server source so runtime components do not overwrite the intended values.
- Test a saved account, a new account, password generation, and a changed password in your supported browser and manager combinations. Check that the account identifier and password are filled into the intended form, especially when registration and sign-in share a page.
- Review intentional exceptions. An API-key field should not invite the visitor's own site password. Choose its markup and autocomplete strategy based on its function, recognise that tools may still apply heuristics, and document the exception if the automated rule continues to warn.
- Rescan the affected HTML and retain a manual test for client-rendered forms. This fix improves the interface; it does not add HTTPS, hashing, rate limiting, or other server-side authentication controls.
What the fix can break
The intended effect is that tools offer to save, fill, or generate credentials more reliably. A mislabelled field can instead receive a saved password in the wrong place, so test non-login settings screens carefully.
Organisational policies may still require autocomplete off. Review such requirements with the responsible owner rather than silently breaking a documented constraint; an old rule may need updating instead of a permanent UI workaround.
Do not promise that autocomplete off protects a shared computer. Browser profiles, account access, and device security remain separate controls, and browsers may ignore this hint on login fields.
Questions
Should login forms use current-password or new-password?
Use current-password when entering an existing credential. Use new-password when creating or replacing one, including a confirmation input.
Does autocomplete off reliably stop password saving?
No. Many browsers and password managers ignore it for credentials. Treat it as a hint with product-dependent behaviour, not an enforceable device-security policy.
Why did the check pass with an unhelpful value?
The documented rule accepts other declared values without confirming their purpose. Test semantics and password-manager behaviour yourself.
Which related page should I review?
Review password fields on HTTP. Helpful autocomplete cannot make a plaintext login safe.