Comparison Tables: Format and Examples

A comparison table evaluates every option against the same decision dimensions, so a reader can see meaningful differences without reconstructing them from separate paragraphs. It is one of the highest-value page elements for conversion and answer-engine extraction—but only when it is published as data rather than a picture of data.

Legend: “Included” means the capability is part of the stated plan without an add-on. “Not available” means the vendor does not offer it on that plan. “Unknown” means the claim could not be verified from the named source. The names and figures above are illustrative; the structure is the production model.

Why this element matters

Comparison creates cognitive work. When three products are described in three separate sections, the reader has to remember each price, normalize different wording, and decide whether an omitted feature is absent or merely unmentioned. A table removes that memory task. Its rows declare the decision dimensions, its columns hold the options, and each intersection supplies the answer. The reader can scan down one option or across one criterion without losing the relationship.

That structure also improves machine extractability: the ability of a search system or answer engine to preserve the relationship between a label and its value when reusing content. A clear header row, explicit row headers, one fact per cell, and complete dimensions create a compact set of subject–predicate–value statements. “Relay — minimum contract — annual” is easy to isolate and quote. A colored card layout containing the same words may look like a table to a sighted visitor but exposes no reliable row-and-column relationships.

An image of a table is not a comparison table. It is a screenshot containing text. A person using a screen reader cannot navigate its headers and cells. A reader cannot copy a price cleanly, search within it, enlarge text without enlarging the entire image, or adapt it to a narrow screen. Crawlers and answer engines may attempt optical character recognition, but even successful character recognition does not guarantee that the correct value stays attached to the correct row and column. Likewise, a pile of styled div elements may mimic a grid while discarding table semantics. The cost is blunt: the page spends research effort producing facts, then hides their relationships from many people and machines.

When to use it

Use a comparison table when readers must evaluate at least two options against at least three shared dimensions. Suitable subjects include products, plans, methods, service tiers, technical specifications, eligibility rules, and a short ranked list. The dimensions must be comparable: price against price, support channel against support channel, and contract term against contract term.

Do not use one merely because several facts can fit into rows. A two-column label-and-value list about one object is a specification table, not a comparison. A schedule is a timetable. A matrix of raw measurements may be a data table whose purpose is analysis rather than choice. A long narrative argument belongs in prose because a cell should not contain a mini-essay.

Near misses require particular care:

• Different criteria for each option: use separate profiles first, then compare only the shared criteria. A grid with mismatched dimensions creates an illusion of parity.
• One verdict with no supporting dimensions: use a direct recommendation and explain the reasoning. A one-row table adds ceremony, not clarity.
• More than five option columns: split the field by audience or use a filterable, accessible table. Shrinking text until everything fits makes the element technically present but practically unusable.
• A visual feature checklist: use a table only if every symbol has a defined meaning and every option receives an answer for every row.
• Frequently changing live data: use a maintained data source and a visible verification date. If no owner can keep it current, do not publish the table.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

Position the primary comparison table after the page defines the audience, selection method, and dimensions, but before long option-by-option reviews. Readers need enough context to interpret the rows; they should not have to read the whole page before receiving the comparison.

On an A vs B page, the main table normally follows the direct answer and a short “how we compared” note. On a shortlist page, it follows the inclusion criteria and precedes detailed entries. A smaller specification table may appear inside a product section, but it must not contradict the primary table or introduce a different meaning for the same label.

Do not place the table directly beside another dense comparison table, an unrelated call to action, or a full-width screenshot. Competing grids make the reading path unclear. Do not insert a promotional banner between the caption and the table, or a source note between a row and the fact it qualifies. Keep the caption, verification date, legend, table, and source note as one bounded unit. A call to action may follow the explanatory verdict, not interrupt the evidence.

Anatomy

The labelled image must identify these regions without baking the explanations into the asset:

1. Caption: states what is being compared, for whom, and under which plan or scenario.
2. Verification date: gives the exact date on which prices and availability were checked.
3. Column headers: name the options; the first header names the decision-dimension column.
4. Row headers: name one decision-relevant dimension each.
5. Body cells: contain one fact, one number with its unit, or one defined symbol.
6. Highlighted column: indicates the editorial recommendation when one exists; it never changes or hides the underlying facts.
7. Legend: defines every symbol and status label in visible text.
8. Source note: names the primary source or method used to verify claims.

Rendered legend: ✓ = available in the specified plan; — = not available in that plan; N/A = the dimension does not apply; Unknown = the team could not verify the fact. The published component must also expose these meanings to assistive technology—for example, visible or visually hidden text in each cell—not rely on the characters alone.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

