Any time Interface Builder shows the user a server-authored message — a toast after a submission, an inline alert, or a data-source message view — the text passes through an HTML sanitiser before rendering. This page describes exactly what is allowed, what is stripped, and where each message surface appears.

## Allowed HTML

Messages and titles may include a narrow subset of HTML: inline formatting, links, paragraph and list structures.

| Tag | Purpose |
|-----|---------|
| `<b>` / `<strong>` | Bold |
| `<i>` / `<em>` | Italic |
| `<u>` | Underline |
| `<br>` | Line break |
| `<code>` | Inline monospace |
| `<a href="...">` | Link |
| `<p>` | Paragraph |
| `<div>` | Generic block wrapper |
| `<ul>` / `<ol>` / `<li>` | Bulleted or numbered list |

Every other tag is stripped. Text inside stripped tags is kept; the tags themselves vanish:

- `"<h1>y</h1>"` → `"y"`
- `"<table><tr><td>x</td></tr></table>"` → `"x"`
- `"<script>alert(1)</script>ok"` → `"ok"`

## Allowed attributes

- `<a>` accepts `href`. All other attributes are dropped.
- Event-handler attributes (`onclick`, `onerror`, and so on) are stripped from every tag.
- `<img>`, `<iframe>`, and similar embeds are removed entirely.

## Link behaviour

Anchors are rewritten to open safely:

- `rel="noopener noreferrer"` and `target="_blank"` are added automatically. Your server cannot override them.
- Only `https:`, `http:`, `mailto:`, and `tel:` schemes are allowed. Any other `href` is removed, including `javascript:`, `data:`, a relative path and an anchor.
- An `<a>` with no `href` left, or with an empty `href` or a bare `#`, renders as its text only.

Example:

| Server sends | User sees / clicks |
|--------------|--------------------|
| `Visit <a href="https://example.com">our site</a>` | "our site" link, opens `https://example.com` in a new tab |
| `Email <a href="mailto:help@example.com">us</a>` | opens mail client |
| `<a href="javascript:alert(1)">click</a>` | "click" with no link |
| `Email <a href="">us</a>` | "Email us" as plain text |

## Variants

The `variant` field in a response controls the message's colour and icon. Five values are recognised:

| Variant | Toast type | Inline alert style |
|---------|------------|--------------------|
| `default` | Success | Neutral |
| `success` | Success | Green |
| `destructive` | Error | Red |
| `warning` | Warning | Yellow |
| `info` | Info | Blue |

Unknown values fall back to `default`.

## Where messages appear

Each response shape decides where the message ends up.

| Response | Appears as |
|----------|------------|
| `{ message, variant }` after **Wait for response** | Toast |
| `{ message, title, variant }` after **Wait for response**, with **Show message after submission** off | Toast (`title` = primary text, `message` = description) |
| `{ message, title, variant }` after **Wait for response**, with **Show message after submission** on | Inline alert that replaces the form; view scrolls to it |
| `{ oneclick_data: { message } }` after a submit or URL button | Toast |
| View data source error `{ oneclick_data: { error_message: { title, message, variant? } } }` or `{ oneclick_data: { message_view: { … } } }` | Full-page message view with Go Back / Retry buttons |
| `{ success: "…" }` after **Select view** | Success toast just before navigation |

Titles and messages in every one of these surfaces go through the same allowlist.

## Empty messages

If `title` is empty or missing, the primary display uses `message` instead. If both are empty, nothing is rendered for that field.

## See also

- [HTTP Response Format](/docs/buttons/interface-button/interface-builder/reference/data-binding/http-response-format) — the exact response shapes that carry these messages.
- [How to format messages](/docs/buttons/interface-button/interface-builder/how-to/data/messages-and-toasts) — practical guide for what to return from your backend.