Back to compare picker

Age gate vs Consent prompt vs Permission request vs Sensitive-data reveal vs Privacy settings vs Cookie banner

Choose age gate when the product must ask for date of birth, age band, declared age, verified age, parent or guardian consent, or age assurance before showing age-restricted content or collecting child data.

Decision dimensions

Dimension Age gateConsent promptPermission requestSensitive-data revealPrivacy settingsCookie banner
UI or UX UI + UX - Eligibility and safety boundary that asks for age, age band, date of birth, verified age, or parent authorization before age-sensitive access, data collection, or content exposureUI + UX - Specific opt-in decision for optional data use, participation, communication, sharing, or trainingUI + UX - Contextual operating-system or browser permission request for device resources, powerful browser features, private user data, or local capabilitiesUI + UX - Controlled reveal and re-hiding of masked sensitive values, secrets, tokens, credentials, identifiers, or private recordsUI + UX - Durable privacy-control surface for account, product, device, app-access, activity, visibility, and sharing settingsUI + UX - Cookie and tracking consent control
UI guidance Render the age gate as a clear eligibility boundary that states why age is needed, what threshold or age band applies, which answer format is required, and what happens next.Render a consent prompt as a focused opt-in decision that names the requester, purpose, data involved, optionality, benefit, consequence of declining, withdrawal route, and consent record before the user chooses.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.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 privacy settings as a returnable control surface with current effective values, privacy categories, data types, app or service access, account/device/product scope, source of truth, managed or unavailable reasons, last updated status, and save or immediate-apply feedback.Render a clearly labelled cookie banner at the top of the document before ordinary page content, with service-specific copy, essential-cookie information, equal accept and reject actions for non-essential purposes, and a link to detailed cookie settings.
UX guidance Use an age gate when the product must adapt, restrict, or verify access because of age-sensitive content, child data protection, app-store rating, regulated features, or parent authorization.Use consent prompt when the product needs the user to knowingly agree to a specific optional data-processing purpose such as marketing, research participation, AI training, personalization, partner sharing, or sensitive-data use.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.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 privacy settings when users need to inspect and change ongoing privacy posture for saved activity, profile visibility, app access, device permissions, data sharing, ad personalization, location, connected apps, or product privacy dashboards.Use a cookie banner to collect or confirm choices for non-essential cookies, local storage, pixels, service-worker storage, analytics, advertising, personalization, or similar device storage technologies.
Good UI A video service asks for date of birth before showing mature content, explains that age is needed for content eligibility, and blocks access without previewing restricted media when the user is under the threshold.A research signup screen asks whether the user consents to being contacted for follow-up interviews, names the research team, shows what contact data is used, offers Yes and No thanks buttons, and links to withdrawal.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.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.An account privacy dashboard groups Saved activity, Profile visibility, Ad personalization, Connected apps, Location history, Device permissions, and Data deletion, with current values, scope labels, last updated times, and unavailable reasons.A service banner says it uses essential cookies and asks to use analytics cookies, with Accept analytics cookies, Reject analytics cookies, and View cookies controls at the same level.
Bad UI A modal asks Are you 18? with the Yes button preselected, no explanation, and mature content visible behind the overlay.A modal says By continuing you agree to personalized offers and partner sharing, with a large Continue button and a small privacy policy link.An app asks for location, contacts, photos, and notifications on first launch before the user knows why any resource is needed.A dashboard shows API keys in plain text by default and copies them to clipboard without warning or audit.A Privacy page links only to a legal policy and has no controls for activity history, public profile fields, personalization, app access, or data sharing.A banner has a large Accept all button and a small Manage settings link but no reject action on the first layer.
Good UX A user enters a birth date, sees that they meet the age threshold for the current region, and can continue without seeing repeated checks during the same signed-in session.A user declines partner sharing and can still complete checkout; the service records no partner-sharing consent and shows how to change the choice later.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.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 pauses saved activity, clears search history for a date range, disables ad personalization, hides birthday visibility, revokes a connected app, and sees which values apply immediately versus after sync.A first-time visitor rejects analytics cookies and the site loads without optional analytics, while essential security cookies remain explained.
Bad UX A user denied by an age check can immediately retry unlimited times until they guess an adult birth year.A user clicks Next to finish onboarding and unknowingly opts into marketing because the consent copy was bundled into the terms paragraph.A user denies microphone access and the app loops the same system prompt every time they tap anything in the support screen.A user opens billing details in a shared office and the full card number appears automatically with no warning.A user turns off location sharing in account privacy settings, but the device-level location permission remains active and the page never explains the split.Reject only closes the banner while ad pixels and analytics continue firing.
Best fit Age or age band controls whether users may access content, features, commerce, community interaction, personalization, or data collection.The product needs a user's active agreement for optional data use, marketing, research participation, personalization, partner sharing, AI training, or sensitive-data processing.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.Users need to inspect, copy, verify, rotate, transcribe, or compare a sensitive value that should normally stay masked or redacted.Users need ongoing control over personal data collection, saved activity, visibility, app access, device permissions, connected services, data sharing, or personalization.The service sets non-essential cookies or similar device storage technologies.
Avoid when The question is whether an eligible user consents to optional data use; use consent prompt.The choice is only about non-essential cookies or device storage; use cookie banner.The decision is consent to optional data use rather than access to a device or browser resource.The task is only entering a password into an authentication form; use password input.The task is a first-time opt-in to one optional purpose; use consent prompt.The service uses only strictly necessary cookies and can explain them on a cookies page.
Required state Age prompt state with reason, threshold, and input format.Pre-consent state with optional processing off and the core task still understandable.Contextual request state tied to the user action that needs the resource.Masked state with the field identity, safe suffix or count, and reveal eligibility.Privacy settings overview with categories and current effective values.First visit with no saved preference.
Accessibility burden Label date, month, year, age band, parent email, verification provider, continue, cancel, correction, and appeal controls with the target threshold or action.Use a labelled region or dialog title that names the consent purpose, not a vague privacy heading.Use a labelled region or dialog title that names the resource and feature, such as Allow location for route check-in.Use a labelled button or toggle whose accessible name includes the field, such as Show API key or Hide account number.Use clear headings, labels, descriptions, and status text for each privacy category and control.Label the cookie banner region with the service name so users know which service is asking for the choice.
Common misuse Preselecting Yes, I am over 18 or styling the adult path as the obvious safe answer.Treating continued use, scrolling, closing, or inactivity as consent.Asking for multiple resources at launch before the user has attempted the relevant feature.Showing sensitive values in plain text by default.Replacing privacy settings with a privacy policy link or legal notice.Accept-only banners.

