A reviewer asks you to put autocomplete="off" on the password input of your site's login form. Why is that usually the wrong call, and what do browsers actually do with it?

## What the attribute asks for `autocomplete="off"` is a request that the browser not remember the value and not pre-fill the field from anything it has stored. It is a request, not an instruction, and the HTML standard is explicit that user agents may ignore it — most pointedly for fields the browser's own credential manager cares about. It can be written per-field, or once on the `<form>` element as the default for the controls inside it. ## Why browsers stopped honouring it on credentials The attribute was widely deployed on login forms during a period when "the browser remembering your password is dangerous" was conventional wisdom. As built-in password managers matured, that use collided with them directly: a site could unilaterally disable the feature browsers were actively encouraging users to adopt. Vendors resolved the collision in the users' favour. On password fields, mainstream browsers now ignore `autocomplete="off"` and continue to offer saving and filling; several extend the same treatment to address and payment autofill, where the user's stored profile is theirs, not the site's, to control. The practical consequence for you is that shipping `autocomplete="off"` on a login form is close to a no-op with a compliance smell: it appears in the markup, satisfies a checklist item, and changes nothing an attacker would notice. ## Why it would be undesirable even if it worked Suppose your users' browser did honour it. What have you achieved? Nobody responds to a form that refuses to fill by inventing a long random password and retyping it from a vault every visit. They respond by choosing something they can retype: shorter, memorable, and reused across sites. The measure trades a local, well-protected credential store for password reuse — a demonstrably worse position. The threat that motivates the request — a shared or unattended machine — is not addressed by the attribute at all. The password was already saved on that device by the browser, from some earlier visit, whether or not this form says `off`. What actually helps sits on your side of the boundary: sensible session lifetimes, a visible sign-out that invalidates the server-side session, re-authentication before sensitive operations, and letting users see and revoke active sessions. ## Where autocomplete="off" is genuinely right The attribute is not useless. It fits fields whose value is meaningful exactly once and would be actively wrong if remembered or replayed: - a one-time transaction authorisation code or a per-transfer confirmation value; - a challenge answer the user must derive fresh each time; - a field where the browser's stored profile would reliably fill the wrong thing — a form that asks for *someone else's* name and address, such as a gift recipient or a dependant, where offering the user's own saved profile is a nuisance rather than a help. That last case is worth care: reach for it only when a grouping token cannot express the situation better. Two distinct addresses in one form are described with `shipping` / `billing` or `section-*` prefixes rather than by switching autofill off. Also note the family relationship: for a code arriving by SMS you generally want `autocomplete="one-time-code"`, not `off`. The token says "this is a single-use code" and enables the platform to surface it, which is both more useful and more accurate than suppression. ## The anti-pattern of the random token A workaround that circulates widely is to defeat autofill by writing a nonsense value — `autocomplete="nope"`, `autocomplete="new-thing-42"` — on the theory that an unrecognised token is not `on`. It is not a supported mechanism. An unrecognised token is simply not a field name, so you fall back to the browser's heuristics; whether anything is suppressed depends on implementation details that change. Code built on that trick breaks quietly on a browser update and leaves a value in the markup that no one can explain. ## How to answer the reviewer Say plainly what the attribute does and does not do, name the narrow cases where it applies, and redirect the concern to controls that live in your system. If the requirement is genuinely "credentials must not persist on this device", the honest answer is that a web form cannot enforce it — that is device management territory. If the requirement is "this specific value must not be replayed", then `autocomplete="off"` on that one field is exactly right, and you should scope it there rather than blanket the form. And if the form is a login, the productive change is the opposite of the request: add `autocomplete="username"` and `autocomplete="current-password"`, so that the manager fills the right boxes and users can afford long generated passwords.