Floating Bar
A floating bar is a slim banner that overlays the edge of a page and floats above the content, presenting a persistent call to action without taking over the screen.
Key takeaways
- It overlays the page and reserves no layout space, so nothing shifts.
- Trigger timing decides whether it reads as a prompt or an interruption.
- A transparent overlay region can swallow clicks meant for links beneath it.
- Frequency capping stops readers learning to close it without reading.
- On a phone, a bar covering a third of the viewport is effectively a modal.
In depth
A floating bar is painted above the document rather than placed inside it. It takes no space in the layout, so nothing moves when it appears or leaves; it simply covers whichever strip of the page it occupies. That puts it between a sticky bar, which reserves its own space, and a modal, which blocks everything. Because it is an overlay, its behaviour is governed by stacking order and pointer handling rather than by the rules of document flow.
Timing does most of the work. Fired on arrival, it interrupts a page nobody has read yet. Fired on scroll depth, a dwell timer or exit intent, it arrives when intent already exists and reads as a prompt rather than an intrusion. Frequency is the second lever, since a bar that returns on every page view of every session teaches people to close it reflexively. Against both sits the hidden cost of covering content, which aggregate reporting never shows because the reader who lost a paragraph does not complain.
The build details matter more than the copy. It needs an explicit stacking context so it sits above the page but below any modal, pointer events confined to the visible element so clicks aimed at links beneath are not swallowed, and a focus order that reaches the close control by keyboard. A short entry animation reads as arrival rather than a rendering fault. In a lead funnel it works as an unobtrusive invitation to start a scorecard mid-article, where the reader has context but no commitment yet.
Overlay behaviour is precisely what makes it risky. A transparent region that still captures pointer events blocks links the reader can plainly see, and the failure looks like a broken site rather than an aggressive bar. It is also unreliable where content reflows, since covering a fixed strip is only safe when you know what sits underneath at every width. And on a phone the distinction from a modal collapses: a bar covering a third of the viewport is an interruption whatever it is called.
Example in practice
How to measure it
Measure clicks against impressions where the bar actually rendered, and split the figure by trigger. A scroll-triggered impression and an exit-intent impression describe different states of mind, so averaging them yields nothing actionable. Dismissal rate is the paired number: high dismissal with a decent click rate means the bar polarizes, which is usually acceptable, while high dismissal with few clicks means it is arriving too early.
Then check what it costs. Compare scroll depth and time on page for sessions where the bar fired against sessions on the same pages where it did not, which reveals whether it interrupts reading. Also monitor click rates on links inside the strip it covers. A drop after launch is the clearest evidence that the overlay is intercepting events rather than sitting politely above them.
Common mistakes
The technical mistake is a container sized larger than the visible bar. Invisible padding sits over the page, intercepts pointer events, and links underneath stop responding for reasons no analytics report will explain. Constrain the interactive area to the visible element, disable pointer events on any transparent wrapper, and click every link in the covered strip on a real device after shipping instead of trusting the design file.
The strategic mistake is firing on page load. That spends the interruption before the page has earned any attention, and for a visitor arriving from search it is the first thing they meet. Trigger on scroll depth, dwell time or exit intent instead. The related error is showing it again on every page of the same visit, which turns a useful prompt into background noise dismissed without reading.
Frequently asked questions
How is a floating bar different from a sticky bar?
Both stay in view while scrolling, but a floating bar overlays the page above the content, whereas a sticky bar typically reserves its own space at the edge. The distinction is mostly about layering and whether content shifts to make room.
Can a floating bar use exit intent?
Yes, floating bars are often triggered by exit intent, scroll depth, or a timer so they appear at high-intent moments. This lets you avoid showing the offer too early and annoying fresh visitors.
Will a floating bar block clicks on my page?
It can if it overlays interactive elements without a proper stacking context or pointer settings. Test it carefully so the overlay never intercepts taps meant for buttons or links underneath.
What is the actual difference between a floating bar and a sticky bar?
Layout participation. A sticky bar reserves space, so the page can be padded to account for it and nothing is ever hidden. A floating bar overlays the page and reserves nothing, so it covers whatever is beneath it. The floating version is easier to add to an existing template and easier to get wrong, because what it hides depends on the viewport.
When should a floating bar be triggered?
After the visitor has shown some engagement. Scroll depth past the first section, a dwell timer of a few tens of seconds, or exit intent on desktop all work, and each suits a different page type. Long articles favour scroll depth, pricing and comparison pages favour exit intent, and short pages usually do not need the pattern at all.
Why did links stop working after we added a floating bar?
Almost always because the overlay's container is larger than its visible content and is capturing pointer events across an invisible area. Set pointer events to none on the wrapper and re-enable them only on the bar itself. Check the stacking order too, since a high z-index applied to a full-width wrapper covers far more of the page than the design suggests.
How often should the same visitor see a floating bar?
Once per session is a safe default, and a dismissal should suppress it for days rather than minutes. The value of the pattern comes from feeling like a timely suggestion, and repetition destroys exactly that. Store the dismissal on the visitor's device, and reset it when the offer genuinely changes rather than on a fixed schedule.
Do search engines treat floating bars as intrusive interstitials?
They can, if the bar occupies a large portion of the screen or obscures the main content when a visitor arrives from search. A thin bar triggered partway through a page is a different situation from a full-width overlay shown immediately on load. The safe test is whether the main content is still the dominant element on a phone screen.
How do I make a floating bar accessible?
Put the close control in the keyboard focus order, give it a real label rather than a bare icon, and make sure focus does not become trapped inside the bar. Announce the bar politely rather than interrupting a screen reader mid-sentence, and confirm the contrast of the text against its background meets the same standard as the rest of the page.