Short answer: on mobile a chat widget has to survive three things a desktop widget never meets: a keyboard that eats half the screen, a viewport that changes height as browser chrome collapses, and a thumb that can only comfortably reach the bottom third. Get those right and the rest is styling.
The keyboard is the whole problem
When a visitor taps the message input on a phone, the on-screen keyboard appears and the usable viewport shrinks by roughly half. A widget that has not planned for this does one of two things, both bad. It keeps its original height and pushes the input field off the bottom of the screen, so the visitor is typing blind. Or it repositions clumsily and the conversation history jumps, so the visitor loses their place mid-sentence.
The correct behaviour is boring and specific: the input field stays pinned above the keyboard, the most recent message stays visible, and the scroll position does not leap. Anything else feels broken even if nothing is technically broken.
Related failure: iOS Safari and Chrome on Android both resize the visible viewport as their toolbars hide and show during scroll. A widget sized to a fixed pixel height gets clipped or leaves a strip of page showing at the bottom. Sizing needs to follow the actual visible viewport, not a number measured once at load.
Safe areas are not optional
Modern phones have rounded corners, notches, and a home indicator bar at the bottom. Content placed flush to the edge of the screen gets clipped or sits underneath system UI. A launcher that looks perfectly placed in a browser devtools emulator can end up half-swallowed by the home indicator on a real device.
The fix is respecting the device's safe area insets so the launcher and the panel edges pad themselves away from system furniture. This is one of those things you cannot verify in a simulator you resized by hand. Load your site on an actual phone, in actual Safari, and look.
Tap targets and the thumb arc
A chat launcher needs to be large enough to hit without aiming. Roughly 44 to 48 pixels square is the accepted floor for a touch target, and a launcher should be comfortably above that floor because it is a primary action, not a footnote.
Inside the panel, the same rule applies to everything interactive: the send button, the close button, suggested question chips, and any handoff link. Suggested questions are the ones people get wrong most often, because they are styled like text and end up with a tap area the height of a line of copy. If a chip is worth showing, it is worth making tappable at a glance.
Position matters as much as size. The bottom-right corner sits inside the natural arc of a right thumb on a one-handed grip. A close button in the top-right of a full-height panel requires a grip change, which is why a swipe-down or tap-outside dismissal is worth having alongside the button.
Full screen or floating card?
On desktop, a chat panel is a card floating over your page. On mobile, that card has nowhere to float. Two reasonable approaches:
Near-full-screen panel. The widget takes over most of the viewport when opened. Maximum room for the conversation, clearest reading, easiest typing. The cost is that your page disappears, so the dismissal affordance has to be obvious.
Tall floating sheet. The panel covers most but not all of the screen, leaving a sliver of page visible at the top. This keeps context and makes dismissal intuitive, at the cost of some conversation height.
Either works. What does not work is scaling the desktop card down proportionally and calling it responsive. A 320-pixel-wide chat panel on a 390-pixel-wide phone wastes the screen and produces a message column so narrow that every reply wraps into a tower.
The sticky bar war
Ecommerce sites pin "Add to cart" to the bottom. Restaurants pin "Book a table". Local services pin "Call now". All of them live exactly where a chat launcher wants to be.
You have three honest options and one dishonest one. The honest ones: move the launcher to the opposite corner, raise the launcher above the sticky bar with extra bottom spacing, or hide the widget on the templates where the bar appears. The dishonest one is stacking them and hoping nobody notices, which produces a cluttered bottom edge and a launcher that intercepts taps meant for your checkout button.
Clerkzo covers the first and third natively: corner position and hide-on-mobile are both behaviour toggles in Widget Studio, with a live preview so you can see the result before publishing. Details on the setup flow are on how it works.
Performance on a phone is not performance on a laptop
Mobile visitors are frequently on slower connections and slower silicon. A widget that adds visible weight to the page is more punishing here than anywhere else. The right pattern is a launcher that loads light and defers the heavy work until someone actually opens the chat. Most visitors never open it, and they should not pay for it.
The related mobile-only mistake is animation. Elaborate entrance animations that look smooth on a desktop GPU stutter on a mid-range phone. Keep motion short and simple, and honour the reduced-motion preference for visitors who have asked their device to calm down.
Typing, autocorrect and the send key
Small details that decide whether a mobile conversation feels natural:
- The input should be a real multi-line text field, so a longer question does not scroll horizontally in a single-line box
- The keyboard's return key should send or newline predictably, not both depending on the browser
- Autocapitalisation and autocorrect should behave like they do in a messaging app, because that is the mental model
- Font size in the input should be at least 16 pixels, or iOS will zoom the whole page when the field focuses, which is jarring and hard to undo
That last one is a classic. A 14-pixel input feels tidy in a design file and triggers an involuntary page zoom on every iPhone that touches it.
What mobile changes about content
Screen size changes reading behaviour. Long paragraphs that scan fine on a laptop become walls on a phone. Chat replies should be short by default, with detail on request. Suggested questions matter more on mobile because typing is expensive, so a well-chosen set of taps can carry a visitor to an answer without a single keystroke. If lead capture is the goal, keep the ask to the minimum fields; the case for that is in lead capture chatbot.
Frequently asked questions
Should I hide the chat widget on mobile entirely?
Only if your mobile layout is already crowded with sticky elements, or if your mobile traffic converts through a phone call instead. Most sites are better off keeping it, since mobile visitors are the ones least likely to fill in a long form.
What size should the launcher be on a phone?
Comfortably above the 44 to 48 pixel touch-target floor, with real spacing from the screen edges so it clears the home indicator.
Why does my page zoom when someone taps the chat input?
The input font size is under 16 pixels. iOS zooms to make small text legible. Raise the font size and the zoom stops.
How do I test this properly?
On real devices. Resizing a desktop browser does not reproduce keyboards, safe areas, collapsing toolbars, or touch accuracy. Borrow an old mid-range Android too, not just a current iPhone.
Does the widget interfere with my site's mobile CSS?
It should not. Clerkzo renders inside Shadow DOM so styles cannot leak in either direction. More on what that means in the website chat widget glossary entry.