Adding Live Chat To Webflow Without Ruining The Design

The Very Specific Webflow Problem

Webflow people care about design. That is basically the whole reason to use Webflow. You spent three weeks getting the spacing right on a hero section, you argued with yourself about a font pairing, you built custom interactions that trigger on scroll.

Then you install a chat widget and a bright green bubble appears in the corner with rounded corners that do not match anything else on the page, a font that is not your font, and a shadow that belongs in 2014.

It is genuinely deflating. All that care, undone by a corner bubble you cannot restyle because it lives inside an iframe you do not control.

So this guide is about two things. Getting chat working on Webflow, which takes about five minutes, and getting it to not look like an intruder, which is the part most tutorials skip entirely.

First, Webflow Has No Native Chat

Let us clear this up because people search for it constantly.

Webflow does not have a built in live chat feature. There is no toggle. There is no official Webflow Chat product. Forms, yes. Chat, no.

Every single option involves pasting third party code into your site. That is not a limitation so much as a design decision, and honestly it is the right one. Webflow is a design and hosting tool, not a customer support platform.

What it does mean is that your choice of chat tool matters more than it would elsewhere, because you are inheriting whatever that vendor decided your site should look like.

The Actual Install, Step By Step

This takes five minutes. Genuinely.

Step one. Get your embed snippet from whichever chat tool you picked. It will look roughly like this.

<script src="https://cdn.tglivechat.com/w.js" data-id="YOUR_WIDGET_ID" async defer></script>

Step two. In Webflow, open your project and go to Site Settings. Not page settings. Site settings, the one with the gear icon at project level.

Step three. Find the Custom Code tab. You will see two boxes. Head Code, and Footer Code, which is labelled something like "Before body tag".

Step four. Paste your snippet into the Before body tag box. Not the head box. This matters, and I will explain why in a second.

Step five. Save, then publish. This is the step everyone forgets. Custom code does not render in the Designer, and it does not render in preview mode. You have to publish to a domain, even the staging webflow.io one, before you will see anything.

Then load the published site and your bubble should be sitting in the corner.

Why Before Body And Not Head

Quick detour into why this matters, because it is the difference between a fast site and a sluggish one.

Scripts in the head load before the page content. The browser stops, fetches your chat widget, parses it, and only then carries on building the page your visitor came to see. On a slow connection that is a visible delay on a blank white screen.

Scripts before the closing body tag load after the content exists. Your design paints first, then chat quietly turns up.

Since nobody has ever opened a chat widget before the page finished loading, there is zero benefit to putting it in the head and a real cost. Use the footer box. Always.

While we are here, keep the async and defer attributes if your vendor provides them. They tell the browser it is allowed to get on with other work instead of waiting.

If You Are On A Free Webflow Site

Bad news, mostly. Custom code in site settings requires a paid site plan.

There is a workaround, which is to drop an Embed element onto the page in the Designer and put the script inside it. It works. But you have to place it on every single page individually, and if you add a page later you will forget, and then chat is missing from your new landing page for two months before anybody notices.

My honest advice, if the site matters enough to have live chat on it, it matters enough for a site plan. If it does not, use the Embed element and set a reminder to check it.

The Part Everyone Skips, Making It Look Right

Right, this is the actual Webflow specific bit.

Most chat widgets give you a colour picker and that is it. You get to choose the shade of blue for a bubble whose shape, font, corner radius and animation were all decided by somebody else. On a template site that is fine. On a carefully designed Webflow site it sticks out badly.

A few things worth doing.

Match the corner radius, not just the colour

This is the detail that gives it away more than colour does. If your buttons and cards use a 4 pixel radius and the chat window uses 16, it reads as foreign immediately. Pick a chat theme with a radius close to your design system, or one that lets you set it.

Pick a theme, not a colour

If your widget offers proper themes rather than a single colour swap, use them. We ship 32 of them for exactly this reason, ranging from frosted glass through to flat and minimal, because a widget that suits a brutalist portfolio is wrong for a wellness brand. Match the mood of the site rather than trying to force one default shape into every context.

Think about where it sits

Bottom right is the default because it is the default. If your Webflow site has a sticky element bottom right, a cookie banner, or a back to top button, the bubble will collide with it on mobile. Move it or move the other thing. Check on an actual phone, not a browser resize.

Consider not showing it everywhere

A chat bubble on a landing page makes sense. On a portfolio case study where you want people reading, it can be a distraction. Most widgets support hiding on specific pages, and it is worth thinking about rather than defaulting to everywhere.

Why Some Widgets Break On Webflow Sites

