Back to compare picker

Sensitive-data reveal vs Password input vs Input mask vs Typed confirmation vs Permission request

Choose sensitive-data reveal when the value already exists in the product or is being reviewed and users need masked state, reveal action, hide action, hold-to-reveal, timed reveal, reauthentication, partial reveal, full reveal, copy while hidden, clipboard warning, audit event, redaction boundary, shoulder-surfing warning, expired reveal, screen reader announcement, or mobile compact treatment.

Decision dimensions

Dimension Sensitive-data revealPassword inputInput maskTyped confirmationPermission request
UI or UX UI + UX - Controlled reveal and re-hiding of masked sensitive values, secrets, tokens, credentials, identifiers, or private recordsUI + UX - Authentication secret entry controlUI + UX - Fixed-format text entry controlUI + UX - Exact target phrase gate before severe commitUI + UX - Contextual operating-system or browser permission request for device resources, powerful browser features, private user data, or local capabilities
UI guidance Render sensitive-data reveal as a masked value with an explicit reveal action, visible hide action, clear field identity, safe default state, reveal duration or hold behavior, and status feedback that explains what is visible now.Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input.Show a persistent label, visible example or hint, fixed grouping, literal separators, and field-adjacent error text so users understand which characters are typed and which are supplied by the mask.Render a visible non-secret text field inside a destructive or high-consequence confirmation, labelled with the exact target phrase the user must type before the final action enables.Render a permission request as a contextual feature gate that names the resource, user action, immediate benefit, system prompt timing, available choices, and fallback before invoking the OS or browser permission prompt.
UX guidance Use sensitive-data reveal when users need to verify, compare, copy, rotate, recover, or transcribe a sensitive value that is normally masked or redacted.Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.Use an input mask to help users enter data that has a stable character structure, especially when grouping matches the physical document, card, container code, or serial key users are copying from.Use typed confirmation only when reproducing the target phrase meaningfully reduces severe wrong-object or wrong-scope mistakes, such as deleting a repository, project, account, workspace, production dataset, or root credential.Use permission request when a feature needs operating-system or browser authorization for resources such as location, camera, microphone, photos, contacts, notifications, Bluetooth, clipboard, motion sensors, or other powerful features.
Good UI An API key row shows sk_live_****9H2Q by default, requires Reauthenticate before Full reveal, logs the reveal event, and automatically hides after 30 seconds.A sign-in form has Email and Password fields, the password field uses autocomplete current-password, a Show button, no spellcheck, and an account-details error after failed login.A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 before submit.Delete repository acme/payments-api? requires typing acme/payments-api, shows a mismatch until the exact path matches, and then enables Delete repository.A field service app asks for location only when the user taps Start route, explains that current location will verify arrival, then opens the system permission prompt and offers manual address entry if declined.
Bad UI A dashboard shows API keys in plain text by default and copies them to clipboard without warning or audit.A login form uses a normal text field named Password and leaves the secret visible on screen.A phone field hard-codes a domestic mask and rejects valid international numbers.A dialog asks users to type YES before deleting a workspace, so the text does not verify the target object.An app asks for location, contacts, photos, and notifications on first launch before the user knows why any resource is needed.
Good UX A developer needs to rotate a webhook secret, reveals it after step-up verification, copies it with a visible clipboard warning, then sees it auto-hide with an audit ID.A user pastes a generated password from a password manager, toggles Show to inspect one character, hides it again, and signs in without the value appearing later in review or history.A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.A user starts deleting acme/payments-api, mistypes the repository path, sees the mismatch, and cancels before deleting the wrong repository.A user taps Scan receipt, sees why camera access is needed for scanning, grants access, scans the receipt, and can later revoke camera access from settings without losing account access.
Bad UX A user opens billing details in a shared office and the full card number appears automatically with no warning.A user cannot paste from a password manager and shortens the password to something easier to type.A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.A user types DELETE by habit and passes the gate without checking which workspace will be removed.A user denies microphone access and the app loops the same system prompt every time they tap anything in the support screen.
Best fit Users need to inspect, copy, verify, rotate, transcribe, or compare a sensitive value that should normally stay masked or redacted.The user needs to enter an existing password, passphrase, or PIN-like memorized secret.The value has a stable character pattern and users benefit from live grouping.A severe action affects repository, project, workspace, account, production, security, billing, or organization-wide scope.A feature needs operating-system, browser, or device authorization to access location, camera, microphone, photos, contacts, notifications, Bluetooth, clipboard, motion sensors, storage access, or another powerful feature.
Avoid when The task is only entering a password into an authentication form; use password input.The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note.Valid values have many lengths, regions, scripts, or exception formats.The action is routine, reversible, local, or recoverable through undo or trash restore.The decision is consent to optional data use rather than access to a device or browser resource.
Required state Masked state with the field identity, safe suffix or count, and reveal eligibility.Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.Empty untouched state with label and visible format example.No-typed-gate state for actions that do not need target-text escalation.Contextual request state tied to the user action that needs the resource.
Accessibility burden Use a labelled button or toggle whose accessible name includes the field, such as Show API key or Hide account number.Use a visible label that names the password purpose, such as Password or Current password.Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.Associate the input with a label that includes or references the required phrase.Use a labelled region or dialog title that names the resource and feature, such as Allow location for route check-in.
Common misuse Showing sensitive values in plain text by default.Using type text for passwords.Using a mask because a format exists even though many valid values do not fit it.Requiring users to type yes, confirm, or delete instead of the target name.Asking for multiple resources at launch before the user has attempted the relevant feature.

