When to Use Tables (and When Not To)
Knowing what a table can do is only half the skill. Knowing when to reach for it — and when to use something else — is just as important.
What qualifies as tabular data
Section titled “What qualifies as tabular data”Tabular data has a meaningful relationship across both rows and columns. You need both axes to understand any single data point.
Ask yourself: “Does this cell only make sense when you know both its column header and its row header?”
If yes, it is tabular data. A table is the right choice.
Good candidates for a table:
| Content type | Example |
|---|---|
| Schedule | Class times by day of the week |
| Pricing comparison | Plan features across price tiers |
| Data comparison | Trail ratings by distance and difficulty |
| Statistics | Player stats by game and category |
| Specification sheet | Product attributes and their values |
In each case, understanding a single cell requires knowing both where it sits in the row and what column it falls under.
When tables are not appropriate
Section titled “When tables are not appropriate”Page layout is the most common misuse. Developers once used <table> to arrange multi-column layouts because it was the only reliable way to do so before CSS matured. That technique is now obsolete.
Do not use <table> for:
- Multi-column page layouts
- Side-by-side image grids
- Navigation menus
- Card or tile arrangements
- Any visual positioning that has nothing to do with data relationships
These should all be handled with semantic HTML elements and CSS. The table elements exist to represent data, not to control how things look on screen.
Why misusing tables harms your page
Section titled “Why misusing tables harms your page”Accessibility: Screen readers announce table structure. A <table> with four cells used for layout will be announced as “table with 2 rows, 2 columns” — which is meaningless and confusing to a user who is trying to navigate content.
Maintainability: Layout built inside table cells is rigid. Changing it requires touching deeply nested HTML. CSS-based layout can be changed in one place.
Responsiveness: Tables do not shrink gracefully on small screens. A properly structured layout using CSS adapts to any screen size without extra work.
The decision rule
Section titled “The decision rule”If the content requires rows and columns to make sense, use a table. If you could represent the same content without rows and columns, do not use a table.
| Ask yourself | If yes | If no |
|---|---|---|
| Does this data have column labels? | Leaning toward table | Probably not a table |
| Does this data have row labels? | Leaning toward table | Probably not a table |
| Would removing a row or column destroy meaning? | Table | Not a table |
| Am I doing this to control layout? | Not a table | Proceed |
Exercise
Section titled “Exercise”Open index.html in VS Code — but do not make any changes yet.
Look at the table you built in the previous lessons. Then look at the rest of your page content: the sections, lists, and description list.
For each of the following content types, decide: table or not a table?
- A list of gear items you pack for a hike
- A comparison of three trail difficulty ratings (Easy, Moderate, Strenuous) showing distance and elevation for each
- A navigation menu linking to pages on your site
- A weekly hiking schedule showing the trail name and time for each day of the week
- A glossary of trail terms and their definitions
Think through each one before checking your reasoning:
- List of gear — No column relationship. Use
<ul>. - Difficulty comparison — Rows (ratings) × Columns (distance, elevation). Table.
- Navigation menu — This is structural, not data. Use
<nav>+<ul>. - Weekly schedule — Rows (days) × Columns (trail, time). Table.
- Glossary — Term–definition pairs. Use
<dl>.
If your existing table fits one of these “table” scenarios, it is correctly placed. If it does not, consider whether a list or description list would be a better fit — and make the change.
- Tabular data has a meaningful relationship across both rows and columns.
- Good use cases: schedules, pricing charts, comparisons, statistics, spec sheets.
- Never use
<table>for layout — it harms accessibility, maintainability, and responsiveness. - The test: does a cell only make sense when you know both its row and its column? If yes, use a table.