Spec Tables: Format, Rules, and Examples

A spec table turns facts about one subject into explicit label–value pairs. A reader can find the operating temperature without rereading a product description, and a machine can retain the relationship between “Operating temperature” and “−10 to 45 °C” without guessing which number belongs to which claim.

The product name and values above are illustrative. The structure is the production model: one subject, one precise label per row, one value with its unit, and an explicit status where a factual value cannot be supplied.

Why this element matters

Specification prose makes readers perform avoidable reconstruction. Consider: “The unit weighs 6.4 kilograms, delivers 500 watts continuously, measures 280 by 190 by 210 millimeters, and can operate from minus 10 to 45 degrees Celsius.” The sentence is grammatical, but a buyer looking only for dimensions must parse every clause. Returning later to check the output means parsing it again. A table moves the labels into a predictable edge and the values into a second column, reducing memory work and making scanning reliable.

The structure matters just as much to machines. Machine extractability is the ability of a crawler, search system, assistant, or downstream publishing tool to preserve the meaning and relationships in content. Native <table>, <th scope="row">, and <td> markup states that the row header qualifies the adjacent value. It produces a dependable pair: “Usable capacity — 512 Wh.” The same two strings embedded among promotional sentences require language-level inference, and a styled collection of unrelated <div> elements may expose visual alignment without exposing a data relationship.

Queryable does not mean that every website becomes a database. It means each fact has a stable label, a discrete value, and predictable markup, so a reader or system can ask for one property without extracting the whole paragraph. Comparable means separately published products can use the same canonical labels and units, allowing values to be aligned later without first normalizing “about half a kilowatt,” “500 watts,” and “0.5 kW.” A spec table enables that later comparison; it is not itself a comparison unless it presents multiple subjects side by side.

When to use it

Use a spec table when the page describes one entity and readers need at least three discrete, verified facts. Typical subjects include a product, software plan, API, file format, facility, vehicle, organization, service package, or technical standard. Suitable facts have bounded answers: dimensions, supported operating systems, connector type, response format, warranty period, legal name, coverage area, version, or a stated limit.

Use prose around the table to explain consequences. “Maximum payload: 18 kg” belongs in the table; why that limit rules out a particular installation belongs in prose. The table should answer “what is the value?” while the surrounding explanation answers “why does it matter?”

Near-miss cases are common:

• When two or more products must be judged on shared criteria, use a comparison table instead. A spec table has one subject; adding several value columns changes its purpose.
• When the content is a sequence of events, use a timeline. Dates in a two-column table do not automatically make the relationships chronological.
• When each row needs several sentences of interpretation, use headings and prose. Dense paragraphs inside cells defeat scanning and become difficult on narrow screens.
• When the list contains only two simple facts, use a sentence or definition list unless the post type requires a registered spec table. A table should create retrieval value, not decorate a small fact.
• When values update continuously, connect the element to an owned data source and show a retrieval time. A manually copied “live” value becomes misleading as soon as it drifts.
• When the document describes field names, types, and validation constraints, use the grouped variant below; do not squeeze the entire data model into one prose-heavy “Details” cell.

The element writing rules take precedence: choose the element by the passage’s purpose, not by its heading or appearance. If a block’s job is to expose specifications, it remains a spec table even when the theme could render the same words as cards.

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

Place the first spec table after the subject has been identified and before the page asks the reader to interpret, configure, compare, or buy it. On a product page, that normally means after the concise product description and key benefit, but before detailed feature explanations. In documentation, put a prerequisite or protocol table immediately before the procedure that relies on it. Readers need to know what the values describe before seeing them, yet should not have to cross a long narrative to retrieve them.

If the page has several categories, place each table beneath a descriptive H2 or H3 such as “Physical specifications” or “Compatibility.” Keep the category title outside the table; the caption then names the precise subject and scope. Preserve the same label order across sibling pages so a reader does not have to relearn the pattern.

Do not place a spec table directly beside another dense table, a full-width screenshot, or an animated carousel. Two competing grids create an unclear reading path and are especially awkward at tablet widths. Do not insert a call to action between a caption and its rows, put footnotes inside an unrelated component, or place a promotional claim in the value column. Keep the caption, table, status legend, verification date, and source note as one bounded unit. Follow it with explanation before introducing another data-heavy element.

Anatomy

The labelled capture must identify these parts:

1. Section heading: names the category when a page has more than one table, such as physical or electrical specifications.
2. Caption: identifies the subject and the exact scope of the table. It must make sense outside the surrounding paragraph.
3. Row header: uses the canonical, unambiguous name of one property.
4. Value: contains one fact rather than commentary or a sales claim.
5. Unit: appears with every numeric value unless the value is genuinely unitless.
6. Status value: spells out “Unknown” or “Not applicable” rather than leaving an empty cell.
7. Verification date: states when volatile facts were last checked.
8. Source note: identifies the primary system, document, test, or owner from which the values came.

