Password Field

Logging into your bank, creating an account in a food delivery app, confirming a payment, changing your password after a breach: the password field is the gate to almost every account. When it works, nobody notices. When it doesn’t, users can’t get in, and they blame themselves (“I must have forgotten it”) before they blame the app.

A password field is a text field with a few extra jobs: hide the value, let people reveal it, play nicely with password managers, and explain the rules. Each job has its own classic bugs. The bigger flow around it (generic error messages, lockout, sessions, reset links) lives on the Login & sign up page. This page is about the field itself.

What is a password field?

A password field is a single-line text field that masks what you type, showing dots instead of characters. It’s used for passwords, PINs typed on a keyboard, and other secrets like an API key or a card’s security code.

It comes in two flavors, and they behave differently:

• Current password (login, confirm before deleting the account): the user types or autofills a password that already exists. It must accept it exactly as it was saved.
• New password (sign-up, change password, reset): the user invents one. The field shows the rules, maybe a strength meter, and password managers offer to generate one.

Anatomy

How it differs from similar components

Component	What’s different	Typical use
Password field	Masked, never autocorrected, managers fill it	Login, sign-up, change password
Text field	Shows the value, may autocorrect	Name, email, notes
One-time code field	Digits only, often split boxes, SMS autofill	2FA codes
PIN pad	On-screen digits, fixed length	App lock, card PIN

Dev note

iOS calls it a secure text field (isSecureTextEntry in UIKit, SecureField in SwiftUI). Android uses an EditText with inputType="textPassword", or a Material TextInputLayout with a password toggle. On the web it’s <input type="password">. Screen readers announce it as “secure text field” or “password”.

Designs & variants

The parts are the same everywhere; what changes is who helps the user. On iOS it’s the Passwords app and its QuickType bar, on Android the autofill service (Google Password Manager or another manager), on the web the browser and extensions.

Every field here works. Type something, reveal it, put the cursor in the middle and reveal again: the cursor should stay where it was.

Email

Password

anna@example.com

QuickType bar above the keyboard (tap a field)

New password

Password

Suggested: hapzov-4Kuqwe-rydtiX. Saved in Passwords.

Use Strong PasswordChoose My Own Password

Password

At least 12 characters

Password

Show

Simulate Caps Lock (for phones)

Create a password

• At least 12 characters, not yet
• Not a commonly used password, not yet
• Doesn’t contain your email name, not yet

Password

Naive meter (character types)

Strength: Strong · Counts character types only.

Length + common-password list

Strength: Very weak · This is one of the most common passwords. Attackers try it first.

Password1!sunflower meadow at duskTr0ub4dor&3

Show / hide: small button, many details

Masking protects against someone looking over your shoulder, but it also hides typos. That’s why almost every modern password field has a show/hide toggle. A good one:

• Has a name that says what it does (“Show password”) and tells the state: either the name changes to “Hide password”, or it’s a toggle button with a pressed state. An icon alone says nothing to a screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary →.
  Dev note

  On the web: aria-pressed.
• Keeps the value and the cursor position. Tap it in the middle of typing and keep typing: the new characters must go where the cursor was, not to the start.
• Keeps focus in the field (on mobile, the keyboard shouldn’t close and reopen).
• Goes back to hidden when the user leaves the screen or submits, so the password isn’t still visible later.
• Has a big enough touch area: at least 44×44 pt on iOS and 48×48 dp on Android. On the web, WCAG 2.5.8 (AA) asks for at least 24×24 CSS px; 44×44 px (2.5.5, AAA) is the comfortable target.

Password managers and autofill

Many people never type their passwords: a password managerPassword managerA tool that stores credentials and fills them into login forms, like Apple Passwords, Google Password Manager or 1Password.Open in glossary → fills them in. That only works if the field tells the system what it is, and if the app doesn’t fight the manager.

Field	Web autocomplete	iOS textContentType	Android autofillHints
Email / username	username	.username	username / emailAddress
Login password	current-password	.password	password
Sign-up / new password	new-password	.newPassword	newPassword

