Help users change passwords easily by adding a well-known URL for changing passwords

Password managers can take users straight to your password-change page

Passwords are still the backbone of most web authentication, and that won't change overnight. While the industry moves toward WebAuthn and other passwordless approaches, there is a simple way to make the password lifecycle more pleasant for your users: support the well-known change-password URL. Password managers can then navigate users directly to the correct page to update a weak or compromised password, instead of dropping them at the homepage and making them hunt for the right settings screen.

Setting this up is a redirect. Point /.well-known/change-password on your domain to whatever URL handles password changes. For example, if your site is https://example.com and the change-password page is https://example.com/settings/password, configure your server to redirect https://example.com/.well-known/change-password to that page. Use HTTP status code 302 Found, 303 See Other, or 307 Temporary Redirect for the redirect.

If serving static HTML, an alternative is to place a page at /.well-known/change-password with a meta refresh:

<meta http-equiv="refresh" content="0; url=https://example.com/settings/password">

Why a well-known URL helps

Password managers already generate strong passwords, autofill them into the right fields, and refuse to fill them on phishing sites. They are now adding a fourth capability: detecting reused, weak, or leaked credentials and recommending that the user changes them.

That last step historically involved telling the user to go update a password and letting them find the page on their own. With the well-known URL, the password manager can jump straight to the relevant form. Making that form itself manageable matters too. If the change-password page asks for the current password, annotate it with autocomplete="current-password". New-password fields inline in the change form should use autocomplete="new-password" where possible. Matching the guidance in Sign-in form best practices makes the password manager's job trivial.

Who supports it

Safari has supported the well-known change-password URL since 2019. Chrome's password manager began using it from version 86. Firefox has indicated the proposal is worth implementing but has not committed to a timeline. Major sites already doing this include Google, GitHub, Facebook, Twitter, and WordPress.

How Chrome uses it

Chrome's built-in password manager can flag leaked passwords from the password settings screen at about://settings/passwords. When the user clicks the "Change password" button next to a flagged entry, the browser opens the site's change-password page if /.well-known/change-password is configured, and falls back to the homepage otherwise.

Server reliability matters

Password managers don't just follow the URL blindly; they probe it first. A well-known URL responder needs to be honest: serving 200 OK for pages that do not exist, whether from a server-side renderer, a single-page app, or an aggressive redirect handler, confuses detection. The proposal reserves a second path, /.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200, as a test. Chrome probes this URL to verify that the server truthfully returns 404 Not Found for missing content before trusting the change-password URL. Make sure your server returns 404 Not Found for genuinely missing resources, and your well-known redirect will work as intended.