Every variant uses the same semantic core. Visual treatments may change emphasis and density, but they may not turn cells into images, remove headers, merge cells, or encode meaning only by color.

Standard: two to four options, three to eight decision rows, no editorial highlight. This is the default when the page explains trade-offs rather than declaring one winner.

Highlighted recommendation: one option column may receive a text label such as “Best for small teams.” Color is supplemental. Highlighting cannot change row order, obscure disadvantages, or make another option’s text lower contrast.

Symbol-led: appropriate for repeated binary availability facts. Use it only when the legend is visible and each cell retains an accessible text equivalent. Prices, limits, and qualifications remain text.

Mobile with sticky first column: the table scrolls horizontally inside its own labelled container. The page itself must never acquire horizontal scroll. Keep the first column sticky so a reader can retain the dimension while moving across options; preserve keyboard access and a visible focus state for the scroll region.

Parameters

The parameters below form the portable content contract. “Source” means where the author or renderer obtains the value, not the evidence cited for a commercial claim.

Three option columns plus the row-header column is a common, readable default. Six total columns is the normal ceiling for an editorial table. A larger dataset needs intentional filtering or segmentation, not progressively smaller typography.

Syntax and code examples

All three forms must map to the same caption, checked date, column order, rows, legend, and highlight. The Markdown pipe table is source data inside a typed directive; the outer element supplies metadata and behavior.

Portable Markdown directive

:::comparison-table{caption="Email platforms for a 10-person team" verification-date="2026-08-27" highlight-column="relay"}
| Decision dimension | Northstar | Relay | Postbox |
|---|---:|---:|---:|
| Monthly price, 10 users | $90 | $120 | Not available |
| Approval workflow | Included | Included | Not available |
| Minimum contract | Monthly | Annual | Unknown |

Legend: Included = part of the named plan; Not available = absent from the plan; Unknown = not verified.

Source: vendor plan and pricing pages.
:::

Hugo shortcode

The existing generic table helper does not carry a caption, verification date, row-header scope, legend, source, or highlight as first-class fields. Until its renderer satisfies this contract, use semantic HTML for a live comparison rather than accepting a visually similar but structurally incomplete grid. The intended Hugo mapping is:

{{< comparison-table caption="Email platforms for a 10-person team" verification-date="2026-08-27" highlight-column="relay" >}}
| Decision dimension | Northstar | Relay | Postbox |
|---|---:|---:|---:|
| Monthly price, 10 users | $90 | $120 | Not available |
| Approval workflow | Included | Included | Not available |
| Minimum contract | Monthly | Annual | Unknown |

Legend: Included = part of the named plan; Not available = absent from the plan; Unknown = not verified.

Source: vendor plan and pricing pages.
{{< /comparison-table >}}

The renderer must output a native <table class="art-table">, <caption>, <thead>, and <tbody>; scope="col" on column headers; scope="row" on row headers; and a contained horizontal-scroll region. The notation is not permission to substitute cards or an image.

WordPress block or shortcode

[comparison_table caption="Email platforms for a 10-person team" verification_date="2026-08-27" highlight_column="relay"]
Decision dimension | Northstar | Relay | Postbox
Monthly price, 10 users | $90 | $120 | Not available
Approval workflow | Included | Included | Not available
Minimum contract | Monthly | Annual | Unknown
[legend]Included = part of the named plan; Not available = absent from the plan; Unknown = not verified.[/legend]
[source]Vendor plan and pricing pages.[/source]
[/comparison_table]

A custom WordPress block may expose the same fields in form controls. It must save or render native table markup and preserve the relationships when styles or scripts fail.

Examples

Good: a decision-ready comparison

This works because every plan answers every decision dimension, numbers include their units and seat assumption, absence is explicit, and the checked date bounds the claim. The most decision-relevant row—total price for the actual team—comes first. Each cell contains one fact rather than a sales claim.

Bad: a persuasive-looking grid

The bad version fails before styling is considered. “Great value” and “powerful” are marketing phrases with no testable meaning. The checkmark has no legend. “Advanced tools” is undefined. The blank Starter cell could mean absent, not applicable, unknown, or forgotten. “Everything you need” bundles an unlimited set of claims into one cell. The rows follow promotional themes rather than buyer decisions, there is no checked date, and there is no source.

Repair it by naming precise dimensions such as guest limit, approval-history period, and single sign-on availability; verifying all three plans against each row; replacing blanks with explicit statuses; defining symbols; and dating the review. If those facts cannot be obtained, publish an honest “Unknown,” not a favorable inference.

Schema markup and accessibility

