Short answer: put the launcher in the bottom-right corner unless something important already lives there. Bottom-right is where visitors have been trained to look for help, it keeps the widget out of the reading path, and it sits near the thumb on mobile. The only good reasons to move it are collisions with your own interface elements, right-to-left layouts, or a sticky bar that already owns that corner.
Why bottom-right became the default
Conventions are not arbitrary. Over the last decade, chat launchers settled into the bottom-right corner of the viewport, and that consistency is now an asset. A visitor who wants help does not read your page hunting for a support affordance. They glance at the corner, find a circle, and click it. When you move the launcher somewhere clever, you are spending your visitor's attention to buy nothing.
There is also a layout reason. Western reading paths run top-left to bottom-right, so the bottom-right corner is the last place the eye lands and the least likely to interrupt a headline, a hero image, or a pricing table. A launcher there is present without being pushy.
And there is a hand reason. On a phone held one-handed, the bottom-right corner is inside the natural thumb arc for most right-handed users. A launcher up top means a grip change. That sounds trivial until you watch someone abandon a question because reaching the button was awkward.
When bottom-right is the wrong call
Move the launcher when it collides with something that matters more.
Sticky checkout or booking bars. Ecommerce and restaurant sites often pin an "Add to cart" or "Reserve a table" bar to the bottom of the screen on mobile. A launcher floating on top of that bar covers the single most valuable pixel on your site. Move to bottom-left, or hide the widget on mobile for that template.
Back-to-top buttons and cookie banners. Two floating elements in the same corner produce a stack of circles that looks accidental. Pick one owner for the corner and relocate everything else.
Right-to-left layouts. For Arabic, Hebrew, Farsi and other RTL sites, the reading path mirrors, and so should the launcher. Bottom-left is the correct convention there.
Left-anchored navigation on apps. If your product has a left sidebar with primary actions, a bottom-left launcher merges into it visually. Stay right.
In Clerkzo the corner is a behaviour toggle, not a code change: pick bottom-right or bottom-left in Widget Studio, watch the live preview update, and publish. You can see the whole setup flow on the how it works page.
The offset problem nobody talks about
Corner choice is the easy half. The harder half is spacing. A launcher jammed flush against the viewport edge looks cheap and, worse, on iOS it can drift under the home indicator or the Safari toolbar. Give the launcher breathing room on every side, and give it more room on mobile than on desktop, because the safe area is smaller than it looks.
The second spacing issue is what happens when the panel opens. On desktop, a chat panel typically expands upward and inward from the launcher. If your page has a fixed footer or a promotional ribbon, the bottom of the panel can end up underneath it, hiding the input field. Test with the panel open, not just the launcher closed. The input field is the part that has to be reachable.
Should the widget appear on every page?
No, and this is the placement decision most sites get wrong. Placement is not only where on the screen, it is where in the site.
Pages where a chat widget earns its keep:
- Service and product pages, where visitors have specific questions about fit, price or availability
- Pricing pages, where the objection is usually one clarification away from resolved
- Contact pages, where the alternative is a form and a wait
- Location and hours pages, especially outside business hours
Pages where it usually does not:
- Checkout and payment steps, where any distraction is a risk
- Legal pages, privacy policies and terms
- Long-form blog reading, where a launcher that expands on scroll feels like an interruption
If you are weighing chat against the form you already have, the tradeoffs are laid out in chatbot vs contact form. Short version: they are complements, not rivals, and the widget usually wins on speed while the form wins on structured detail.
Placement and the layers underneath
A floating widget lives on top of your site, which means it participates in your stacking order whether you planned for it or not. Two things go wrong. First, a modal on your site opens underneath the chat panel, so the launcher hovers over your own dialog. Second, your site's CSS leaks into the widget and turns the send button into an unstyled rectangle.
The second problem is the one worth engineering around. Clerkzo renders inside Shadow DOM, which isolates the widget's styles from your page in both directions. Your CSS cannot reach in and break the widget, and the widget's CSS cannot reach out and break your layout. That is why a Clerkzo install is one script tag rather than a stylesheet audit. If the term is new, the embed code glossary entry covers what that single tag actually does.
A short checklist before you publish
- Load the site on a real phone, not just a resized browser, and check the launcher against the thumb arc
- Open the panel and confirm the input field is fully visible and not under a sticky footer
- Scroll to the bottom of a long page and check the launcher does not cover the footer navigation
- Check any sticky bars, cookie notices and back-to-top buttons for corner collisions
- Decide which templates should show the widget at all, and turn it off elsewhere
Frequently asked questions
Is bottom-left ever better than bottom-right?
Yes, in three cases: right-to-left languages, sites with a sticky bottom-right action bar, and sites where another floating element already owns the right corner. Otherwise stay with the convention.
Should the widget show on mobile at all?
Often yes, but not always. If your mobile layout is already dense with sticky elements, hiding the widget on small screens is a legitimate choice. Clerkzo has a hide-on-mobile toggle for exactly this.
Can I put the chat launcher in the header instead?
You can link to it from the header, but the floating launcher should stay in a corner. Header placement scrolls away, and a help affordance that disappears is not much of a help affordance.
How do I stop the widget from covering my cart button?
Change the corner, or hide the widget on the templates where the cart bar appears. Do not try to solve it with z-index alone; that just decides which element wins the fight, not whether the fight happens.
Does placement affect how many people use it?
Placement affects discoverability and comfort, which are prerequisites for use. A launcher nobody can find or reach gets ignored. Beyond that, what drives usage is whether the widget answers well, which is a content problem more than a position problem. See do I need a chatbot for my business for the broader question.