Sensitive-data reveal

UI or UX
UI + UX - Controlled reveal and re-hiding of masked sensitive values, secrets, tokens, credentials, identifiers, or private records
UI guidance
Render sensitive-data reveal as a masked value with an explicit reveal action, visible hide action, clear field identity, safe default state, reveal duration or hold behavior, and status feedback that explains what is visible now.
UX guidance
Use sensitive-data reveal when users need to verify, compare, copy, rotate, recover, or transcribe a sensitive value that is normally masked or redacted.
Good UI
An API key row shows sk_live_****9H2Q by default, requires Reauthenticate before Full reveal, logs the reveal event, and automatically hides after 30 seconds.
Bad UI
A dashboard shows API keys in plain text by default and copies them to clipboard without warning or audit.
Good UX
A developer needs to rotate a webhook secret, reveals it after step-up verification, copies it with a visible clipboard warning, then sees it auto-hide with an audit ID.
Bad UX
A user opens billing details in a shared office and the full card number appears automatically with no warning.
Best fit
Users need to inspect, copy, verify, rotate, transcribe, or compare a sensitive value that should normally stay masked or redacted.
Avoid when
The task is only entering a password into an authentication form; use password input.
Required state
Masked state with the field identity, safe suffix or count, and reveal eligibility.
Accessibility burden
Use a labelled button or toggle whose accessible name includes the field, such as Show API key or Hide account number.
Common misuse
Showing sensitive values in plain text by default.

Password input

UI or UX
UI + UX - Authentication secret entry control
UI guidance
Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input.
UX guidance
Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.
Good UI
A sign-in form has Email and Password fields, the password field uses autocomplete current-password, a Show button, no spellcheck, and an account-details error after failed login.
Bad UI
A login form uses a normal text field named Password and leaves the secret visible on screen.
Good UX
A user pastes a generated password from a password manager, toggles Show to inspect one character, hides it again, and signs in without the value appearing later in review or history.
Bad UX
A user cannot paste from a password manager and shortens the password to something easier to type.
Best fit
The user needs to enter an existing password, passphrase, or PIN-like memorized secret.
Avoid when
The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note.
Required state
Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.
Accessibility burden
Use a visible label that names the password purpose, such as Password or Current password.
Common misuse
Using type text for passwords.

Input mask

UI or UX
UI + UX - Fixed-format text entry control
UI guidance
Show a persistent label, visible example or hint, fixed grouping, literal separators, and field-adjacent error text so users understand which characters are typed and which are supplied by the mask.
UX guidance
Use an input mask to help users enter data that has a stable character structure, especially when grouping matches the physical document, card, container code, or serial key users are copying from.
Good UI
A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 before submit.
Bad UI
A phone field hard-codes a domestic mask and rejects valid international numbers.
Good UX
A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.
Bad UX
A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.
Best fit
The value has a stable character pattern and users benefit from live grouping.
Avoid when
Valid values have many lengths, regions, scripts, or exception formats.
Required state
Empty untouched state with label and visible format example.
Accessibility burden
Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.
Common misuse
Using a mask because a format exists even though many valid values do not fit it.

Typed confirmation