A technical aside that explains a class of weird bugs.

Webflow generates a lot of CSS, including some fairly assertive global rules. If a chat widget just dumps its HTML onto your page, your site styles will leak into it. Symptoms look like this. Text in the chat window inherits your body font at the wrong size. Buttons lose their padding. The whole thing is subtly broken in a way that is very hard to debug because it looks fine on the vendor's demo site.

The fix, from the widget side, is Shadow DOM. It creates a boundary that page CSS cannot cross, so the widget looks the same on every site regardless of what the host page is doing. Ours mounts in Shadow DOM and we wrote a longer piece about why if you want the detail.

When you are evaluating a widget, load it on a page with aggressive CSS and see what happens. If it survives, it is isolated properly.

Now The Bigger Question, Who Answers

Here is where most Webflow chat setups quietly fail, and it has nothing to do with code.

Webflow sites are very often built by one person. A freelancer, a designer, a small studio, a founder who taught themselves. That person is not sitting at a desk watching a support dashboard. They are in Figma, or on a call, or at a client meeting, or asleep.

So you install chat, three people message you in the first fortnight, you reply to all of them, you feel good. Then you get busy with a project for three weeks and stop checking. A month later there are five unread messages and two of them were people asking about hiring you.

I have done this. It is genuinely painful when you find them.

The fix is not discipline. Discipline does not scale and you will lose. The fix is putting messages somewhere you already look constantly. For a lot of people that is Telegram, which is the whole idea behind what we built. Visitor types on your Webflow site, message arrives in your Telegram, you reply from your phone in the same app where your friends are sending you memes, and the reply appears in the widget.

No dashboard. No new habit. Just a notification in a place you already respond to.

Whatever tool you choose, apply this test before you install anything. When somebody messages my site at 8pm on a Sunday, what physically happens, and will I actually see it?

Things That Go Wrong

Widget not appearing. Did you publish? Custom code never shows in Designer or preview. Publish first, then check the live URL.

Still not appearing after publishing. Open in an incognito window. Ad blockers hide a lot of chat widgets, and if you are a person who has an ad blocker you will confuse yourself for twenty minutes.

Appears on some pages only. You probably used an Embed element on one page rather than site wide custom code. Move it to Site Settings.

Overlapping something on mobile. Check for sticky footers, cookie banners and back to top buttons. Test on a real device.

Site got slower. Open DevTools, Network tab, filter to JS, and see how big the widget is. Some are 500 kilobytes and up. If yours is one of those, no amount of clever loading fixes it and you want something lighter.

Works on the staging domain but not the live one. Almost always a domain restriction set to one origin. Add both, or update it when you go live and remember it exists.

Interactions stopped working after adding it. Rare, but if a widget is not properly isolated it can collide with Webflow interactions on scroll or hover. Test with the widget removed to confirm it is the culprit before you spend an hour rebuilding an animation that was fine all along.

The Short Version

Site Settings, Custom Code, Before body tag, publish. That is the install and it takes five minutes.

The part worth thinking about is everything after. Pick something that matches your design rather than fighting it, keep it light so it does not undo your performance work, and make absolutely sure the messages land somewhere you will genuinely see them.

Webflow Specific Things That Catch People

A few quirks that only show up on Webflow and will waste your afternoon if you do not know about them.

Staging versus production

Your webflow.io staging domain and your real domain are different origins. If your chat tool has a domain restriction setting, and it should for security reasons, you need to allow both or the widget will silently refuse to connect on staging. The symptom is confusing, because the script loads fine and the bubble may even appear, but nothing sends.

Localisation

If you use Webflow Localization, custom code in site settings applies across locales. That is usually what you want, but it means your chat greeting is in one language while the page is in another. Most widgets have a language setting, and some let you pass it per page, which is worth setting up properly if you are running multiple locales rather than leaving everyone with English.

Handing the site to a client

This is the one that bites agencies. If you built the site under your own Webflow account and later transfer it, custom code goes with the site, which is fine. But the chat account is yours, not theirs. Decide early whose account owns the widget, because migrating a widget after handover means the client loses conversation history or you keep paying for their tool forever.

The cleanest approach is to set up the chat account in the client's name from the start, add yourself as a collaborator, and remove yourself at handover. Slightly more admin on day one, dramatically less awkward in month six.

The Designer preview trap

Worth repeating because people lose real time to it. Custom code does not run in the Designer or in preview mode. If you are testing changes and seeing nothing, you almost certainly just need to publish. There is no way around this and it is not a bug.

A chat widget nobody answers is worse than no chat widget at all. At least with no widget, people email you.