Mobile is where consent quietly breaks

Most of your traffic is probably on a phone, but most cookie banners are still designed on a desktop monitor where there's room to breathe. Shrink that same banner to a 390-pixel-wide screen and the cracks show: the reject button slides off the visible area, the text runs to six lines, the buttons sit too close to tap accurately. Recent benchmark data suggests desktop and mobile consent rates end up similar when both banners give the two choices equal visibility. A lot of mobile banners don't, and that gap is where consent leaks.

This guide covers the mobile-specific decisions: touch targets, layout, viewport, and the reject-button trap. For the performance side of mobile banners (layout shift, script weight), see cookie banners and Core Web Vitals.

Touch targets: build for a thumb, not a cursor

A mouse pointer is a single pixel. A thumb is roughly a centimeter of soft contact area, and it misses small targets. The platform guidance converges on the same range: Google's Android accessibility guidance recommends touch targets of at least 48 by 48 density-independent pixels, Apple's Human Interface Guidelines recommend 44 by 44 points, and WCAG 2.2's Target Size (Minimum) criterion sets a floor of 24 CSS pixels with adequate spacing. For consent buttons, aim for the higher end. Undersized targets produce mis-taps, and a mis-tap on a consent banner means someone accepted or rejected by accident, which isn't a valid choice.

Give the buttons breathing room too. Google recommends at least 8 pixels of spacing between adjacent targets. "Accept" and "Reject" jammed edge to edge invites fat-finger errors, and if those errors skew toward "accept" you've built an accidental dark pattern.

The reject-button trap

The most common mobile compliance failure is putting "Accept all" on the first screen and burying "Reject all" behind a "Manage preferences" tap. On desktop that's already a problem. On mobile it's worse, because vertical space is scarce and it's tempting to show one button and hide the rest. Regulators don't grant a mobile exception. The EDPB and national authorities treat equal ease of accepting and rejecting as a hard requirement, screen size included. If "Accept all" is one tap, "Reject all" has to be one tap too.

When you can't fit two full-width buttons plus a manage link comfortably, stack them: "Reject all" and "Accept all" as two equal buttons, on one row or as two full-width rows, with "Manage settings" as a smaller text link below. Both primary choices stay one tap away.

Layout for small screens

Anchor to the bottom. A bottom sheet sits in the natural thumb zone, the lower third of the screen that's easy to reach one-handed. A top banner forces a stretch and competes with the browser chrome.
Respect the safe area. On iPhones with a home indicator and on Android phones using gesture controls, the very bottom strip is reserved. Use the CSS safe-area-inset values so your buttons don't sit under the system gesture bar where taps get swallowed.
Cap the height. A banner that eats 60 percent of a phone screen reads as a wall. Keep the first layer short: headline, one sentence, two buttons, a settings link. Push detail into an expandable layer.
Don't trap the scroll. If the banner is a modal, make sure the visitor can scroll its own content on a short screen. Purpose toggles you can't reach because they're below the fold and the modal won't scroll is a real bug that tanks completion.

Type and contrast that survive sunlight

People use phones outdoors, one-handed, in a hurry. Set body text at 16 pixels or larger so mobile Safari doesn't zoom the viewport on focus and so it's readable at arm's length. Keep contrast well above the WCAG AA minimum (4.5:1 for body text). And apply the same contrast to both buttons. A common dark pattern is a bright, high-contrast "Accept" next to a washed-out grey "Reject," which the EDPB explicitly calls out. Equal visual weight isn't optional here, it's the compliance line.

One more mobile detail people skip: honor the visitor's own text-size setting. Some users bump their system font up for readability, and a banner with fixed pixel heights and no room to grow will clip its own buttons or hide the reject option when the text reflows. Let the container expand with the content, and re-check that both buttons stay reachable at larger text sizes.

Test on real conditions, not a resized browser

Chrome's device emulator is a starting point, but it won't show you what a thumb does or how the banner behaves on a slow connection where the script arrives late. Check the real thing:

Can you reach both buttons one-handed on a large phone?
Does the reject button stay on screen without scrolling?
Do the buttons clear the iOS home indicator and the Android gesture bar?
On a throttled connection, does the banner appear without shoving content around when it loads? (That layout shift hurts both UX and your Core Web Vitals.)

The mobile takeaway

Mobile doesn't need a different compliance standard. It needs a design that holds up when the screen shrinks. Equal, thumb-sized, well-spaced buttons with the reject option visible on the first screen will out-convert a cramped desktop banner squeezed onto a phone, and it keeps you on the right side of the regulators at the same time. CookieBeam renders a single responsive banner that adapts to the viewport and keeps accept and reject at equal prominence across devices, so you're not maintaining a separate mobile design or hoping a desktop layout survives the shrink. To read where mobile and desktop diverge in your own numbers, see how to measure your banner's performance.