How to Add an AI Character to Your Website

Adding an AI character to a website no longer requires building a custom real-time avatar application. A modern website assistant can be embedded as a full-page experience, placed inside part of a page, or opened from a floating corner widget. The character can listen, think, speak and animate while the host website remains a normal web application.

The more important design question is not how to put a face on a page. It is what job the character should do once it is there.

What is an AI character for a website?

A website AI character is a visual conversational interface that can interact with a visitor in real time. It combines an animated character with speech input, conversational intelligence and generated speech.

It can perform many of the same jobs as a text chatbot or voice agent, but with a visible character that can express personality, emotion and identity.

Common examples include:

• a product expert that answers questions while someone browses a product page;
• a sales assistant that helps a visitor choose between products or plans;
• a support character that explains how to use a service;
• a hotel, venue or tourism guide;
• a course tutor or coach embedded beside learning material;
• a recruitment or onboarding character;
• a fictional or branded character that visitors can meet; and
• an interactive presenter that guides somebody through a page or workflow.

AI website character vs chatbot

A chatbot is usually a text box. It is efficient, familiar and often the right choice when visitors want short factual answers.

An AI character adds a human or fictional presence. That can be useful when personality, trust, teaching, persuasion, role-play or entertainment are part of the job.

The distinction is not that one is intelligent and the other is not. Both can use the same language models and tools. The difference is the interaction layer.

For the broader terminology, see AI Avatar vs AI Character vs Visual Agent vs Chatbot.

Start with the job, not the embed code

It is easy to begin with implementation: “We want a talking avatar in the bottom-right corner.” That is backwards.

First decide why a visitor would talk to the character.

A useful website character should have a clear job such as:

• Explain — make complicated products or services easier to understand;
• Guide — help visitors find the right page, product or next action;
• Qualify — understand the visitor's needs before a sales conversation;
• Teach — answer questions about material on the page;
• Demonstrate — make the product itself visible through an interactive character;
• Support — answer common questions and escalate when necessary; or
• Entertain — create a character experience that makes the site itself memorable.

Once the job is clear, the placement and interaction model become much easier to choose.

There are three useful ways to put an AI character on a website

1. Embed the whole experience in the page

This works well when the character is the main content: a training scenario, tutor, product demonstration or interactive story.

Liforma's HTML integration uses a CDN script and one custom element. There is no build step:

<script src="https://cdn.liforma.ai/sdk/v2/client.js"></script>

<div style="width: 100%; min-height: 480px;">
  <liforma-experience
    experience-id="exp_YOUR_EXPERIENCE_ID"
  ></liforma-experience>
</div>

The same approach works in ordinary HTML and in site builders or CMS products that allow custom HTML, including WordPress, Webflow, Squarespace, Framer, Shopify, Wix and Ghost. See the HTML integration documentation.

2. Use a floating corner character

For a site-wide assistant, a full-page embed can be too intrusive. A floating launcher allows the character to remain available without taking over the page.

Liforma's ExperienceWidget is designed for this pattern. The collapsed state loads a lightweight visual preview. The actual player and conversational session are created when the visitor opens it.

<script src="https://cdn.liforma.ai/sdk/v2/client.js"></script>

<liforma-experience-widget
  experience-id="exp_YOUR_EXPERIENCE_ID"
  alt="Talk to our assistant"
  position="bottom-right"
  offset="16"
></liforma-experience-widget>

This is usually the best pattern for product help, sales assistance and support because the character is available across the site without obscuring the content. See the ExperienceWidget documentation.

3. Integrate the experience as part of your application UI

If the character is a first-class part of a web application, use the framework component or JavaScript API rather than treating it as a standalone widget.

For example, a Svelte application can render the complete experience with:

<script lang="ts">
  import { Experience } from '@liforma/client/svelte';
</script>

<Experience experienceId="exp_YOUR_EXPERIENCE_ID" />

The Liforma SDK provides equivalent integration surfaces for Svelte, React and Next.js. The quick start shows the supported frameworks and session model.

What Liforma handles for the host website

A useful abstraction is that the website integrates an Experience, not a collection of low-level AI services.

The hosted runtime handles the underlying conversation and presentation lifecycle, including speech, turns and avatar rendering. The site supplies the space in which the experience appears and, for advanced integrations, can listen to events or control parts of the session.