There is no general Schema.org type or property for a comparison table. The element remains part of the enclosing Article, Product, or collection page. Facts may feed valid product, offer, or rating properties only when the page independently meets the eligibility and evidence rules for that structured data. Do not convert a highlighted column into aggregateRating, review, or offers markup unless the underlying content genuinely supplies those values.

Accessibility comes from relationships, not appearance. Use <th scope="col"> for each option header and <th scope="row"> for each decision dimension. Add a concise <caption> that identifies the table. Avoid merged cells because rowspan and colspan make navigation and extraction harder; repeat a label or split the table instead. Keep the source order logical and do not remove the table from the accessibility tree.

On small screens, place overflow on a container around the table, never on the page. Give a keyboard-focusable scroll region an accessible name and visible focus state. A sticky first column may help preserve context, but it must not cover focused content or rely on scripts to expose data. Symbols require visible text definitions and cell-level text equivalents. Color can highlight a recommended column, but the header also needs a text label.

Writing rules

Choose rows by decision value, not by convenience. Put the criterion most likely to change the reader’s choice first, then prerequisite capabilities, total cost, constraints, support, and secondary details. Alphabetical ordering is useful only when readers arrive knowing the dimension name; it is usually wrong for a buying decision. Vendor navigation order is promotional taxonomy, not reader priority.

Dimension parity is absolute: every option must be assessed on every row. A blank is still an answer, but it is an ambiguous one, so blanks are prohibited in published tables. Use these statuses precisely:

• Not available: the option does not provide the capability under the stated plan or conditions.
• Not applicable: the dimension logically does not apply to that option.
• Unknown: the team could not verify the answer from an appropriate source.

One cell contains one fact, number, or defined symbol. Include units and conditions: “$49/month for 5 seats” is usable; “Affordable” is not. “10 GB per workspace” is usable; “Generous storage” is not. If a value needs a qualification, keep it short and attach the source note to the table. If it needs a paragraph, explain it below the table and use a concise cell label such as “Conditional.”

Use three to eight rows for a summary and no more than ten without a strong reason. Use two to five option columns, plus the row-header column. Keep headers concrete and parallel. Do not put buttons, forms, autoplay media, paragraph-length sales copy, testimonials, star ratings without a stated methodology, or nested tables inside cells. Never use merged cells in the editorial comparison.

The checked-on date is required because price, inventory, plan names, and feature availability change. Write an exact date, not “recently” or “current.” Assign an owner and review cadence before publication. A stale table is worse than no table: its clean structure makes an outdated claim look unusually authoritative and easy to repeat.

Post types that use it

The postTypes frontmatter is the machine-readable join to these six documents. The visible table explains the editorial placement that the identifier alone cannot carry.

QA checklist

• The output is a native HTML table, not an image, canvas, CSS grid, or pile of div elements.
• The table has a useful caption, one clear header row, column-header scope, and row-header scope.
• Every option is assessed on every dimension; no published cell is blank.
• “Not available,” “Not applicable,” and “Unknown” are used according to their distinct meanings.
• Every cell contains one fact, number with units, or defined symbol—never a marketing phrase.
• Every symbol has a visible text legend and an accessible text equivalent in its cell.
• Rows are ordered by decision relevance rather than alphabetically or by vendor-page order.
• The table stays within the column limit, or the content has been segmented deliberately.
• On mobile, horizontal scrolling is contained within the labelled table region and the page does not scroll sideways.
• A sticky first column, when used, remains readable, keyboard-safe, and high contrast.
• No cells are merged and no cells contain nested tables or complex interactive controls.
• A precise checked-on date and appropriate primary source note are present.
• The highlighted column, if any, has a text label and does not suppress unfavorable facts.
• The table still communicates its relationships when custom styling and scripts are unavailable.

FAQ

How many options should a comparison table include?

Use two to five option columns in the main table. If more options are necessary, split the comparison into audience-specific tables or provide a filterable interface that preserves native table semantics.

Can a comparison table use checkmarks and crosses?

Yes, but each symbol needs a visible text legend and an accessible text equivalent. A shape or color alone is not an answer because readers cannot reliably infer whether it means included, recommended, tested, or merely present.

What should a blank cell mean?

Nothing. Blank cells are prohibited because their meaning is unknowable. Write “Not available,” “Not applicable,” or “Unknown” and use each term according to its defined meaning.

Does a comparison table need structured data?

Usually not. No general comparison-table schema exists. Keep it within the page’s valid schema and map product, offer, or rating properties only when the page has the evidence those properties require.

How often should the table be checked?

Match the cadence to volatility. Pricing and plan entitlements may require monthly or quarterly review; stable specifications may change less often. In every case, show the exact last-checked date so readers can judge freshness themselves.