What to check:

• Login: the saved password is offered (iOS QuickType bar, Android autofill dropdown, browser key icon) and fills both username and password.
• Sign-up: the system suggests a strong password, fills it in, and offers to save it with the right username.
  Dev note

  On iOS, apps can describe their rules with passwordRules so the suggestion actually passes them; on the web Safari reads the passwordrules attribute.
• Paste works. Users of password managers that don’t autofill copy and paste. Blocking paste doesn’t make anything safer; it pushes people to shorter passwords they can type. WCAG 2.2 criterion 3.3.8 Accessible Authentication (Minimum) (Level AA) expects login not to depend on remembering or retyping a password, and allowing paste and autofill is the usual way to meet it.
• autocomplete="off" is a smell. On password fields most browsers ignore it, some managers honor it, so behavior becomes unpredictable. It’s never a security fix.
• App and website share passwords when they’re linked: on iOS through Associated Domains, on Android through Digital Asset Links. A password saved on the website should be offered in the app.

Rules, checklists and strength meters

Users can only follow rules they can see. Show them before the user types, then tick them off live. Error messages that reveal one rule at a time (“Needs a number.” → “Needs a symbol.” → “Too short.”) are a classic usability bug.

Strength meters are trickier than they look. The common, naive version counts character types: lowercase, uppercase, digit, symbol. That’s exactly what attackers expect. It rates Password1! as Strong (it’s one of the first passwords any attacker tries) and a long passphrase like sunflower meadow at dusk as Weak. Current guidance, like NIST’s SP 800-63B, favors length and checking against lists of common and breached passwords over composition rules.

Length, spaces and other characters

• Maximum length: allow long passwords (64 characters or more is a common recommendation). If there’s a maximum, tell the user and enforce it the same way on every form. A browser’s maxlength cuts typed and pasted text without any message.
• Silent truncationTruncationText that gets cut off because it doesn't fit its space.Open in glossary →: if sign-up saves 20 characters but login only sends the first 16, the user is locked out with the right password. See password hashingPassword hashingStoring a one-way scrambled version of a password instead of the password itself.Open in glossary →.
  Dev note

  Some hashing algorithms (bcrypt) also only use the first 72 bytes.
• Spaces: a space is a valid password character. Trimming leading or trailing spaces is a team decision, but it must happen the same way everywhere, or “Secret123 ” saved at sign-up won’t match at login.
• Unicode: accented letters and emoji should work, and a password set on the web must work in the app. The keyboard on another device may produce a differently encoded “č”.

Caps Lock and other helpers

On computers, Caps Lock is the top reason for “I typed the right password”. A web field can detect it while you type and show a warning. Safari on macOS shows its own Caps Lock indicator in password fields. Phones don’t need this, their keyboards show the shift state.

Dev note

event.getModifierState('CapsLock').

Keep the secret secret

A few security basics belong to the field itself:

• Never in the URL or logs. The password goes in a POST body, not in ?password=…, and never into analytics events or crash logs. Check the network traffic with DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary → or a proxy tool.
• No copy out of a masked field. Browsers and the OS disable Copy and Cut while the value is hidden.
• No autocorrect, no suggestions, no autocapitalize. Otherwise the keyboard may learn the password and suggest it later.
• Screenshots and screen recording on sensitive screens: Android apps can block screenshots and recording and blank the app in the recent apps view. iOS has no switch to block screenshots; apps hide sensitive content when screen capture is detected and cover the screen in the app switcher.
  Dev note

  On Android that’s FLAG_SECURE on the window.

When to use it

A password field is the right choice when:

• The value is a secret that people nearby shouldn’t see: password, PIN on a keyboard, recovery phrase, API key.
• The user must type it again later exactly as now, so a typo matters (that’s why reveal is so useful).
• Password managers should recognize the field.

Good and bad uses

Also avoid a password field for things that aren’t secret: masking a username, a promo code or an amount only makes typos harder to see. And a one-time code has its own field type, with SMS autofill.

Dev note

autocomplete="one-time-code".