Unknown means the property applies but no trustworthy value was available at verification time. Not applicable means the property’s premise does not apply to this subject. Not available is different again: it means a capability or option is absent. Zero is a measured or declared value. A blank cell communicates none of these meanings and is therefore not permitted.

Stay Updated on AI Visibility Trends

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

Email address

Subscribe

Design examples

Every design variant retains native table markup, row headers, visible labels, text values, and a caption. Styling may change density and grouping, but it cannot turn the facts into an image or make color carry meaning alone.

Standard two-column: the default for one subject and three to twelve facts. Labels occupy the first column and values the second. Use it for product, company, plan, and service facts.

Grouped: two or more short tables divide a larger specification set by reader task. Each group receives a heading and each table retains its own caption. Do not use merged separator rows as visual headings because they complicate navigation and extraction.

Field reference: a documentation variant for properties whose meaning requires consistent secondary fields such as type, requirement, and constraint. The first column uses row-header semantics, while each secondary dimension has a column header.

Compact mobile: labels and values wrap naturally without reducing type size. A simple two-column table should reflow within its container. A wider field-reference variant may scroll inside a labelled, keyboard-focusable region; it must not make the entire page scroll horizontally.

Parameters

The following contract defines the portable element. “Source” in the last column states where the renderer obtains the parameter, not where the factual claim was researched.

Use verified whenever price, compatibility, availability, version support, capacity, or another value can change. A publication date is not a substitute: it says when the page was released, not when the specification was checked.

Syntax and code examples

All implementations map to the same caption, ordered rows, status meanings, verification value, and source. The portable directive is the canonical authored form.

Portable Markdown directive

:::spec-table{caption="Northstar Field 500 — core specifications" verified="2026-08-27"}
| Specification | Value |
|---|---|
| Usable capacity | 512 Wh |
| Continuous AC output | 500 W |
| Dimensions (W × H × D) | 280 × 190 × 210 mm |
| Water-resistance rating | Unknown |
| Fuel type | Not applicable |

Status: Unknown = relevant but not verified; Not applicable = cannot apply.

Source: approved product data sheet, revision 4.
:::

Hugo shortcode

The Hugo adapter should accept named parameters only and render the pipe-table body as semantic table rows. The notation below defines the intended mapping; it does not imply that a new local shortcode should be created inside an article task.

{{< spec-table caption="Northstar Field 500 — core specifications" verified="2026-08-27" >}}
| Specification | Value |
|---|---|
| Usable capacity | 512 Wh |
| Continuous AC output | 500 W |
| Dimensions (W × H × D) | 280 × 190 × 210 mm |
| Water-resistance rating | Unknown |
| Fuel type | Not applicable |

Status: Unknown = relevant but not verified; Not applicable = cannot apply.

Source: approved product data sheet, revision 4.
{{< /spec-table >}}

The renderer must output <table>, <caption>, <tbody>, <th scope="row">, and <td>. A field-reference variant also needs <thead> with scope="col" headers. It must preserve minus signs, multiplication signs, unit spacing, and status text exactly.

WordPress block

<!-- wp:amicited/spec-table {"caption":"Northstar Field 500 — core specifications","verified":"2026-08-27","variant":"standard"} -->
<table>
  <tbody>
    <tr><th scope="row">Usable capacity</th><td>512 Wh</td></tr>
    <tr><th scope="row">Continuous AC output</th><td>500 W</td></tr>
    <tr><th scope="row">Dimensions (W × H × D)</th><td>280 × 190 × 210 mm</td></tr>
    <tr><th scope="row">Water-resistance rating</th><td>Unknown</td></tr>
    <tr><th scope="row">Fuel type</th><td>Not applicable</td></tr>
  </tbody>
</table>
<p class="spec-table__status">Unknown = relevant but not verified; Not applicable = cannot apply.</p>
<p class="spec-table__source">Source: approved product data sheet, revision 4.</p>
<!-- /wp:amicited/spec-table -->

A WordPress implementation may use editable block controls rather than literal HTML, but its saved attributes and server-rendered output must preserve the same contract. Authors must not substitute a screenshot or a generic columns block.

Examples

Good: complete, normalized product facts

Verified: 27 August 2026. Source: illustrative approved installation sheet, revision 2.

This works because the caption identifies one subject and one context. Every label names a testable property, ranges retain their units, dimensions do not mix systems, and maximum power is distinguished from typical power. “Not applicable” is justified because a wired sensor has no battery to replace; it does not hide an unknown battery specification. The table can be scanned by a person, navigated by row header, or transformed into discrete property–value pairs.