Age gate

UI or UX
UI + UX - Eligibility and safety boundary that asks for age, age band, date of birth, verified age, or parent authorization before age-sensitive access, data collection, or content exposure
UI guidance
Render the age gate as a clear eligibility boundary that states why age is needed, what threshold or age band applies, which answer format is required, and what happens next.
UX guidance
Use an age gate when the product must adapt, restrict, or verify access because of age-sensitive content, child data protection, app-store rating, regulated features, or parent authorization.
Good UI
A video service asks for date of birth before showing mature content, explains that age is needed for content eligibility, and blocks access without previewing restricted media when the user is under the threshold.
Bad UI
A modal asks Are you 18? with the Yes button preselected, no explanation, and mature content visible behind the overlay.
Good UX
A user enters a birth date, sees that they meet the age threshold for the current region, and can continue without seeing repeated checks during the same signed-in session.
Bad UX
A user denied by an age check can immediately retry unlimited times until they guess an adult birth year.
Best fit
Age or age band controls whether users may access content, features, commerce, community interaction, personalization, or data collection.
Avoid when
The question is whether an eligible user consents to optional data use; use consent prompt.
Required state
Age prompt state with reason, threshold, and input format.
Accessibility burden
Label date, month, year, age band, parent email, verification provider, continue, cancel, correction, and appeal controls with the target threshold or action.
Common misuse
Preselecting Yes, I am over 18 or styling the adult path as the obvious safe answer.

Consent prompt

UI or UX
UI + UX - Specific opt-in decision for optional data use, participation, communication, sharing, or training
UI guidance
Render a consent prompt as a focused opt-in decision that names the requester, purpose, data involved, optionality, benefit, consequence of declining, withdrawal route, and consent record before the user chooses.
UX guidance
Use consent prompt when the product needs the user to knowingly agree to a specific optional data-processing purpose such as marketing, research participation, AI training, personalization, partner sharing, or sensitive-data use.
Good UI
A research signup screen asks whether the user consents to being contacted for follow-up interviews, names the research team, shows what contact data is used, offers Yes and No thanks buttons, and links to withdrawal.
Bad UI
A modal says By continuing you agree to personalized offers and partner sharing, with a large Continue button and a small privacy policy link.
Good UX
A user declines partner sharing and can still complete checkout; the service records no partner-sharing consent and shows how to change the choice later.
Bad UX
A user clicks Next to finish onboarding and unknowingly opts into marketing because the consent copy was bundled into the terms paragraph.
Best fit
The product needs a user's active agreement for optional data use, marketing, research participation, personalization, partner sharing, AI training, or sensitive-data processing.
Avoid when
The choice is only about non-essential cookies or device storage; use cookie banner.
Required state
Pre-consent state with optional processing off and the core task still understandable.
Accessibility burden
Use a labelled region or dialog title that names the consent purpose, not a vague privacy heading.
Common misuse
Treating continued use, scrolling, closing, or inactivity as consent.

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.

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.

