Prepared Docs

Prepared Docs

⌘K

    Loading navigation…

User

  1. Components
  2. Secret
  3. Usage

Secret

Usage

Overview

Secret renders sensitive material (API keys, webhook signing secrets, integration tokens) with masking, controlled reveal, and a copy action. It belongs in admin surfaces where operators verify or rotate credentials. The mental model is "this value is dangerous by default; the operator must opt in to see it, and the action is audited". Aligns with security UX basics: minimize exposure, log access server-side, and never let secrets leak into client analytics or support screenshots.

When to use

  • Settings screens where operators must verify, copy, or rotate credentials.
  • Support flows needing fingerprint verification (last-four style) without exposing the full secret casually.
  • Read-only display of a rotated secret immediately after creation, paired with a copy action.

When not to use

  • Password entry during authentication—use the Input password pattern.
  • Public or unauthenticated pages—secrets should never ship to unauthorized sessions at all.
  • High-traffic feeds where copy actions could leak via shoulder-surfing without additional gates.

Variants

VariantPurposeEmphasis
Full maskHide every character until explicit revealDefault for highest-risk secrets
Fingerprint (last-four)Allow verification without full exposureUse for "is this the right key?" workflows
Reveal-then-copyExpose briefly for verificationCollapse on navigation; never persist revealed state

Content guidelines

  • Labels explain scope ("Signing secret for Integration X", "Webhook key: Training"). Localize with formatMessage.
  • Put rotation instructions adjacent to the control, not behind an external docs link operators won't follow mid-task.
  • Never describe the secret's contents or length in helper text ("A 64-character hex string…") unless the verification task requires it.

Behavior and states

  • Copy. Confirm success without echoing the secret in a toast that might be logged. A generic "Copied" is safer than "Copied abc123…".
  • Reveal. Require explicit intent (a click or unmask toggle). Rate-limit the toggle if abuse is a concern in the deployment.
  • Masked state persistence. Default to masked on every navigation. Never leave a secret revealed across routes.

Best practices

Do

  • Pair the UI with server-side audit logging for view and copy events in regulated deployments.
  • Default to masked and require an explicit action to reveal.
  • Rotate secrets through a confirmation flow that names the integration and its blast radius.

Don't

  • Render secrets in error overlays, screenshots, or shared URLs.
  • Store the revealed state longer than necessary. Collapse on navigation, route change, or idle timeout.
  • Echo the value back in copy-success toasts or analytics events.

Accessibility

Screen reader users should understand when content is masked vs. revealed without broadcasting the value itself via a loud live region. Copy buttons need specific names ("Copy API key") instead of generic "Copy". See Accessibility for the full contract.

Related Components

  • Input for editable secrets during entry.
  • Callout for rotation warnings and security notices.
  • Data list for read-only secret rows inside a larger profile.

Previous

Radio Cards / Accessibility

Next

Secret / API and Development

On this page

Overview
When to use
When not to use
Variants
Content guidelines
Behavior and states
Best practices
Accessibility
Related Components