Common bugs

#	Bug	What you see	Typical severity
1	Silent truncation	Sign-up accepts 20 characters, login cuts to 16: the right password never works	Critical
2	Paste blocked	Paste does nothing; password manager users can’t log in	High
3	Autofill broken	No saved password offered, or the email lands in the password field	High
4	Toggle without name or state	Screen reader says just “button”	High (for affected users)
5	Toggle moves the cursor	After revealing, new characters go to the start, or the field is cleared	Medium
6	Misleading strength meter	Password1! is “Strong”, a long passphrase is “Weak”	Medium
7	Rules hidden until failure	“Invalid password” with no hint, or one rule revealed per attempt	Medium
8	Inconsistent rules	Sign-up allows spaces or emoji, login or reset rejects them	High
9	Spaces trimmed on one side only	“Secret123 ” saved at sign-up doesn’t match at login	High
10	Password leaks	Visible in the URL, a log, an analytics event or the app switcher	Critical (security)
11	Stays revealed	Come back to the screen and the password is still in plain text	Medium
12	Autocorrect on	The keyboard “fixes” the password or suggests it later	Medium

Stress-test it

Sign-up and login are two different forms that must agree on the same secret. Change how each one treats length and spaces, switch the feedback style and the autocomplete value, and use the presets.

🧪 Password lab

One account, two forms: what sign-up saves and what login later sends. Change how each side treats the password and see if the user can still get in.

Maximum length

64 on both formsLogin cuts at 16

Leading / trailing spaces

KeepTrim at sign-up onlyTrim both

Feedback while typing

Rules checklistNaive meterBetter meter

autocomplete attributecurrent-passwordnew-passwordoff

Simulate Caps Lock on

Password

Strength: Weak · Counts character types only.

Password manager: Unpredictable: many browsers still fill passwords, some password managers skip the field. Never use it to "block" managers.

sunflower meadow at dusk·Password1!·Secret123Blue-Kettle-Sings-42Žuta kuća 🏠 na brduaaaaaaaaaaaa

Sign-up saves (24)

sunflower·meadow·at·dusk

Login sends (16)

sunflower·meadow

Values differ: "Email or password is incorrect", forever.

Same intent in native apps

iOS textContentType: (none) · Android: importantForAutofill="no"

The login field silently cuts the password to 16 characters. Sign-up saved 24, so this user can never log in with the password they chose.

Sign-up trims leading/trailing spaces but login doesn’t. Same password, different values: login fails.

The naive meter says "Weak", a length + blocklist check says "Strong". Users trust the meter, so a wrong one teaches bad passwords.

autocomplete="off" on a password field: password managers may ignore the field or save the wrong thing. Use current-password on login and new-password on sign-up.

Find the bug

Harbor Bank’s login and sign-up pages share one buggy password component. There’s already an account for anna@example.com; its password is in the password manager panel below the browser. Explore it like a real tester:

• Log in with Anna’s saved password: copy and paste it, then type it.
• Reveal the password in the middle of typing, then keep typing.
• Create an account with a weak password, then a common one, then a long one, and log in with it.
• Turn on the screen reader and Tab through the form.
• Watch the network log after every attempt.

🐞 Bug hunt: Harbor Bank login

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

bank.example.com

Harbor Bank

Log inCreate account

Email

Password

Log in

Device

Restart app

Password manager · saved login

anna@example.com · Blue-Kettle-Sings-42

Copy password

Screen reader (VoiceOver captions)

Network log

• Log in or create an account to see requests…

1. 1

   Hint: Copy Anna's password from the password manager panel and paste it into the password field.

   Paste is blocked in password fields

   Nothing happens: the field cancels the paste event. Password manager users can't log in without retyping a 20-character password by hand, which pushes people towards short, weak passwords. Expected: paste and autofill always work (WCAG 3.3.8 Accessible Authentication).

   Reveal answer✓ I found this
