Consent Banners on Small Screens: When Truncated Choices Stop Being Choices

Published 2026-10-16

Most consent banners are designed on a desktop monitor and approved in a desktop review. Most visitors meet them on a phone. Between those two screens the banner changes character: the text truncates, the buttons stack into a column, the settings link drops below the fold, and the whole panel can cover the page so completely that the only visible action is the bright accept button. The recorded consent looks identical in the log. The choice behind it was not.

Small screen consent is not a cosmetic issue. Regulators judge whether a choice was freely given and informed, and both tests are applied to what the visitor actually saw. This guide covers the failure modes that appear only on phones, and the checks that catch them before a complaint does.

The truncation problem

Banner copy is usually written to a character budget set by the desktop layout. On a narrow screen the same panel wraps that copy into a tall stack, and many designs quietly cap the visible text, cutting the sentence that explains what advertising cookies do or hiding the link to the full policy. A visitor who cannot read what a category means cannot consent to it in any informed sense. Test the banner at the smallest common viewport, read what is actually visible without scrolling inside the panel, and shorten the copy until the essential meaning survives at that size. If the meaning needs the policy page to make sense, the banner text is doing too little work.

Button stacking and the vanishing reject

Desktop banners place accept and reject side by side. Stacked vertically on mobile, order becomes emphasis: whichever button renders first and in the accent color collects the taps. Designs that put accept first, in filled color, and reject second, in faint text, are steering, and steering is exactly what dark pattern guidance prohibits. The fix is boring and effective: same size, same visual weight, adjacent positions, and wording of equal clarity. Reject all should never require opening a settings layer that accept does not. If your mobile banner needs a scroll to reveal the reject path, the layout has already made the decision for the visitor.

Panels that cover the page

A mobile banner that covers ninety percent of the screen creates a hostage situation: interact with the banner or leave. Some of that is unavoidable on small screens, but the panel should still be dismissible in a way that defaults to no tracking, and it should never trap the visitor in a loop where closing the panel reopens it on the next page. Check the behavior in a real device session, including landscape orientation and the largest text size setting, where banners routinely break. Accessibility text scaling is not an edge case; a meaningful share of visitors use it, and a banner that falls apart at large text fails them first.

Testing like a visitor, not a reviewer

Build a small device checklist and run it monthly: smallest phone viewport, largest text, slow connection, and a clean profile. Record how many taps each outcome takes, accept, reject, and custom settings, and whether the record written matches the choice made. Screenshot the banner at each state, because the screenshots are what an audit conversation will be about. Teams that keep dated mobile screenshots next to their consent records answer complaints in minutes. Teams that only ever reviewed the desktop banner discover, during the complaint, what their visitors had been seeing all along.

Related reading

These earlier guides cover connected questions in more depth: How to Handle Consent When a Visitor Uses Multiple Devices, Consent Records Retention: How Long to Keep Proof and What to Store, and Consent Mode Signals When a Visitor Declines: What Your Tags Should Actually Do.

Frequently asked questions