Build a Product Comparison Table Readers Can Use

A useful product comparison table lets readers answer a specific question: Which options meet my requirements, and what evidence supports each value? Start with that question—not a list of every specification you can find.

For example, a portable-monitor comparison might help readers find models costing no more than US$200, weighing no more than 800 grams, and measuring at least 14 inches diagonally. The finished public table should let readers narrow the options while keeping model variants, unknown values and source dates visible.

Define the comparison before collecting data

Write a short scope statement that specifies:

• Products included: the category and selection rule, such as all models in a named manufacturer’s current portable-monitor range.
• Configuration: the exact variant represented by each row.
• Market and price basis: country, currency, seller, and whether tax and delivery are included.
• Time: when prices and specifications were checked.
• Decision criteria: the requirements readers can use to narrow the table.

Treat one row as one exact configuration under one stated price basis. Do not combine the cheapest variant’s price with another variant’s features. If you compare offers from several sellers, identify the seller in each row so readers can distinguish duplicate products from different offers.

Keep manufacturer specifications, independent measurements and your calculations distinct. A claimed weight and a measured weight should not silently share the same field. For a more detailed specification layout, see building a spec sheet readers can verify.

Use columns that support filtering

Keep numbers numeric, put units in headers, and move qualifications into separate fields. Data Carpentry recommends separate fields for notes, consistent units within a column, and one piece of information per cell in its spreadsheet-formatting guidance.

This fictional layout example shows the structure. These are not real products, researched specifications or recommendations. The blank weight is intentional. The result column applies only to the three requirements stated above.

Product ID	Variant	Price USD	Weight g	Diagonal in	Weight status	Requirement result
A	Standard	179	720	14.0	Published	Meets all
B	Standard	199		15.6	Not published	Unverified
C	Standard	229	640	14.0	Published	Over budget

For the example requirements:

• A meets all three thresholds.
• B meets the price and size thresholds, but its weight cannot be assessed.
• C meets the weight and size thresholds, but exceeds the budget.

An unknown value is not a failed requirement—and it is not a pass. Keep the numeric cell blank and explain the reason in a status field. Never enter zero to mean “unknown”: zero is a real value, and numerical missing-value codes can accidentally enter calculations, as Data Carpentry explains.

A requirement-result field makes the distinction explicit. If you include one, publish its thresholds and update it whenever the underlying values change. Keep individual metrics available so readers can apply different requirements.

Use consistent categories such as Yes, No and Unknown for feature availability. Do not use a green cell as the only indication that a feature exists; that meaning may disappear when the data is exported or viewed without colour.

Make each consequential value traceable

Add provenance fields to your working dataset:

Field	What to record
spec_source_url	The exact model or configuration page
price_source_url	The seller page supporting the listed price
checked_date	Date you inspected the sources, in YYYY-MM-DD form
price_basis	Currency, seller, tax and delivery treatment
conditions	Qualifications such as “without stand”
comparison_notes	Unresolved differences or missing information

If one source does not support every specification, add metric-specific source fields rather than implying that it does. Link to the relevant product page or document, not just a manufacturer’s homepage.

Give the publication a version and date. GOV.UK’s spreadsheet-sharing guidance recommends recording publication information, using consistent column names and clearly labelling versions. Keep the dated source file so later changes can be distinguished from corrections.

Prefer requirements to an unexplained overall score

For a general-purpose comparison, start with filters and individual metrics rather than a “best product” score. Readers may value lower weight more than lower price, or have a requirement you did not include.

If you publish a score, disclose the included metrics, whether higher or lower values are preferable, the transformations and weights, and the treatment of missing values and ties. Otherwise, a precise-looking rank hides subjective choices. Use the public ranking disclosure checklist when ranking is necessary.

Publish a clean file, then check the reader’s view

Create a publication copy with one header row, no merged cells and no repeated headings inside the data. These practices align with GOV.UK’s accessibility and machine-readability guidance.

Before uploading, inspect hidden sheets, rows, columns and document properties, as the same guidance recommends. Remove private supplier quotes, personal contact details and other sensitive material. TablePage pages are public; upload only data intended for public release.

As of October 11, 2026, TablePage states that it accepts CSV, TSV, XLSX and XLS files and generates public dataset pages with filterable tables accessible without signup.

Publish the scope statement alongside the comparison, including the price basis, check dates and meaning of blank cells. After publication, check that numeric values remain numeric, filters behave as intended, unknown values remain distinguishable, and source links point to the correct variants. Try the example requirements yourself: can a reader separate a qualifying option from an unverified one?

Keep the most useful comparison fields prominent and test the page on a small screen. W3C’s table guidance recommends simple tables and preserving relationships between headers and data across display formats. The reader should be able to narrow the options without losing the evidence behind them.