2. 2

   Hint: Type Anna's 20-character password into the login field, reveal it, and check the network log.

   Login silently cuts the password to 16 characters

   The login field has maxlength="16", so the last characters are dropped without a message: Blue-Kettle-Sing. The request shows (16 chars) and the server answers 401. Sign-up has no such limit, so every user with a password longer than 16 characters is locked out. Expected: the same limit (64+) on every form, and a visible message instead of silent truncation.

   Reveal answer✓ I found this
3. 3

   Hint: Turn on the screen reader and Tab from the password field to the eye icon.

   Show/hide button has no name and no state

   VoiceOver only says "button". A blind user can't tell what it does or whether the password is currently visible (and might reveal it in public). Expected: "Show password, button" that becomes "Hide password", or a toggle with aria-pressed (WCAG 4.1.2 Name, Role, Value).

   Reveal answer✓ I found this
4. 4

   Hint: Type half a password, tap the eye, then type a few more characters.

   Revealing the password moves the cursor to the start

   The field is re-created on every toggle and the cursor jumps to the beginning, so "Secret" + reveal + "123" becomes 123Secret. Users who don't look closely save a different password than they think. Expected: value, focus and cursor position stay exactly as they were.

   Reveal answer✓ I found this
5. 5

   Hint: On Create account, type Password1! and read the meter. Then try a long passphrase without capitals.

   Strength meter calls "Password1!" strong

   The meter only counts character types, so Password1! is "Strong" and the account is created, while sunflower meadow at dusk is "Weak". Expected: common and breached passwords are rejected or rated very weak, and length counts most.

   Reveal answer✓ I found this
6. 6

   Hint: On Create account, look for the rules before you submit anything.

   Password rules appear only after a failed attempt

   Nothing tells the user what's required until they submit a password that breaks a rule; only then does the list appear. Expected: rules visible below the field from the start, updated live as the user types.

   Reveal answer✓ I found this

How to test it

Checklist

Password field test checklist

0 of 15 checked

Copy

• The field masks the value and has a visible label (not only a placeholder)
• Show/hide works both ways, keeps the value, focus and cursor position
• The toggle has a name ("Show password") and announces its state
• Paste works, and Copy/Cut are disabled while the value is masked
• Login offers the saved password (iOS Passwords, Android autofill, browser) and fills the right fields
• Sign-up and change password get a strong password suggestion, and the manager saves it with the right username
• autocomplete / textContentType / autofillHints are current-password on login and new-password on sign-up
• Rules are shown before typing and ticked off live; errors name the rule that failed
• Any strength meter rejects or flags common passwords like Password1!
• The same long password (64+ characters, spaces, emoji, accents) works on sign-up, login, change and reset
• No form cuts the password silently; a maximum, if any, is shown and enforced the same way everywhere
• Caps Lock warning on the web (desktop)
• No autocorrect, autocapitalization or keyboard suggestions in the field
• The password never appears in URLs, logs, analytics or the app switcher
• Toggle and field have a big enough touch area and work with keyboard and screen readers

Example test cases

Accessibility

• A real label: “Password” or “New password”, connected in code. Screen readers announce it as “secure text field” (iOS) or “password” (web, TalkBack) and don’t read the characters aloud.
• The toggle needs a name and a state (WCAG 4.1.2 Name, Role, Value, Level A): “Show password” / “Hide password”, or a pressed state. It should be reachable with TabKeyboard navigationUsing a website with only the keyboard: Tab to move, Enter or Space to activate, Esc to close.Open in glossary → and work with Enter and Space.
  Dev note

  On the web the state is aria-pressed.
• Autofill and paste (WCAG 3.3.8 Accessible Authentication (Minimum), Level AA): don’t make people memorize and retype. Mark the field’s purpose so autofill works (also WCAG 1.3.5 Identify Input Purpose, Level AA).
  Dev note

  With autocomplete.
• Rules and errors are text, linked to the field, and announced. A live checklist should not spam the screen reader on every keystroke; the final state matters.
  Dev note

  Linked with aria-describedby.
