> For the complete documentation index, see [llms.txt](https://docs.limecall.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.limecall.com/callback/styling-the-widget.md).

# Styling the widget

Brand the widget from the dashboard, and what to know before writing your own CSS.

## Use the dashboard first

Colour, position, corners, launcher style, button text and the panel's logo are all settings — see [Appearance](/callback/appearance.md).

Settings travel in the configuration the widget fetches at load time, so they apply everywhere the widget is installed, they survive widget updates, and they can be changed without touching your site's code. Reach for CSS only for something the settings genuinely cannot express.

{% hint style="warning" %}
Do not brand the widget by adding `data-` attributes to your snippet. They override the fetched configuration and freeze that setting on your site, after which the dashboard stops affecting it. Use the Appearance settings.
{% endhint %}

## If you must write CSS

The widget renders into your page with class names prefixed `lp-`. You can target them from your own stylesheet.

```css
/* Nudge the launcher clear of a sticky footer */
.lp-launcher {
  bottom: 96px !important;
}
```

`!important` is usually required, because the widget sets its own positioning inline.

## Know what you are taking on

{% hint style="warning" %}
Internal class names are not a supported API. They are implementation detail and can change in any widget update, without a version bump and without warning — the widget updates itself on your site.
{% endhint %}

That is a real trade-off, not a formality: CSS written against internal classes can break silently, and the first sign is usually a customer telling you the contact button looks wrong.

If you do it:

* **Keep it minimal.** Position and spacing survive far better than restyling internals.
* **Scope it tightly.** One rule against one class beats a cascade of overrides.
* **Re-check after updates.** Put it on whoever owns the site as a periodic check.
* **Never rely on layout internals.** Anything depending on the panel's internal structure will break.

## Better alternatives

**The widget does not fit your design.** Hide the launcher and use your own button, so the only visible element is one you control:

```js
window.LimeCall.on("ready", function () { window.LimeCall.hideLauncher(); });
```

See [Widget recipes](/callback/widget-recipes.md).

**You want your own form entirely.** Post to the widget API and never render the panel at all — your markup, your styling, your validation. See [Connect your own form](/callback/connect-your-own-form.md).

That is the right answer for anyone doing heavy visual customisation: a supported API you control beats CSS against classes that can move.

## Inline mode

The **Inline** display style renders the widget into a container on your page rather than floating it:

```html
<div id="limephone-callback"></div>
```

Size and position that container with your own CSS as you would any other element. This is the supported way to place the widget inside a page layout, and it does not depend on internal class names.