Bad: ambiguous pseudo-data

The bad table looks organized but does not provide dependable data. “Power” could mean supply voltage or consumption, while “Low” is not measurable. Cable length lacks a unit. The temperature row does not name Celsius or Fahrenheit and appears to mix a range with a degree symbol. “Rugged” is promotional language rather than an ingress-protection rating. The blank battery cell does not say whether the fact is unknown, irrelevant, zero, or accidentally omitted. The compatibility claim bundles an undefined population and installation judgment into one cell.

Repair it by splitting broad labels into canonical properties, obtaining values from a named primary source, adding a unit to every measurement, and replacing blanks with the correct status. If the source does not state the ingress rating, write “Unknown”; do not convert marketing language into an invented technical value.

Schema markup and accessibility

There is no general Schema.org type for a specification table. The table remains valuable semantic HTML even when it produces no JSON-LD. When the enclosing page represents an eligible entity, map only exact, verified facts to supported properties: for example, a product’s sku, weight, width, height, depth, material, or additionalProperty entries where appropriate. Organization facts may map to properties such as legal name or address. The visible table and structured data must agree, use the same units, and come from the same source. Do not invent ratings, offers, identifiers, or schema properties because a row exists.

Accessibility begins with real markup. Give the table a descriptive <caption>. Use <th scope="row"> for each specification label; field-reference variants also need <th scope="col"> in a <thead>. Keep the reading order logical in source, not only on screen. Do not use blank cells, merged cells, icon-only statuses, color-only grouping, or tooltips as the sole location of a value. Abbreviations such as AC, DC, and IP should be expanded in nearby prose when the intended audience may not know them.

A basic two-column table should wrap rather than scroll whenever practical. When a wider table requires horizontal scrolling, contain it in a region with an accessible label and tabindex="0", preserve a visible keyboard focus indicator, and never lock the first column in a way that covers values at high zoom. Test at 200% zoom, with keyboard navigation, and with styles disabled; the label–value relationship must survive all three.

Writing rules

The rules protect retrieval and comparison, so precision comes before compactness:

• Use 3–12 rows per table. Split longer sets by reader task—physical, electrical, compatibility, commercial—rather than creating an undifferentiated wall of facts.
• Keep labels to 1–6 words where possible. Use a qualifier such as “maximum,” “typical,” “installed,” or “per user” when it changes the meaning.
• Keep a normal value to one line and no more than 12 words. Move interpretation, exceptions, and recommendations into adjacent prose or a directly associated note.
• Use one measurement system per table unless the audience genuinely needs both. When both are required, present the primary value first and the conversion in parentheses for every applicable row.
• Put a unit beside every numeric measurement: 512 Wh, 3 m, and 45 °C. Never rely on a heading to supply a unit to only some rows.
• Normalize equivalent properties across sibling pages. Choose one label and one unit—such as “Weight” in kilograms—and do not alternate with “Mass,” pounds, or vague phrases without a documented reason.
• Use exact status words: Unknown, Not applicable, or Not available. Define them once when more than one status appears. Never use a dash, empty cell, TBC, question mark, or color to imply status.
• Use a factual, neutral tone. Values may be favorable, but words such as “amazing,” “ultra-fast,” “best-in-class,” and “generous” are conclusions, not specifications.
• Never put calls to action, testimonials, paragraphs of sales copy, unexplained scores, unsupported comparisons, or decorative images inside a value cell.
• State the source and an exact verification date for volatile or externally asserted values. If ownership is unclear, the table is not ready to publish.

Post types that use it

The postTypes frontmatter field drives the approved uses below. Inclusion means the post type may require or benefit from the element; it does not mean every page must manufacture three facts to satisfy a layout.

QA checklist

• The table describes one clearly identified subject; multiple options have not been disguised as a spec table.
• The caption names both the subject and the table’s scope.
• Every property uses a precise, canonical label and every cell contains one value.
• Numeric values include consistent units, qualifiers, ranges, and dimensions.
• No cell is blank; Unknown, Not applicable, and Not available are used only with their defined meanings.
• Claims match a named primary source, and volatile facts show an exact verification date.
• The published output uses native <table>, <caption>, row headers, and data cells rather than an image or visual grid.
• Field-reference variants include column headers and preserve all header relationships.
• The table works at narrow widths, 200% zoom, with keyboard navigation, and with styles disabled.
• Color, icons, abbreviations, and tooltips are never the only way to understand a value.
• Visible facts and any eligible Schema.org properties agree exactly.
• Promotional claims, interpretation, calls to action, and long prose sit outside the table.
• The element follows the playbook precedence rule and the selected post type includes the element in its content contract.