If you have ever compared notes with another MyLiveChat user and found that their dashboard offers a setting yours does not, or that their chat window looks different from yours, you have run into widget generations. It is not a plan difference and it is not a bug. The widget your visitors load is a property of your account, and accounts keep the generation they were created with.
This surprises people because most web software updates itself. A hosted product usually rolls everyone forward together, and the version question never arises. A chat widget is different in one important respect: it renders inside your page, alongside your CSS, your layout and sometimes your consent tooling. Moving an existing installation to a new rendering surface is a change to a live page on a live site, and doing that automatically to every customer overnight is how you break a thousand checkout flows at once.
So the rule is deliberate and it is worth knowing: a new account is created on the current generation, and an existing account stays where it is until somebody chooses to move it.
How the version is actually decided
When a visitor's browser loads your snippet, the request arrives with your account identifier, and the server resolves which runtime to serve. The resolution order is simple:
- Your account's stored generation is the normal answer, and for almost every request it is the only one that matters.
- An explicit override in the snippet URL wins if present. This exists so a specific page can be pinned during testing, not as a thing to leave in production.
- A site-wide default can move accounts that are already on the current generation onto the promoted build, and is deliberately written so that it cannot convert an older account's snippet into the newer surface.
That last clause is the safety property. Even the global switch, the one an operator would reach for to roll everybody forward, is constrained so that it will not silently change what an older installation renders. If you have an old snippet in an old template on a page nobody has touched in three years, it keeps working the way it always did.
The practical consequence: nothing about your widget changes because we shipped something, unless you asked for it. That is a guarantee worth having and it is also the reason you can be running a widget from years ago without ever noticing.
How to tell which one you have
Three ways, roughly in order of how quickly they answer the question.
- Look in the dashboard. There is a page for the widget version that states which generation the account is on and offers the switch. If you are hunting for a setting a colleague has and you do not, check here first — a missing option is more often a generation difference than a plan difference.
- Look at what the widget can do. Capabilities are the most honest signal. Behavioural invitation rules evaluated in the visitor's browser, and article search inside the chat window, belong to the current generation. If those are absent, you are on an older one.
- Look at the network requests. Open your site with the browser's developer tools on the network tab and watch what the chat snippet pulls in. The runtime path names the generation directly. This is the definitive answer and takes about twenty seconds.
The third method is also the one to use when a colleague insists the widget is fine and you are seeing something different — two people can be looking at two pages carrying two different snippets, which happens more often than anyone expects on sites with several templates.
What you gain by moving, honestly
The current generation is where new work happens, so the gap widens over time rather than narrowing. As of now the differences worth knowing about are these.
- Trigger rules that run in the browser. Invitation rules evaluated on the visitor's own device, against things only the browser knows — how far down the page they are, how long they have been on it, whether the pointer just left towards the tab bar.
- Article search inside the chat window, so a visitor can look something up without leaving the conversation.
- An actively developed rendering surface. Accessibility, keyboard behaviour, mobile layout and styling fixes land here.
What you do not gain is anything about how conversations are handled on our side. Routing, transcripts, notifications, ticketing and the AI assistant are server-side concerns and work the same regardless of which widget generation the visitor loaded. This matters when you are weighing whether the move is urgent: if what you want is an AI answering after hours, you already have it. If what you want is an invitation that fires when someone scrolls past the pricing table, that is a widget-side capability and the version is the gate.
What to check before you switch
Switching is a dashboard action and it takes effect on the next page load, which is exactly why it deserves ten minutes of preparation rather than a click on a Friday afternoon.
- Your styling. The widget renders inside your page rather than in a sealed frame, which is what lets it match your site — and also means your own CSS can reach it. A rule written broadly enough on your side can restyle controls inside the chat window. Look at the widget on your busiest template after switching, not just on the homepage.
- Your customisations. Colours, launcher position, greeting text and pre-chat fields are settings you have already made. Re-check them rather than assuming they carry across identically, particularly anything positional.
- Every template that carries the snippet. Most sites have more than one. Checkout, blog, help centre and landing pages are frequently built from different templates, and the one nobody remembers is usually the one that matters commercially.
- Your content security policy, if you have one. A CSP that permits the widget will generally continue to, but this is a cheap thing to confirm and an expensive thing to discover from a customer.
- Mobile. On a real phone, not an emulator, on the page where most of your revenue happens.
Do the switch when you can watch it. Early in a working day beats end of week, because the failure mode is not dramatic — it is a widget that looks slightly wrong on one template and is quietly ignored by visitors until somebody notices the conversation count dropped.
When staying put is the right call
There is a real answer here that is not “upgrade”, and it is worth saying because upgrade advice usually assumes the answer.
If your widget works, your visitors reach you, your styling is exactly as you want it, and you have no interest in browser-evaluated invitation rules or in-chat article search, then moving buys you very little today and costs you an afternoon of checking. The older generations are not deprecated out from under you, and the resolution rules described above exist specifically to keep them serving.
The honest triggers for moving are: you want a capability that lives in the current generation; you are rebuilding the site anyway and the testing is nearly free; or your widget is visibly wrong on mobile and you would rather move to the actively developed surface than patch around it. Absent one of those, a deliberate decision to stay is a perfectly good decision, and it is better than a half-finished migration nobody tested.
And if you have already moved and it did not go well, going back is a supported action rather than a support ticket: there is a dedicated screen for switching the embedded chat back to the Classic UI. It is worth knowing what that screen does and does not change before you reach for it — in particular that it applies to the whole workspace and will not tell you which version you are on today.
What to measure after a switch
- Conversations started per day, compared with the same weekday before the change. This is the number that catches a widget nobody can find or click. Compare like weekdays, not raw daily totals.
- Mobile share of conversations. A layout problem on phones shows up here before anyone reports it, because visitors do not file bugs about a chat button they could not tap.
- Pages conversations start from. If one template disappears from the list, that template is broken, and this is the quickest way to find out which one.
- Any change in blocked or failed loads, if you have visibility into it. Worth one look after the switch and then no more.
- Nothing about response time. That is a staffing measure and the widget generation does not touch it — if it moved, something else changed at the same time.