> ## 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.

# Tables for structured comparisons

> Use tables when you're comparing multiple items against a consistent set of attributes.

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>;
};

Tables communicate relationships between items and attributes. A reader can scan a column to understand all the values for one attribute, or scan a row to understand everything about one option. However, tables only work if the content actually has that structure. Using tables when the information isn't tabular can make it harder to understand or introduce accessibility issues.

## When are tables the right choice?

Tables work well when:

* You have multiple items (rows) with the same set of attributes (columns)
* Each cell has a short, scannable value. Don't put paragraphs of prose in table cells.
* The comparison is the point, not the individual items.

Examples of when to use tables:

* Feature comparison by plan tier
* Supported SDK languages by feature
* API parameters with name, type, default, and description columns
* Operating system requirements

```mdx Environment requirements table theme={null}
| Environment | Minimum version | Notes |
|-------------|----------------|-------|
| Node.js     | 18.0           | LTS recommended |
| Python      | 3.9            | |
| Ruby        | 3.1            | |
| Go          | 1.21           | |
```

## When are tables the wrong choice?

Trying to force non-tabular information into a table is the most common problem. There must be a relationship between the table rows, headers, and cells. If there isn't, don't use a table.

Uneven cell content can be difficult to read. If some cells are two words and others are two paragraphs, the table stops being scannable. Pull the long content into a separate section and use the table for the short summary.

Tables with more than five or six columns start to break on mobile screens. Consider whether some columns could be collapsed, removed, or moved to a detail section.

Tables aren't good for narrative content. If you expect someone to read every word in a table in a particular order, it isn't actually a table. Similarly, don't try to put complex conditional logic in a table cell. If your table cell says "See note 3 below," reconsider how you're structuring the information.

If cells need bullet lists, code blocks, or multiple paragraphs, use a different structure.

## Alternatives to tables

When a table is almost right but doesn't quite fit, consider these alternatives:

* Two or three items with many attributes: consider cards organized with `<Columns>`.
* Many items, few attributes: a bulleted list may be simpler.
* Comparison where one option is clearly recommended: state the recommendation in prose and use a table only to show the key differences

<Quiz
  question="You're documenting three authentication methods. Each requires explaining a four-step setup process, has a different security model, and is suited for different use cases. Should this be a table?"
  answers={[
{ text: "Yes. Authentication methods with consistent attributes are perfect for tables.", correct: false },
{ text: "No. The content is too complex and narrative for table cells.", correct: true },
{ text: "Yes. Use one row per method and put the setup steps in the cells.", correct: false },
{ text: "No. Use an accordion for each method instead.", correct: false },
]}
  correctFeedback="Right. When each item requires a multi-step explanation, a table cell isn't the right container. The setup processes and security model explanations are narrative content. Better to give each authentication method a section or page, and use a table only for a high-level summary of key differences."
  incorrectFeedback="A four-step process doesn't fit in a table cell cleanly. Tables work for scannable, attribute-value content. Bot procedures or narrative explanations. Use a summary table for the high-level differences (single sign-on, rate limits, token type) and send readers to dedicated sections for the full setup."
/>

<Check>
  Next up: [Columns and cards for visual comparisons](/courses/components/columns-and-cards) — When you need layout flexibility that tables don't provide.
</Check>