Guide · June 17, 2026

Design a compact mobile cookie banner that doesn't block actions

Mobile cookie banner design: compact, unobtrusive, clear Accept/Reject, PDPL-compliant. UX tips and a developer checklist.

consent.vn Editorial6 min read

Quick answer

On mobile, use a bottom-sheet banner occupying about 20–30% of the screen, without covering important content. Place two Accept/Reject buttons with a minimum size of 44 px, plus Options. Block all non-essential cookies/SDKs before the user chooses, and store and honor the choice.

How should a mobile cookie banner be designed?

Use a bottom sheet at the bottom edge, ~20–30% of screen height, short copy (2–3 lines), with three choices: Accept, Reject, Options. Touch targets at least 44×44 px (iOS) or 48×48 dp (Android), with spacing ≥8–12 px to avoid mistaps.

  • Do not cover the full screen, do not block OS back/scroll interactions.
  • Content: main purposes, types of third parties, policy link, Options (granular) link.
  • Do not load non-essential cookies/SDKs before obtaining consent (if you rely on consent as your PDPL legal basis).

How to comply with PDPL without getting in the user's way?

Keep choices clear, easy to tap, and not deceptive. By law, consent must be explicit and demonstrable; to ensure voluntariness, show Accept and Reject with equivalent prominence. Allow continued use of the service when non-essential cookies are rejected.

  • Limit copy to 120–160 characters; use a short title: “We use cookies for analytics and personalization.”
  • Button order: left to right: Reject, Options, Accept (or Accept/Reject side by side); avoid dimming the Reject option.
  • Do not obstruct system gestures (home indicator, navigation bar) — honor the safe area (env(safe-area-inset-*), WindowInsets).

  1. Inventory & classify:

    Audit cookies/SDKs by group: necessary (login, cart), analytics, advertising, additional features. Record vendor, purpose, injection point.

  2. Choose the legal basis:

    For non-essential cookies/SDKs, if relying on consent, do not load before the user chooses. Document the legal basis for each purpose.

  3. Design the banner:

    Use a bottom sheet 20–30% of the viewport height; one-line title; 1–2 line description; “Options” and “Policy” links. Buttons ≥44×44 px; color contrast meeting WCAG AA.

  4. Build the Options panel:

    Allow toggles by purpose (analytics, advertising, etc.). Default to off for purposes requiring consent.

  5. Block loading before consent:

    Gate tag manager/SDK initialization (e.g., dataLayer.consent = false); only initialize when the user Accepts or enables a given purpose.

  6. Capture & store evidence:

    Save timestamp, policy version, choice, device. Provide a way to withdraw consent in Privacy settings.

  7. Test on real devices:

    iOS/Android, small screens, rotation, keyboard open, in-app browsers (Facebook/Zalo). Ensure it doesn't cover CTAs, search bars, or the tab bar.

  8. Monitor & iterate:

    A/B test copy and button placement; measure accept/reject rates without loading new trackers before consent.

Placement, size, Accept/Reject buttons: minimum criteria

Placing it at the bottom edge (bottom sheet) is optimal because it doesn't cover the header and avoids obstructing back gestures. Flexible height 20–30% depending on content density. Buttons must:

  • Minimum size: 44×44 px (iOS), 48×48 dp (Android), spacing 8–12 px.
  • Color/visual prominence balanced between Accept and Reject to reduce “dark pattern” risk.
  • Include an “Options” link to a granular panel; don't hide it behind multiple steps.

Technical tip: use CSS clamp() for height; prefer position: sticky over fixed when the browser has toolbars; respect env(safe-area-inset-bottom) on iOS.

Technical implementation: block SDKs/cookies before consent

The goal is “no load before consent” for all non-essential purposes.

  • Web: configure Consent Mode/CMP API; gate tags in your Tag Manager with consent.purpose == true; use async/defer and check before init.
  • App: delay SDK initialization (analytics/ads) until after the splash screen; read consent state from local storage/secure storage; if absent, show the banner and initialize only when the user chooses.
  • Third-party: with webviews/in-app browsers, set a no-tracking fallback (anonymize IP, don't persist IDs) until consent is obtained.

Mobile patterns to use/avoid

Use:

  • Bottom sheet with a light slide-in, without locking the background; allow the main content to scroll.
  • Short banner + a full “Options” page.

Avoid:

  • Fullscreen modals that require Accept to continue.
  • “Continuing to scroll = consent” — hard to defend as clear, explicit consent.
  • Putting Reject under a secondary menu or dimming it.

Ready-to-use concise copy suggestions

  • Title: “We use cookies for analytics and personalization.”
  • Description: “You can Accept, Reject or choose per purpose via Options. Change at any time in Privacy settings.”
  • Buttons: [Reject] [Options] [Accept]

PDPL compliance: points not to forget

  • The Personal Data Protection Law (Law 91/2025/QH15) takes effect 01/01/2026, upgrading Decree 13/2023/ND-CP. Enforcement authority: Ministry of Public Security (A05).
  • When relying on consent: don't load non-essential cookies/SDKs before consent; allow withdrawal; store evidence of consent and the notice/version.
  • Data subject rights (access, erasure, withdrawal of consent, etc.) must have clear channels in your app/site.
  • Administrative fines per the guiding decree; serious violations may lead to criminal liability.
  • Data breaches must be notified within 72 hours of discovery as required.

Soft CTA: consent.vn provides a banner/mobile CMP, consent evidence storage, and a rights request (DSAR) portal — tailored to Vietnam's SME realities.

Use a bottom sheet taking 20–30% of the screen, offering Accept/Reject/Options with buttons ≥44×44 px, without locking the background, and do not load non-essential trackers before a choice.
By regulation, consent must be voluntary, clear, and demonstrable. Showing Reject alongside Accept helps reduce the risk of being seen as “nudging.” We recommend balanced design and consulting legal counsel for your specific case.
No. “Scroll = consent” is hard to prove as clear and voluntary, especially on mobile. Use explicit buttons or toggles and log the choice.
Group “advertising/identifiers” under Options, default off if relying on consent; only initialize the SDK after the user enables it. Allow withdrawal of consent and disable the SDK on subsequent launches.

Source: the Personal Data Protection Law (Law 91/2025/QH15) (PDPL) https://thuvienphapluat.vn/van-ban/Cong-nghe-thong-tin/Luat-Bao-ve-du-lieu-ca-nhan-2025-559455.aspx; Decree 13/2023/ND-CP https://thuvienphapluat.vn/van-ban/Cong-nghe-thong-tin/Nghi-dinh-13-2023-ND-CP-bao-ve-du-lieu-ca-nhan-769838.aspx; Ministry of Public Security (A05) https://bocongan.gov.vn

Guides

Get started — set up in 5 minutes.

Need help with PDPL compliance?

Get started