Exit Intent Pop-ups: How They Work and Why They Convert
The detection method, what it cannot detect, and the mobile equivalent that is not really the same thing.
On this page
The short version
- It fires when the cursor leaves through the top of the viewport, which is a proxy for the tab bar and the address bar rather than for leaving.
- It cannot work on mobile. There is no cursor, and every mobile substitute is measuring something else entirely.
- It is the cheapest pop-up to justify, because the visit was ending anyway — which also caps how much it can ever be worth.
Exit intent is the one pop-up trigger with a defensible ethical position: it fires as the visit ends, so the interruption costs the reader nothing they were about to spend anyway.
It is also more limited than it is usually presented as being, and understanding the mechanism explains both the appeal and the limits.
How the detection works
The page watches the cursor. When it crosses the top edge of the viewport at sufficient speed, the reader is assumed to be heading for the tab bar, the address bar, the back button or the close control. That is the whole mechanism.
What it cannot detect
A great deal. Someone switching tabs with a keyboard shortcut. Someone closing the window with a shortcut. Someone moving to another monitor. Someone simply stopping reading and walking away. Someone reaching for the top of the screen for a reason that is not leaving — a bookmark, a different tab they mean to come back from.
The last of those is the false positive, and it is the reason exit intent should still respect a frequency cap. A reader who checked another tab and returned to find a pop-up waiting has been interrupted mid-visit by something claiming to have detected the opposite.
What each exit route triggers
| How they leave | Detected? |
|---|---|
| Cursor up to the tab bar or address bar | Yes |
| Cursor up to the back button | Yes |
| Keyboard shortcut to close or switch tab | No |
| Clicking a link away from the site | No |
| Switching applications | No |
| Stopping reading and leaving the tab open | No |
| Anything at all on a phone | No |
What to put in it
The visitor is leaving, so this is not the moment for a considered offer. It works best with something immediate and specific: the article's own content upgrade, a single checklist, a one-question ask.
A general newsletter subscription performs poorly here, because the reader is in the act of disengaging and being asked for an ongoing commitment. A concrete thing they can have now performs much better.
Discounts perform best of all and carry the usual cost: a reader who learns that leaving produces a discount will leave again.
Sensible settings
Require some engagement before it arms — a scroll depth or a time threshold — so a visitor who arrived at the wrong page and immediately left does not get an offer for content they never read.
Fire once per visitor per few weeks, not once per session. Add a small delay after arming, because a cursor crossing the top edge in the first seconds is usually someone still orienting.
And do not use it alongside another pop-up. Two interruptions in one visit is the arrangement that produces complaints, and the second one lands on a reader who already said no.
Exit intent check
- Requires engagement before arming
- Fires once per visitor per few weeks
- The offer is immediate and concrete, not an ongoing subscription
- No mobile equivalent is pretending to be exit intent
- The back button is never intercepted
- It is the only interruption on the page
- Existing subscribers are excluded
Frequently asked questions
Does exit intent still work, or have people learned to ignore it?
It still converts better than arrival-triggered overlays on most sites, largely because the reader is not being interrupted mid-task. Familiarity has reduced the effect rather than removed it.
Should I use it on a checkout or form page?
Carefully. On a checkout, an exit-intent offer can rescue an abandonment; it can also distract someone who was about to buy. If you try it, restrict it to people who have been on the page long enough to have stalled.
What about intercepting the back button on mobile?
Do not. It overrides a control the reader pressed deliberately, some browsers actively work against it, and it is the single most resented pattern in this category.