Privacy settings

UI or UX
UI + UX - Durable privacy-control surface for account, product, device, app-access, activity, visibility, and sharing settings
UI guidance
Render privacy settings as a returnable control surface with current effective values, privacy categories, data types, app or service access, account/device/product scope, source of truth, managed or unavailable reasons, last updated status, and save or immediate-apply feedback.
UX guidance
Use privacy settings when users need to inspect and change ongoing privacy posture for saved activity, profile visibility, app access, device permissions, data sharing, ad personalization, location, connected apps, or product privacy dashboards.
Good UI
An account privacy dashboard groups Saved activity, Profile visibility, Ad personalization, Connected apps, Location history, Device permissions, and Data deletion, with current values, scope labels, last updated times, and unavailable reasons.
Bad UI
A Privacy page links only to a legal policy and has no controls for activity history, public profile fields, personalization, app access, or data sharing.
Good UX
A user pauses saved activity, clears search history for a date range, disables ad personalization, hides birthday visibility, revokes a connected app, and sees which values apply immediately versus after sync.
Bad UX
A user turns off location sharing in account privacy settings, but the device-level location permission remains active and the page never explains the split.
Best fit
Users need ongoing control over personal data collection, saved activity, visibility, app access, device permissions, connected services, data sharing, or personalization.
Avoid when
The task is a first-time opt-in to one optional purpose; use consent prompt.
Required state
Privacy settings overview with categories and current effective values.
Accessibility burden
Use clear headings, labels, descriptions, and status text for each privacy category and control.
Common misuse
Replacing privacy settings with a privacy policy link or legal notice.

Cookie banner

UI or UX
UI + UX - Cookie and tracking consent control
UI guidance
Render a clearly labelled cookie banner at the top of the document before ordinary page content, with service-specific copy, essential-cookie information, equal accept and reject actions for non-essential purposes, and a link to detailed cookie settings.
UX guidance
Use a cookie banner to collect or confirm choices for non-essential cookies, local storage, pixels, service-worker storage, analytics, advertising, personalization, or similar device storage technologies.
Good UI
A service banner says it uses essential cookies and asks to use analytics cookies, with Accept analytics cookies, Reject analytics cookies, and View cookies controls at the same level.
Bad UI
A banner has a large Accept all button and a small Manage settings link but no reject action on the first layer.
Good UX
A first-time visitor rejects analytics cookies and the site loads without optional analytics, while essential security cookies remain explained.
Bad UX
Reject only closes the banner while ad pixels and analytics continue firing.
Best fit
The service sets non-essential cookies or similar device storage technologies.
Avoid when
The service uses only strictly necessary cookies and can explain them on a cookies page.
Required state
First visit with no saved preference.
Accessibility burden
Label the cookie banner region with the service name so users know which service is asking for the choice.
Common misuse
Accept-only banners.
Decision rules
  • Choose age gate when the product must ask for date of birth, age band, declared age, verified age, parent or guardian consent, or age assurance before showing age-restricted content or collecting child data.
  • Choose consent prompt when an eligible user is deciding whether to allow a specific data use, message, sharing action, or optional feature; consent does not prove age eligibility.
  • Choose permission request when the operating system, browser, workspace, or product needs access to a device capability, account resource, location, camera, microphone, file, or contact list.
  • Choose sensitive-data reveal when the user is already allowed to see hidden information and needs a deliberate reveal, masking, timeout, or audit treatment.
  • Choose privacy settings when the user manages durable account, profile, tracking, visibility, data sharing, or child privacy defaults after eligibility is established.
  • Choose cookie banner when the immediate decision is about cookies, tracking, analytics, personalization, or advertising technologies, not age eligibility.
  • An age gate must state why age is needed, which age threshold applies, whether exact birth date or age band is enough, what happens to underage users, and what parent or appeal route exists.
  • Use data minimization: do not ask for more age evidence than the risk needs; a low-risk content filter may need an age band, while regulated mature content may need stronger age assurance or verified age.
  • An underage result should block or adapt access without leaking restricted content, trapping the user in a retry loop, or encouraging them to lie.
  • Keep age gate state separate from legal acceptance, account creation, marketing consent, cookie choice, and device permission so users can understand which requirement stopped them.
Inspect live examples
Failure modes
  • The form asks only Are you over 18? with Yes highlighted, then shows restricted content before checking the answer.
  • The product collects full ID documents for a low-risk age-band decision and gives no deletion or data-minimization explanation.
  • An underage user is denied with no child-safe alternative, parent route, or explanation of the threshold.
  • A parent consent step is labeled as consent to all tracking, subscriptions, and marketing rather than age-related authorization.
  • The UI treats a denied camera permission as an age gate failure, hiding the real recovery route.
  • The age gate remembers a failed answer forever with no correction, appeal, session refresh, or support path.