Use sensitive-data reveal when a normally masked stored, generated, or displayed sensitive value needs controlled temporary exposure; use password input for entering an authentication secret, input mask for formatting structured entry, typed confirmation for visible target verification before a risky action, and permission request for OS or browser device-resource access.
Use sensitive-data reveal when a normally masked stored, generated, or displayed sensitive value needs controlled temporary exposure; use password input for entering an authentication secret, input mask for formatting structured entry, typed confirmation for visible target verification before a risky action, and permission request for OS or browser device-resource access.
Practice the judgment: Imagine this situation: The secret is visible by default, permanently visible after reveal, or revealed automatically on hover, focus, validation, print, export, or blur. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Sensitive-data reveal | Password input | Input mask | Typed confirmation | Permission request |
|---|---|---|---|---|---|
| UI or UX | UI + UX - Controlled reveal and re-hiding of masked sensitive values, secrets, tokens, credentials, identifiers, or private records | UI + UX - Authentication secret entry control | UI + UX - Fixed-format text entry control | UI + UX - Exact target phrase gate before severe commit | UI + 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 reauthentication dialog asks for Current password, lets the user show it temporarily, accepts a pasted manager value, and clears the field after an incorrect attempt. | 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 secret is visible on page load, print, export, screenshot, or shared-screen mode. | 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. | The typed field is masked like a password, making users unable to check the repository name they entered. | 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. | The person reaches the intended result with clear feedback. | A user submits ABCD 123 and receives a precise error that the six-digit serial group and check digit are incomplete. | A user starts deleting acme/payments-api, mistypes the repository path, sees the mismatch, and cancels before deleting the wrong repository. | A user denies precise location, chooses approximate location instead, and the app still shows nearby pickup points with lower accuracy. |
| Bad UX | A user taps a copied state and the interface silently places a raw token on the clipboard while the token remains hidden on screen. | A failed login page says the password is wrong, confirming that the username exists. | 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 believes typing the phrase is the only safeguard, but the dialog hides forks, members, billing effects, and recovery limits. | 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 task is choosing a new password and needs creation-specific guidance, strength feedback, and blocklist rejection. | 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. | Required phrase state showing the exact target phrase to reproduce. | 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. | Connect hint, format example, canonical-value note, and error text to the input with descriptive relationships where supported. | 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. | Rejecting pasted values that include spaces, dashes, parentheses, or lowercase characters. | 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. |