That means a basic integration does not require the website developer to separately wire together:

• speech recognition;
• a language model;
• text-to-speech;
• speech-to-animation;
• avatar playback;
• conversation lifecycle; and
• the UI for starting and stopping the interaction.

For the developer, the reusable unit is the Experience ID.

Can you embed an AI character without a backend?

Yes. Liforma supports browser session creation protected by an origin allowlist.

For a basic public experience, you add the website's origin to the allowed origins and embed the experience. The browser can then create a session without exposing an API key.

Liforma's browser-embed documentation recommends server-side session creation when you already have a backend, but the origin-allowlisted browser path exists specifically so an embed does not require one.

In production, microphone access requires HTTPS.

When should you use a server-created session?

A server session is useful when your own application needs to decide whether a visitor is allowed to start an experience.

Examples include:

• an authenticated customer portal;
• a paid course;
• usage tied to your own customer account;
• an internal company application; or
• a product where you want your server to control session creation.

The browser calls a route on your own application, and that server route uses the Liforma API key to mint the session. The key never needs to be exposed to the browser. Liforma provides helpers for this pattern in Next.js as well as the underlying session API.

What if the website builder strips scripts?

Some CMS editors remove <script> tags from page content for security.

In that case, put the Liforma CDN script in the theme, site header or equivalent global code area, then place only the <liforma-experience> element in the page content.

If the platform cannot host the component at all, Liforma also supports a direct player <iframe>. Public Experience URLs expose oEmbed metadata as well, which can help platforms that understand rich embeds from a pasted URL. See the oEmbed documentation.

A website character should understand the context of the website

Embedding the character is only the first step. A genuinely useful website assistant should know what it is there to help with.

There are two broad kinds of context.

Stable website knowledge

This is information that belongs to the site or company: products, services, pricing, policies, documentation, FAQs and other content.

For larger sites, the normal pattern is to turn this content into a searchable knowledge source rather than putting the entire website into every LLM prompt. Relevant passages can then be retrieved when the visitor asks a question.

Current-page context

The assistant can also benefit from knowing what the visitor is looking at right now.

On a product page, that might include the product name, description and visible options. On a help page, it might include the article title and relevant text. On a checkout page, it might include non-sensitive state supplied deliberately by the host application.

This can turn a generic assistant into something much more useful:

“I can see you're looking at the Business plan. Would you like me to explain how it differs from the Creator plan?”

Do not blindly send the entire DOM to the AI

A tempting implementation is to take document.body.innerText and append the whole page to every prompt.

That can work for a small prototype, but it is usually a poor production architecture.

Pages contain navigation, cookie banners, repeated footers, hidden UI, legal text, unrelated components and user-generated content. Sending everything wastes context and can make the assistant less reliable.

A better website-assistant design extracts or supplies the parts of the page that are actually relevant. That can be done by:

• marking the page regions that the assistant is allowed to read;
• sending structured page metadata from the host application;
• extracting the main article or product content;
• using a pre-built knowledge index for the stable site content; and
• adding only the current-page information needed for the present turn.

This keeps the context cleaner and reduces the risk that arbitrary page content accidentally becomes an instruction to the model.

Page context creates a new kind of website assistant

Traditional support bots often behave like a separate help centre. The visitor opens the widget and asks the bot a question from scratch.

A page-aware character can behave more like somebody standing beside the visitor.

On an insurance page it can explain the policy currently visible. On a SaaS pricing page it can compare the plans the visitor is looking at. On a museum website it can discuss the exhibit on the page. On a course page it can answer questions about the current lesson.

The interaction begins with shared context rather than requiring the visitor to restate where they are and what they are reading.

What should the character be allowed to do?

Answering questions is only one level of website assistance.

An agent can also use controlled tools exposed by the host application. Depending on the use case, those tools might:

• look up a product or order;
• check availability;
• open the right help article;
• capture a lead;
• book or request an appointment;
• advance an onboarding flow; or
• write structured state back to the host application.

Liforma Experiences support tools as controlled external capabilities. The character can invoke the tools declared for the experience, while the host application observes results and state changes. See the Liforma concepts documentation.

The important word is controlled. A website character should not get unrestricted access to the page, database or browser merely because it can converse with the visitor.

Full-screen character or corner widget?

The right presentation depends on whether the character is the destination or an assistant to the page.

