Build a Comparison Table Readers Can Use

Build a comparison table with one item per row, one comparable quantity per column, and an explicit label for missing information. Give it a caption that says what the reader is comparing, then explain the decision the values support.

Start with the question your post answers. If you are still choosing that question, use your blogger keyword research plan. A useful table makes the answer easier to inspect; adding more columns does not automatically make it more useful.

Choose the decision before the columns

For a bottle comparison, a reader might ask which options hold enough water without exceeding an empty-weight limit. Capacity and empty weight belong in separate columns. A price column can provide context, but it does not answer that capacity-and-weight question.

For real recommendations, establish that your observations can support a comparison before building the table. The affiliate research guide covers that earlier decision. Here, the task is arranging suitable information so readers can use it.

Fill a small example

Table: Fictional bottle specifications for practicing comparison-table construction. All values are imaginary teaching data.

Suppose the teaching decision requires at least 500 mL and an empty weight no greater than 300 g. Bottle A meets those two limits. Bottle B exceeds the weight limit. Bottle C has enough capacity, but its weight is unknown, so the table cannot establish whether it meets both conditions.

This is a conditional reading of invented specifications, not a product recommendation or an overall winner. The table says nothing about leakage, durability or whether the price includes delivery.

Keep quantities and missing values clear

Use the same quantity and unit down each column. Empty weight is not filled weight, and capacity is not a weight measurement. If your real sources use different units, convert them to a documented common basis before entering the values, retaining the original values in your notes.

Name the currency and price basis when using real prices. A monthly fee and a one-time purchase price should not appear as comparable bare numbers in one price column. Add the relevant date and conditions to your source notes rather than quietly dropping them.

Write Unknown when you lack a value. Use Not applicable when the criterion does not apply, and explain why. Enter zero only when it is the known value. A blank published cell or an unexplained dash leaves the reader guessing which meaning you intended.

Keep a separate data item in each cell. Avoid stuffing several weights or prices into one cell with line breaks. W3C's table tips recommend separating data this way and keeping complex topics in simpler tables.

Give the table headers and a caption

Use specific column names such as Empty weight (g), rather than Size or Details. Item names identify the rows. W3C's table tutorial explains why structural header and data cells matter: visual styling alone does not express their relationship to software.

In HTML, use th for headers and td for data. For this example's row and column headers, scope="row" and scope="col" make the intended direction explicit, following W3C's two-header guidance.

A short caption identifies the table's topic. Put an HTML caption directly inside the table when your editor supports it. W3C's caption guidance explains this connection. A nearby paragraph can visibly label a table, as above, but it does not create that HTML caption relationship.

The filled HTML teaching file includes the complete example. This excerpt shows the pattern:

<table>
  <caption>Fictional bottle specifications — imaginary teaching data</caption>
  <thead>
    <tr>
      <th scope="col">Item</th>
      <th scope="col">Capacity (mL)</th>
      <th scope="col">Empty weight (g)</th>
      <th scope="col">Price (USD)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Bottle C</th>
      <td>600</td>
      <td>Unknown</td>
      <td>22</td>
    </tr>
  </tbody>
</table>

The code is teaching markup. A Markdown pipe table, a bold first column or an editor's preview does not guarantee the same saved HTML. An editor may remove captions or attributes, so inspect the published output before claiming those relationships are present.

Reuse the files

Download the filled CSV data to see how each quantity stays attached to its item, unit and teaching label. It stores one item-and-criterion pair per row; arrange those pairs into the display table shown above. The unknown weight has an explanation instead of a substitute number. Real-source dates remain empty because these entries are fictional.

Use the blank CSV worksheet for your own data. Replace the sample item labels and criteria, enter values with a source and checked date where relevant, and record why a value is unknown. Unfilled worksheet cells are prompts to finish, not ready-to-publish facts.

The Markdown template supplies the filled example and a blank display table. The HTML teaching code is a plain-text file you can open and copy into an HTML-capable editor. It adds the caption and explicit row/column headers; it does not configure your theme or certify its accessibility.

Check the actual result

Compare the displayed values with your source notes, including units and unknowns. Check the saved HTML for the intended caption and header relationships. If your editor cannot preserve them, use a supported table tool or obtain implementation help rather than assuming the preview is sufficient.

View the published table on a phone and with enlarged text. Keep every cell reachable, with its meaning intact; a wide table must not simply lose its rightmost columns. W3C's responsive-table advice emphasizes preserving relationships when the presentation changes. Test the actual output with assistive technology where relevant, and record only tests you perform.

Finish with a sentence explaining what the table establishes and what information still matters. Then fit it into your complete blog post, where readers can move from the comparison to a useful next step.