On a login form and on a change-password form, which HTML autocomplete values belong on the password inputs, and what does autocomplete="new-password" change?

## Two tokens, two opposite requests HTML defines three password-adjacent autofill tokens: `current-password`, `new-password`, and `one-time-code`. The first two look like variations on "password" but they request opposite behaviour from the browser's credential store. `current-password` means: *this field wants the password the user already has for this site.* The browser is invited to fill it from its store, and after a successful submission to treat the form as a sign-in. `new-password` means: *this field wants a password the user does not have yet.* The browser must **not** fill the stored value here. Instead it may offer to generate a strong random password, and after submission it should offer to save or update the stored credential rather than reuse it. ## The two canonical forms A sign-in form: ```html <label for="u">Email</label> <input id="u" name="u" type="email" autocomplete="username"> <label for="p">Password</label> <input id="p" name="p" type="password" autocomplete="current-password"> ``` The `username` token is half the pattern and is routinely forgotten. A password manager stores a pair, so it needs to know which field is the identifier; `type="email"` alone is a weaker signal because plenty of forms contain an email field that is not the account name. A registration form: ```html <input type="email" autocomplete="username"> <input type="password" autocomplete="new-password"> <input type="password" autocomplete="new-password"> ``` Both password boxes get `new-password`. That is deliberate, not a copy-paste slip: when the browser generates a password it fills both, and when the user types their own it knows the second box is a confirmation of the same new secret rather than a second credential. A change-password form: ```html <input type="password" autocomplete="current-password"> <!-- old --> <input type="password" autocomplete="new-password"> <!-- new --> <input type="password" autocomplete="new-password"> <!-- confirm --> ``` ## What breaks when you get it wrong The most common bug is marking every password field `current-password`, or marking none of them at all and letting heuristics decide. The browser then fills the stored password into the *new* password box. Two bad outcomes follow. Either the user does not notice, submits, and the server rejects the change because the new password equals the old one — or the server accepts it and nothing actually changed. Meanwhile the manager sees a login-shaped submission and never prompts to update the stored entry, so the next visit fills a password that is no longer current. The mirror mistake is putting `new-password` on a login field. Now the browser refuses to fill the saved credential and instead offers to generate one, which is baffling on a sign-in screen and pushes users toward typing from memory. ## The missing-username problem Many change-password screens live behind an authenticated session and show no username at all. A credential manager needs an identifier to know *which* stored entry to update — without one it may create a duplicate entry or skip the update prompt entirely. The standard remedy is to include the account identifier in the form as a real input carrying `autocomplete="username"`, made non-editable and hidden visually rather than removed from the accessibility tree by `type="hidden"` — managers generally look at real, rendered fields. Something like: ```html <input type="text" name="username" value="[email protected]" autocomplete="username" readonly hidden> ``` Behaviour varies between managers, so test with more than one; the principle — give the form an identifier — holds regardless. ## Related tokens and grouping `one-time-code` is the third member of the family and covers a code delivered out of band, which is a different flow again. For passkeys, the HTML autofill grammar allows the `webauthn` token to be appended after the field name (as in `autocomplete="username webauthn"`) so that the browser can surface passkeys in the same autofill dropdown as saved passwords. ## What these tokens are not They are not a security control. Nothing about `new-password` enforces password strength, and nothing about `current-password` verifies anything — the server still owns rules, hashing and rate limiting. What the tokens buy is that the *right* value lands in the *right* box and the manager's stored entry stays in sync, which in practice is what pushes users toward long generated passwords instead of memorable reused ones. They are also not a substitute for labelling. A password field still needs a real `<label>`; the autofill token speaks to the browser, the label speaks to the user and to assistive technology, and neither one covers for the other.