Do not make the visitor talk to the avatar

A visible character is not an excuse to force a conversational interface onto every task.

Visitors should still be able to browse the website normally. The character should help when conversation is faster, clearer or more engaging than navigating alone.

That usually means:

• do not block the page behind the assistant;
• make the character easy to dismiss or minimise;
• do not start microphone capture unexpectedly;
• offer clear text/UI alternatives for important actions;
• keep normal navigation usable; and
• make it obvious that the visitor is interacting with AI.

Do you need a photorealistic website avatar?

Not necessarily.

If the website character is intended to reproduce a real salesperson, founder or spokesperson, photorealism may be important.

But a product guide, tutor, mascot or branded character may work better with a deliberate stylised identity. A stylised character also signals more clearly that the visitor is interacting with an AI character rather than a human video call.

The trade-offs are covered in Photorealistic vs Stylized AI Avatars: Why More Realistic Isn't Always Better.

How much does a website AI character cost?

Cost depends heavily on how the platform meters usage.

A persistent real-time avatar session can be billed for every minute the visitor remains connected, even while they are thinking or reading. Other systems charge separately for the avatar, speech recognition, language model, voice and session infrastructure.

Liforma Live is currently priced at approximately $0.01 per generated speech minute for STT, intelligence, TTS and speech-to-animation, without a separate per-connected-minute session charge. That can be particularly useful for website assistants because a visitor may keep the page open much longer than the character actually speaks.

For a detailed current comparison, see How Much Do Interactive AI Avatars Cost?.

Example: turning a product website into an interactive sales assistant

Imagine a visitor arrives on a company's pricing page.

A small character is visible in the corner. It does nothing until the visitor opens it.

The character already knows the company's stable product information. The host page also supplies the fact that the visitor is currently viewing pricing.

The visitor asks:

“We have about 40 employees and need SSO. Which plan should we use?”

The character can explain the relevant plans and ask a follow-up question. If the visitor wants to talk to sales, a controlled tool can capture the request or move them into the appropriate workflow.

The important point is that the visitor never had to leave the page, search the documentation or restate which product they were looking at.

Example: a character that teaches the page rather than supports it

The same architecture can be used very differently on an educational site.

Suppose a learner is reading a lesson about the solar system. Instead of a generic help bot, the page contains an AI science tutor. The tutor can answer questions about the material, ask the learner questions, explain a difficult paragraph in another way and launch a short role-play.

The character is no longer customer support. It is part of the content.

That is why we think website AI characters are ultimately a larger category than “chatbot with a face.”

Example: let visitors meet your product before installing anything

An interactive avatar company has an unusually useful marketing opportunity: the product can demo itself inside the website.

A visitor can talk to a working character before signing up. The same pattern can work for other businesses too. A tradesperson, consultant, school, hotel or SaaS company could let prospective customers try a site-specific assistant before making a purchasing decision.

For a product whose value is inherently interactive, an embedded live demonstration can communicate more than screenshots or a two-minute product video.

How to add a Liforma character to your site

1. Create or remix an Experience. Choose the character, appearance, voice, backdrop, behaviour and any experience state or tools you need.
2. Publish it. The Experience becomes the reusable unit you can launch from the site.
3. Choose the presentation. Use a full embed when the character is central, or ExperienceWidget for a floating assistant.
4. Choose browser or server session creation. Public browser embeds can use origin allowlisting; authenticated applications can mint sessions from their own server.
5. Add the component. Use HTML/CDN, Svelte, React, Next.js or the lower-level JavaScript API.
6. Test the real page. Check microphone permission, mobile layout, loading behaviour, minimisation and the way the character coexists with the site's existing navigation.
7. Add context and tools only where useful. Give the character the information and capabilities needed for its job rather than uncontrolled access to the site.

The bigger opportunity: from chatbot to page-aware character

The first generation of website AI mostly added a small text window in the corner of the page.

The next step is not simply to replace that box with a face. It is to create an assistant that has a role, understands the visitor's current context, can explain what they are looking at and can take part in a richer experience when needed.

Sometimes that character will still behave like support. Sometimes it will teach, demonstrate, qualify, role-play, guide or entertain.

The website stops being merely a collection of pages with a chatbot attached. It becomes a place where visitors can meet intelligent characters that understand why they are there.