---
title: "How long should my registration form password be? · Proxy Mail QA"
description: "Password length and rules for a registration form, from NIST SP 800-63B, and how to check your form and server do what you decided."
url: https://proxymail.qa/solve/how-long-should-my-registration-form-password-be
---

1. [Home](https://proxymail.qa/)
2. [What we solve](https://proxymail.qa/solve)

# How long should my registration form password be?

The short answer comes from NIST's digital identity guidelines. The longer answer is checking that your form and your server both do what you decided.

Updated 5 November 2026

> **Our recommendation, up front.** We make Proxy Mail QA, so we’re not neutral, but it doesn’t choose your password policy. The numbers below come from NIST’s digital identity guidelines (SP 800-63B, fourth revision), which many security teams follow. We recommend Proxy Mail QA for the step after you decide: checking that your form and your server actually do what you decided, with test passwords at exactly the minimum and maximum, one either side, and every kind of symbol. It doesn’t review your password storage or your security as a whole.

## The short answer

- **At least 15 characters** if the password is all someone needs to sign in.
- **At least 8 characters** if every account also has a second factor, such as a code from an authenticator app.
- **Allow at least 64 characters.** Longer is fine; a limit in the thousands isn’t needed.
- **No rules demanding a capital, a number and a symbol.** Length matters more, and those rules make people choose `Password1!`.
- **Refuse common and breached passwords**, by checking new ones against a list.

## The rest of the guidance, in plain words

NIST’s guidance for passwords chosen by users also says:

- **Accept any characters**: letters, digits, symbols, spaces and characters from other languages. Normalise Unicode (to NFC) before hashing, so `é` typed two different ways is the same password.
- **Count characters, not bytes**, when checking the length.
- **Don’t cut passwords short.** Check the whole password, never just the start of it.
- **Don’t force people to change passwords on a schedule.** Ask for a change only when there’s a sign the password was exposed.
- **No password hints and no security questions.**
- **Allow paste and password managers**, so people can use long random passwords without typing them.
- **Show what was typed** on request, so people can check a long password before they submit.

## Why have a maximum at all?

A very long password costs your server time to hash, so a maximum stops someone sending megabytes as a password. Set it well above what people use: 64 is the least NIST recommends allowing, and 128 or 256 is common.

Watch your hashing algorithm. **bcrypt reads only the first 72 bytes** of a password and ignores the rest. Two long passwords that start the same then sign in as each other. A character can be more than one byte (`é` is two, an emoji is four), so 72 bytes can be fewer than 72 characters. Either:

- use Argon2id (or scrypt), which has no such limit, or
- keep the maximum at a length that fits in 72 bytes, or
- if you must keep bcrypt with longer passwords, hash the password first in a way your security team approves.

## Put the rules where the browser can see them

HTML

```html
<label for="password">Password</label>
<p id="password-rules">At least 15 characters. Any letters, numbers, symbols or spaces.</p>
<input id="password" name="password" type="password" autocomplete="new-password" minlength="15" maxlength="128" aria-describedby="password-rules" required />

```

- `minlength` and `maxlength` let the browser warn early, and password managers make passwords that fit. `maxlength` also cuts pasted text short without saying so, so set it well above what a password manager would make.
- `autocomplete="new-password"` tells password managers to offer a new strong password.
- Show the rules before someone types, not only after they get it wrong.
- **Enforce the same rules on the server.** The browser’s checks are a convenience; anyone can skip them.
- If you use an auth service (Supabase Auth, Clerk, Firebase Authentication, Auth0 and others), set the minimum in its settings as well. Many default to a much shorter one, and a page that says 15 while the service accepts 6 is a common bug.

## Check that your form does what you decided

`get_password_variants` (MCP), `qa.passwordVariants()` (npm) or `GET /v1/variants/passwords` (REST API) take your rules (`min_length`, `max_length`, and whether `symbols` are allowed) and return fresh test passwords in three groups:

| Group  | With a 15-to-64 policy                                                                                                                                                  | What should happen                                                                                           |
| ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| accept | Exactly 15 and exactly 64 characters; each kind of symbol; a space inside; éüñ                                                                                          | Accepted, and signs in afterwards exactly as typed                                                           |
| reject | 14 characters; 65 characters                                                                                                                                            | Refused, with the rule, before an account is made                                                            |
| decide | Only digits; only lower-case letters; a space at the start or end; an emoji; é typed two ways; two passwords sharing their first 72 bytes (when the maximum is over 72) | Your choice, but decide on purpose. Under NIST, a 15-digit password is allowed unless it’s on your blocklist |

The 72-byte pair is the one to watch: if the second password signs in to the account made with the first, your app is cutting passwords short.

You can run these by hand, from an agent, or in a test:

- **By hand:** with [Proxy Mail QA for Chrome](https://proxymail.qa/chrome-extension), the card in the password field offers **Edge-case password**, with lists marked “Should be accepted” and “Should be rejected”, made to fit the field’s own `minlength` and `maxlength`. Its everyday passwords fit those rules too.
- **From an agent:** with Proxy Mail QA connected in Qoder ([Marketplace](https://qoder.com/en/marketplace/connector?id=proxymail-qa)):

Prompt

```text
Our password policy is 15 to 128 characters, any characters allowed. Using Proxy Mail QA,
get_password_variants with min_length 15 and max_length 128, and try each one on
https://staging.acme.dev/signup with a new test address (use a plus tag for each).
For accepted ones, verify the account and sign in with the same password.
Give me a table: what it tests, accepted or refused, the message shown, and whether
signing in worked.

```

- **In a test:** `await qa.passwordVariants({ minLength: 15, maxLength: 128 })` returns `accept`, `reject` and `decide`, each a list of `{ tests, value }` to loop over in Playwright or Cypress.

If refused passwords show no error at all, see [Why is my registration form not showing password errors?](https://proxymail.qa/solve/why-is-my-registration-form-not-showing-password-errors)

## What Proxy Mail QA doesn’t do here

- Choose your policy, or tell you whether it meets a law or a standard you’re held to.
- Check how passwords are stored, or test the rest of your security. A security review or penetration test does that.
- Test a blocklist of breached passwords: try a few well-known ones, such as `password1234567`, yourself.

Sources: [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html), and its section on [authenticators](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/).

## Try it on your next sign-up test

Free plan, no credit card. Create an address and watch the code or link arrive.

[Create a free account](https://app.proxymail.qa/?mode=signup&from=site-solve-how-long-should-my-registrati)

## Related guides

- [Test sign-up and email verificationA fresh, private address for every sign-up test, with the verification link or code ready the moment it lands.](https://proxymail.qa/solve/email-verification-testing)
- [Test OTP and one-time login codesCodes pulled out of the email with a Copy button and a countdown when the email says how long they last.](https://proxymail.qa/solve/otp-code-testing)
- [Test magic links and passwordless sign-inSingle-use links that are never opened or prefetched on our side, so they still work when you click them.](https://proxymail.qa/solve/magic-link-testing)
- [Test password reset emailsRequest, receive and use reset links, and keep the new password saved next to the test account.](https://proxymail.qa/solve/password-reset-testing)
- [Stop sharing one Gmail inbox for QAPrivate, disposable addresses for every tester instead of one shared mailbox and a pile of plus-addresses.](https://proxymail.qa/solve/shared-test-inbox)
- [Take QA notes by voice with Wispr FlowDictate what each test account is for, its state and what you found, straight into its notes, in seconds.](https://proxymail.qa/solve/voice-notes-wispr-flow)
- [Verification link points to localhost:3000Why emails from staging link to localhost, how to fix it in Supabase, Firebase and other stacks, and how we flag it.](https://proxymail.qa/solve/localhost-links)
- [Common Supabase sign-up and login problemsEmails that never arrive, links that expire or sign nobody in, and sign-ups that fail, with the fix for each.](https://proxymail.qa/solve/supabase-auth-problems)
- [Common Firebase sign-up and login problemsMissing verification and reset emails, verified users who still look unverified, failing links and sign-up limits, with the fix for each.](https://proxymail.qa/solve/firebase-auth-problems)
- [Sign-up and login problems in vibe-coded appsThe login bugs AI-built apps usually ship with: emails only you receive, links to the preview, missing pages, and what to ask the builder.](https://proxymail.qa/solve/vibe-coded-login-problems)
- [Test sign-up emails in PlaywrightA complete Playwright test for sign-up codes and links, from a fresh inbox to the report on the pull request.](https://proxymail.qa/solve/playwright-email-tests)
- [Test sign-up emails in CypressA complete Cypress test for sign-up links and codes, with the email waits running as Cypress tasks.](https://proxymail.qa/solve/cypress-email-tests)
- [Test sign-up emails with pytestA complete pytest test for sign-up codes and links, with Playwright for Python or Selenium and a one-file helper.](https://proxymail.qa/solve/pytest-email-tests)
- [Test coupon codes and welcome offersThe coupon with its discount, end date and arrival time, what checkout did with it, and a failure when an expired or reused one is accepted.](https://proxymail.qa/solve/coupon-code-testing)
- [Test unsubscribe links and one-click unsubscribeThe unsubscribe headers and link checked on every marketing email, and a watch that flags any marketing after unsubscribing, with no time limit.](https://proxymail.qa/solve/unsubscribe-testing)
- [Test that a welcome offer can't be claimed twiceVersions of one address that reach the same inbox, and a check that fails when the same person got the offer more than once.](https://proxymail.qa/solve/welcome-offer-abuse)
- [AI sign-up page reviewLet an agent check the sign-up through to the email: delivery, the link, how it was sent, and that only one arrives.](https://proxymail.qa/solve/ai-sign-up-page-review)
- [AI registration page reviewAn agent tries every field with values made for it, then finishes the registration through the email.](https://proxymail.qa/solve/ai-registration-page-review)
- [Review a sign-up page by handA checklist for your browser and phone, in the order that finds the most problems.](https://proxymail.qa/solve/how-to-review-my-sign-up-page)
- [Review a simple sign-up form12 checks for a form with an email, a password and perhaps a name.](https://proxymail.qa/solve/review-a-simple-sign-up-form)
- [Review a multi-page sign-up formOne test account across every screen, and the verification email wherever it comes.](https://proxymail.qa/solve/review-a-multi-page-sign-up-form)
- [Review a financial sign-up formThe emails, age and country rules and awkward values in a financial sign-up, and what needs other tools.](https://proxymail.qa/solve/review-a-financial-website-sign-up-form)
- [An email address for testing registrationA new, real address for every registration try, with the code or link ready to use.](https://proxymail.qa/solve/email-for-checking-my-registration-form)
- [An email address for testing sign-inTest accounts with saved passwords and an inbox for codes, magic links and resets.](https://proxymail.qa/solve/email-for-checking-my-sign-in-form)
- [No error for a password that breaks the rulesThe eight usual causes of a silent password field, and how to tell which one it is.](https://proxymail.qa/solve/why-is-my-registration-form-not-showing-password-errors)
- [Help me check my websiteA whole-site check in an afternoon, in the order that finds the costliest problems first.](https://proxymail.qa/solve/help-me-check-my-website)
- [Tools to build and check a websiteA toolkit by area, most of it free and none of it ours, except for account emails.](https://proxymail.qa/solve/tools-to-help-build-and-check-my-website)
- [What tools do I need for a website?The full list, then which parts a simple site can skip.](https://proxymail.qa/solve/what-tools-do-i-need-when-building-a-website)

[Built your app with an AI tool? Pick yours](https://proxymail.qa/built-with)
