> ## Documentation Index
> Fetch the complete documentation index at: https://learn.mintlify.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Choose the right callout

> Mintlify gives you a variety of callout types. Use them to send different signals to your readers.

export const Quiz = ({question, answers, correctFeedback, incorrectFeedback}) => {
  const [selected, setSelected] = React.useState(null);
  const [checked, setChecked] = React.useState(false);
  const quizId = React.useId();
  const isCorrect = checked && answers[selected]?.correct;
  const reset = () => {
    setSelected(null);
    setChecked(false);
  };
  return <div className={"quiz-container" + (checked ? " quiz-checked" : "")}>
      <Badge color="green">Quiz</Badge>
      <p className="quiz-question" id={quizId + "-question"}>{question}</p>
      <div className="quiz-options" role="radiogroup" aria-labelledby={quizId + "-question"} aria-disabled={checked}>
        {answers.map((answer, i) => <label key={i} className={["quiz-option", !checked && selected === i ? "quiz-option-selected" : "", checked && answer.correct ? "quiz-option-correct" : "", checked && selected === i && !answer.correct ? "quiz-option-incorrect" : ""].filter(Boolean).join(" ")}>
            <input type="radio" name={"quiz-" + quizId} checked={selected === i} onChange={() => !checked && setSelected(i)} disabled={checked} />
            <span className="quiz-radio" />
            <span className="quiz-option-label">{answer.text}</span>
          </label>)}
      </div>
      {checked && <div className={"quiz-feedback " + (isCorrect ? "quiz-feedback-correct" : "quiz-feedback-incorrect")} role="status" aria-live="polite" aria-atomic="true">
          <span className="quiz-feedback-icon">{isCorrect ? "✓" : "✗"}</span>
          {isCorrect ? correctFeedback : incorrectFeedback}
        </div>}
      <div className="quiz-actions">
        {!checked ? <button className="quiz-btn quiz-btn-check" type="button" onClick={() => selected !== null && setChecked(true)} disabled={selected === null}>
            Check answer
          </button> : <button className="quiz-btn quiz-btn-reset" type="button" onClick={reset}>
            Try again
          </button>}
      </div>
    </div>;
};

Callouts are visual interrupts. They break the flow of reading so people notice them, stop, and pay attention. And since they're defined components, callouts can signal the same information to AI agents.

But what exactly is the signal you're sending? That depends on which type of callout you use.

If you use callouts inconsistently, you'll send mixed messages and make it difficult for readers to build a mental model of your content.

The main takeaway: use callouts consistently and purposefully. Types carry meaning so treat them as vocabulary, not decoration.

## The types of callouts

While you can use callouts however you like, always use them consistently. And consider how the label affects the reader's perception of the content.

Here are some general guidelines for when to use each type of callout:

| Component   | Signal                 | Use when                                                                                                       |
| ----------- | ---------------------- | -------------------------------------------------------------------------------------------------------------- |
| `<Note>`    | Neutral addition       | There's something useful to know that doesn't fit in the main flow.                                            |
| `<Info>`    | Informational emphasis | You need to draw attention to a fact, definition, or caveat like a permission or prerequisite.                 |
| `<Tip>`     | Optional improvement   | There's a best practice or shortcut the reader might not discover on their own.                                |
| `<Warning>` | Caution required       | Something could break or cause data loss if the reader misses this.                                            |
| `<Danger>`  | Serious harm possible  | Ignoring this information or doing this action incorrectly is destructive, irreversible, or security-critical. |
| `<Check>`   | Confirmation           | The reader has completed something correctly, or a requirement has been satisfied.                             |

## How to choose

Ask yourself, "What happens if the reader skips this callout?"

* Nothing bad, they just miss something useful → `<Tip>` or `<Note>`
* They might be confused or have a worse experience → `<Info>`
* Something breaks or data gets corrupted → `<Warning>`
* Data gets lost, accounts get compromised, or something irreversible happens → `<Danger>`

The `<Check>` callout is different. Use it to give users confirmation after they complete a task. Use the other callout types to guide users before they take an action or make a decision.

```mdx Example of a <Check> callout theme={null}
<Check>
  Your API key is now active. Verify this by checking the **Keys** section of your dashboard.
</Check>
```

## The note versus info distinction

These two are easy to conflate. If you use them consistently, your users learn to expect the same signal from each.

Notes and info callouts can signal different intent.

* `<Note>` is a side thought. "By the way, you might want to know this."
* `<Info>` is a direct call to attention. "Make sure you understand this."

If you want to point out that a feature behaves differently in a specific context, that's probably an info callout. If you're adding an aside about something tangentially related, that's a note.

In practice, many documentation sites pick one and use it consistently rather than trying to draw a precise line. What is more important is that you reserve warning and danger callouts for actual risk.

## Don't escalate to sound important

The most common callout mistake is using a warning because the content feels significant, but there's no actual risk for the user. If you're using `<Warning>` to emphasize a default setting or note an API behavior, you're training readers to ignore your warnings.

Reserve warning and danger callouts for potentially destructive actions or situations where data could be lost or compromised. If you can describe the worst-case outcome and it's "your request fails with a 400 error," that's not worthy of a warning or danger callout. If the worst-case is "all data in this environment is permanently deleted," that's danger.

<Quiz
  question="You want to mention that users can prefix any CLI command with DEBUG=true to see detailed log output. It's not required for normal use, but useful when something isn't working as expected. Which callout type fits best?"
  answers={[
{ text: "<Note> — It's useful information that doesn't fit naturally in the flow", correct: false },
{ text: "<Info> — Users should be aware this option exists", correct: false },
{ text: "<Tip> — It's an optional technique readers probably won't discover on their own", correct: true },
{ text: "<Warning> — Verbose logs can expose sensitive information", correct: false },
]}
  correctFeedback="Right. A Tip is for optional improvements — things that make the reader's experience better but aren't required. DEBUG=true is exactly that: actionable, optional, and easy to miss. Note is for neutral information that doesn't call for action. Tip signals 'here's something worth trying.'"
  incorrectFeedback="Note is for side information — 'by the way' content with no particular call to action. A debugging flag is more than a neutral aside: it's an actionable technique that improves the reader's experience in a specific situation. That's what Tip is for."
/>

<Check>
  Next up: [When callouts stop working](/courses/components/callout-fatigue) — What happens when you use too many callouts and how to fix it.
</Check>
