Making the widget look like your site

Everything visual lives on the widget's Design tab, and nothing is applied to your visitors until you press Publish.

Start from a screenshot

The fastest way is to upload a screenshot of your own site. We read the palette, the corner radius and the typeface off it and propose values; you review and change anything before applying, and applying only fills the fields -- it does not save. The screenshot is not stored.

Theme tokens

Each field is a CSS variable the widget reads:

• Primary and Primary hover are the launcher, the send button and the links.
• Visitor bubble and Assistant bubble are the two sides of the conversation.
• Page background, Panel background, Text, Muted text and Borders are the panel itself.
• Panel radius, Bubble radius, Font size, Launcher size, Panel width, Panel height and the two offsets are the shape and where it sits.

Leaving a colour empty means "inherit", which is usually right for the ones you have no opinion about. Every field can go back to the WelcomeAI default on its own, and there is one button that resets the lot -- you cannot get stuck with a configuration you regret.

You will not see all of them. The list is filtered to the tokens the widget's own type actually draws, because a colour picker for something that never appears is a setting saved and never read. A floating chat gets all forty-one; a docs assistant has no launcher button, so the seven launcher colours are not offered; Spotlight and Inline input draw an answer card rather than bubbles, so the two bubble colours and the bubble radius are not there either; and Glow, the second colour in Spotlight's gradient wash, is offered to Spotlight and to nothing else. Change the type and the list changes with it.

Typeface

Pick from the Google Fonts list and it loads in the editor, in the preview and on your site, from one request. Leave it as the system font if you would rather not add a download: it matches whatever device the visitor is on and appears instantly.

Giving the assistant a name and a face

Under Assistant identity you can call the assistant something -- Mia, Alex, whatever suits the brand -- and give it a picture. Three things change:

• The name appears as a small label above each reply, the way a messenger shows who is speaking. It is drawn once per run of answers, not on every bubble.
• The picture appears beside each reply and in the panel header, cropped square and drawn round.
• While it writes decides what the visitor sees while the answer is coming: the three dots, the words "Mia is typing...", or both. With no name it is always the dots -- a typing line with nobody in front of it reads as a bug.

The name is presentation only. It is not sent to the model and it does not change how the assistant answers; if you want it to say it is Mia, put that in the knowledge base's operator instructions.

Pictures, and what happens to them

Every image you upload here -- the assistant's picture, the hosted page's logo and its background -- is converted to WebP in your own browser before it is sent, scaled to the size we actually draw it at. A four-megabyte photograph dropped on the background field arrives as about twenty kilobytes. The original never leaves your machine and is never stored.

Each upload gets its own address that never changes its contents, so browsers and our CDN cache it for a year and a replacement is picked up immediately.

The launcher icon

The WelcomeAI mark by default. Upload your own as a PNG or JPG at exactly 128 by 128 pixels, or as a square SVG. An SVG is checked carefully before it is stored -- scripts, event handlers, embedded files and external references are refused, and what we keep is a rebuilt copy containing only what is needed to draw it.

Light, dark, or follow the visitor

Theme has three settings. Auto follows the visitor's own system preference, which is the right default for a site that already does.

The live preview

The panel beside the editor is your widget on a real page at a real device width. Switch between desktop, tablet and mobile: the widget has its own breakpoints and they only fire at real widths, so judging the mobile layout by making the browser narrow does not work.

The hosted page (Full page widgets)

A Full page widget is served on its own address -- ours, or your own hostname -- so unlike every other type it has no page of yours around it. Hosted page appearance is that page:

• Header logo and Header text are the strip above the chat. The logo is never cropped; set its height in pixels and the width follows. The text has a colour of its own, because the strip sits over your background rather than inside the panel.
• Background colour is the ground behind the panel, and it is also what the page paints before the widget has loaded -- so a dark brand no longer gets a white flash on its own domain.
• Background image goes behind everything, with a fit (cover, contain or tile) and an overlay: a colour with its own opacity laid on top, so one photograph works under a light theme and a dark one without exporting it twice.
• Panel width is how wide the chat is allowed to get on a large screen.

Quick actions: two texts, one visible

A quick action is a pill shown before the first message, and an Ask one carries two strings:

• Label is what the visitor sees and clicks -- and, once they do, it is what their own message says in the chat.
• Question to send is what the assistant receives. It is never shown to the visitor, so it can be as long and as specific as it needs to be: "What does each plan cost per month and per year, and what is included in each?" behind a pill that reads "See pricing".

Leave the question empty and the label is sent as-is, which is the right choice when the pill already reads like a question.

In your Conversations the visitor's message shows the label, with the question underneath it -- so "why did it answer that?" is answerable from the transcript without opening the widget's settings.

Publishing, and clearing the cache

Publish does two things: it makes the draft what visitors get, and it clears the answers stored for this widget's knowledge base. Those answers are keyed on the question and the material, not on anything on this screen, so without that step a change to the greeting or the citations could be followed by a day-old reply.

Clear cache does the second half on its own. Use it when the material changed rather than the widget -- you re-indexed a source, rewrote the system prompt, corrected a price in a document. It only touches the knowledge base this widget answers from.

When the tokens are not enough

Pro and Business plans can write custom CSS against the widget's shadow root, using ::part() selectors for the launcher, panel, header and messages, or the widget's own class names. @import and external url() are stripped -- the widget must not fetch anything from a third party onto your visitors' pages.

If you are fighting the CSS, check the simpler thing first: a token you left empty is inheriting from somewhere, and setting it explicitly is usually the whole fix.