• Strength meters must not rely on color alone: show the word (“Weak”, “Strong”) too. Text needs 4.5:1 contrast, the meter bars and field border 3:1 (WCAG 1.4.3 / 1.4.11).
• Touch targetsTouch targetThe area of the screen that responds to a tap, which should be large enough for a finger.Open in glossary →: at least 44×44 pt on iOS and 48×48 dp on Android. On the web, WCAG 2.5.8 (AA) asks for at least 24×24 CSS px; 44×44 px (2.5.5, AAA) is the comfortable target.
• No tight time limits on typing a password; if there is a session timeout, warn before it ends.

Mobile vs web

iOSAndroidWeb

• There’s no built-in reveal button: apps switch between a secure and a normal field, which is exactly where cursor and focus bugs come from.
  Dev note

  UITextField with isSecureTextEntry = true, or SecureField in SwiftUI.
• With Associated Domains, passwords saved for the website appear in the app.
  Dev note

  Set textContentType to .username, .password or .newPassword. Associated Domains use webcredentials:.
• Strong Password suggestions appear on new-password fields and should match the app’s rules.
  Dev note

  They appear on .newPassword fields; passwordRules makes the generated password match the app’s rules.
• The last typed character is shown briefly before it turns into a dot. That’s normal.
• Test with the Passwords app and a third-party manager, VoiceOver, Dynamic Type, and the app switcher (does the screen hide sensitive content?).

Dev note

EditText with inputType="textPassword", or Material TextInputLayout with endIconMode="password_toggle". In Compose, a TextField with PasswordVisualTransformation and a trailing icon button.

• Test with Google Password Manager and a third-party autofill service (Settings › Passwords & autofill).
  Dev note

  Set autofillHints (password, newPassword, username).
• If the spec says so, check that sensitive screens block screenshots and screen recording and are blanked in Recents.
  Dev note

  That’s FLAG_SECURE.
• The “Show passwords” setting makes characters appear briefly while typing.
• Test with TalkBack, font scale, and a hardware keyboard or Chromebook.

Dev note

<input type="password"> with a <label> and autocomplete="current-password" or "new-password". The email field gets autocomplete="username".

• Check the attributes in DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary → (Elements panel): maxlength, autocomplete, onpaste handlers.
• Browsers disable Copy and Cut from masked fields; maxlength silently cuts typed and pasted text.
• Edge adds its own reveal eye; Safari on macOS shows a Caps Lock icon. Test in Chrome, Safari, Firefox and Edge, plus a password manager extension.
• Log in, then use Back and Reload: the password must not reappear in the field or in the URL.

Related pages: the whole login flow, account enumeration and lockout are on Login & sign up, the reset flow on Password reset, and general text input bugs on Text field.

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.Sign-up accepted a 20-character password, but login always says "Email or password is incorrect". What do you suspect first?

   AThe user forgot the passwordBLogin cuts the password to a shorter maximum lengthCThe server is downDCaps Lock

2. 2.The product owner wants to block paste in the password field "for security". What do you say?

   AGood idea, it stops hackersBIt hurts password manager users and pushes people to weaker passwordsCOnly block it on AndroidDBlock copy instead

3. 3.Which autocomplete value belongs on a sign-up password field?

   AoffBcurrent-passwordCnew-passwordDpassword

4. 4.A strength meter rates "Password1!" as Strong. Why is that a bug?

   AIt has too many symbolsBIt is one of the most common passwords, so attackers try it firstCMeters should never say StrongDIt is too long

5. 5.What should a screen reader say on the eye icon next to a password field?

   A"Button"B"Eye"C"Show password, button", then "Hide password"DNothing, it is decorative

Key takeaways

• A password field is a masked text field whose value must be accepted exactly, by every form that touches it.
• Never cut a password silently. Test the same long password (spaces, emoji, accents) on sign-up, login, change, reset, app and web.
• Password managers need current-password / new-password (and the iOS and Android equivalents) and working paste.
• Show/hide needs a name, a state, and must keep value, focus and cursor.
• Show rules up front and be wary of strength meters that only count character types.
• The password never belongs in a URL, log or screenshot.