UI or UX
UI + UX - Exact target phrase gate before severe commit
UI guidance
Render a visible non-secret text field inside a destructive or high-consequence confirmation, labelled with the exact target phrase the user must type before the final action enables.
UX guidance
Use typed confirmation only when reproducing the target phrase meaningfully reduces severe wrong-object or wrong-scope mistakes, such as deleting a repository, project, account, workspace, production dataset, or root credential.
Good UI
Delete repository acme/payments-api? requires typing acme/payments-api, shows a mismatch until the exact path matches, and then enables Delete repository.
Bad UI
A dialog asks users to type YES before deleting a workspace, so the text does not verify the target object.
Good UX
A user starts deleting acme/payments-api, mistypes the repository path, sees the mismatch, and cancels before deleting the wrong repository.
Bad UX
A user types DELETE by habit and passes the gate without checking which workspace will be removed.
Best fit
A severe action affects repository, project, workspace, account, production, security, billing, or organization-wide scope.
Avoid when
The action is routine, reversible, local, or recoverable through undo or trash restore.
Required state
No-typed-gate state for actions that do not need target-text escalation.
Accessibility burden
Associate the input with a label that includes or references the required phrase.
Common misuse
Requiring users to type yes, confirm, or delete instead of the target name.

Permission request

UI or UX
UI + UX - Contextual operating-system or browser permission request for device resources, powerful browser features, private user data, or local capabilities
UI guidance
Render a permission request as a contextual feature gate that names the resource, user action, immediate benefit, system prompt timing, available choices, and fallback before invoking the OS or browser permission prompt.
UX guidance
Use permission request when a feature needs operating-system or browser authorization for resources such as location, camera, microphone, photos, contacts, notifications, Bluetooth, clipboard, motion sensors, or other powerful features.
Good UI
A field service app asks for location only when the user taps Start route, explains that current location will verify arrival, then opens the system permission prompt and offers manual address entry if declined.
Bad UI
An app asks for location, contacts, photos, and notifications on first launch before the user knows why any resource is needed.
Good UX
A user taps Scan receipt, sees why camera access is needed for scanning, grants access, scans the receipt, and can later revoke camera access from settings without losing account access.
Bad UX
A user denies microphone access and the app loops the same system prompt every time they tap anything in the support screen.
Best fit
A feature needs operating-system, browser, or device authorization to access location, camera, microphone, photos, contacts, notifications, Bluetooth, clipboard, motion sensors, storage access, or another powerful feature.
Avoid when
The decision is consent to optional data use rather than access to a device or browser resource.
Required state
Contextual request state tied to the user action that needs the resource.
Accessibility burden
Use a labelled region or dialog title that names the resource and feature, such as Allow location for route check-in.
Common misuse
Asking for multiple resources at launch before the user has attempted the relevant feature.
Decision rules
  • Choose sensitive-data reveal when the value already exists in the product or is being reviewed and users need masked state, reveal action, hide action, hold-to-reveal, timed reveal, reauthentication, partial reveal, full reveal, copy while hidden, clipboard warning, audit event, redaction boundary, shoulder-surfing warning, expired reveal, screen reader announcement, or mobile compact treatment.
  • Choose password input when the user is entering a memorized secret into sign-in, login, password reset, or password creation; password reveal helps entry accuracy but the pattern is still the authentication input itself.
  • Choose input mask when the value has a stable visible format such as grouped digits, serial key, date, time, or account field and masking is about structured entry formatting rather than protecting a secret from observation.
  • Choose typed confirmation when users must type a visible target phrase such as a repository name to confirm a destructive action; masking that phrase prevents target verification and confuses it with a secret.
  • Choose permission request when the user is granting OS or browser access to a device resource such as camera, microphone, location, photos, contacts, notifications, Bluetooth, clipboard, or motion sensors rather than revealing a value the product already holds.
  • Use partial reveal when last-four, prefix plus suffix, issuer, domain, or token fingerprint is enough; use full reveal only when policy, role, and task need justify complete exposure.
  • Require reauthentication, role check, reason capture, audit event, or approval before revealing high-risk credentials, recovery codes, API keys, financial identifiers, health identifiers, or customer personal data.
  • A reveal control must have an immediate hide path, and visible values should auto-hide on timeout, blur, navigation, or expired reveal where policy requires it.
  • Copy while hidden must still warn about clipboard exposure and confirm copy without showing the raw value in status text, logs, URLs, analytics, screenshots, or support payloads.
  • A redaction boundary means the full value must not be sent to the client; CSS masking or DOM-only hiding is not enough for users who are not permitted to reveal the value.
Inspect live examples
Failure modes
  • The secret is visible by default, permanently visible after reveal, or revealed automatically on hover, focus, validation, print, export, or blur.
  • The reveal button sits beside an unrelated action and causes accidental disclosure.
  • Copy places the raw secret on the clipboard silently while the interface appears masked.
  • A partial-view user receives the full raw value in the DOM and the UI hides it with styling only.
  • An audit record, console log, URL, analytics event, error message, screenshot, or support payload contains the raw sensitive value.
  • The UI offers Show but no Hide, no timeout, no shoulder-surfing warning, no reauthentication, or no audit event for high-risk values.