HTML tables have a reputation for being an outdated, clunky way to display data, largely because of their long-abandoned misuse for entire page layouts in the early web — but for genuinely tabular data (rows and columns of related values), a properly structured HTML table remains the correct, accessible, and universally supported choice, no framework or JavaScript library required. This guide covers what proper table structure actually looks like and when a table genuinely is the right tool.
The core elements of a proper table
A well-structured HTML table uses a specific set of semantic elements, each serving a distinct purpose that plain, unstructured markup cannot replicate. The <table> element wraps the whole structure. <thead> contains the header row (or rows), separate from the body content, which matters both for styling and for accessibility. <tbody> contains the actual data rows. Within each section, <tr> defines a table row, <th> defines a header cell (used within the header row, and sometimes for row labels within the body), and <td> defines a standard data cell. Using these elements correctly — rather than, say, styling plain <div> elements to merely look like a table visually — is what gives a table its actual semantic meaning, which both assistive technology and search engines rely on to understand the data's structure.
Why the header/body distinction matters
Separating header cells (<th>) from data cells (<td>) is not just a styling convenience — screen readers use this distinction to announce column headers when a user navigates through data cells, so a visually impaired user moving through a table of, say, product prices hears the relevant column header alongside each value, rather than an undifferentiated list of numbers with no context about what each one represents. A table built entirely from generic cells with no semantic header distinction loses this accessibility benefit entirely, even if it looks visually identical to a properly structured table for a sighted user.
Making a table readable and scannable
Beyond correct semantic structure, a few practical touches make a table genuinely easy to read at a glance. Alternating row background colors (often called "zebra striping") help a reader's eye track across a wide row without losing their place, particularly in tables with many columns or dense data. Right-aligning numeric columns (rather than the default left alignment) makes columns of numbers visually easier to compare, since digits line up consistently by place value. Adequate cell padding prevents a dense table from feeling cramped and hard to parse visually, which matters especially on smaller screens where table content is already fighting for limited horizontal space.
Handling tables on small screens
A table with many columns is one of the genuinely difficult layout challenges on mobile, since a table's fundamental structure — many columns side by side — does not naturally compress to a narrow screen the way flowing text does. Common approaches include allowing the table to scroll horizontally within its container (keeping the table structure intact but requiring a horizontal swipe or scroll to see all columns), or restructuring the presentation entirely for small screens (stacking each row's data vertically with labels, effectively turning each row into its own small card). Neither approach is universally superior — a horizontally scrolling table preserves the table's comparative structure but requires extra interaction, while a stacked-card presentation is easier to read on mobile but loses the direct visual comparison across a row that a table format naturally provides.
Building a table quickly
For a one-off table — inserting a data comparison into a blog post, a documentation page, or a report — manually writing out the full semantic HTML structure by hand, row by row, is tedious and error-prone, especially for anything beyond a handful of rows. The HTML Table Generator lets you build a table visually (entering headers and row data directly) and exports the correctly structured HTML markup, including the proper header/body distinction described above, without needing to hand-write the semantic tags for every row and cell.
When a table is the wrong choice
Not every collection of related information belongs in a table — if the data is not genuinely tabular (rows and columns of comparable values across consistent categories), forcing it into a table structure often produces an awkward, hard-to-read result compared with a more natural format like a list, a set of cards, or plain prose. And for data whose relationships or trends matter more than the exact individual values — a trend over time, a proportional comparison — a visual chart frequently communicates the point far more immediately than a table of raw numbers ever could; the Chart Generator is the better tool whenever the goal is showing a pattern or comparison at a glance rather than presenting precise, individually referenceable values.
Sorting and interactive features without a framework
Basic table interactivity — allowing a reader to click a column header to sort the data, for instance — is sometimes assumed to require a JavaScript framework or table library, but for a table with a modest number of rows, a small amount of plain, dependency-free JavaScript can implement sortable columns perfectly well without pulling in a large external library purely for this one feature. Reserve an actual table-focused framework or library for genuinely complex requirements — very large datasets needing virtualised scrolling for performance, advanced filtering across many columns simultaneously, or live-editable cells — since for the much more common case of a modest, mostly static data table, plain semantic HTML with a touch of vanilla JavaScript remains both lighter-weight and easier to maintain than an added framework dependency.
Styling without a framework
A clean, professional-looking table needs surprisingly little custom styling — consistent borders or subtle row dividers, adequate padding, a distinct header style (often a background color or bold text), and the alignment conventions described above cover the vast majority of what makes a table look polished, all achievable with plain CSS and no framework dependency at all. For any interactive elements placed near or within a table (an action button in each row, for instance), the CSS Button Generator produces consistent, framework-free button styling that matches the same lightweight, dependency-free approach.
Key takeaways
- Use proper semantic elements (thead/tbody, th/td) — they matter for accessibility and structure, not just visual appearance.
- Zebra striping, right-aligned numbers, and adequate padding make a table genuinely easier to scan.
- On mobile, choose between horizontal scrolling (preserves structure) or a stacked-card layout (easier to read) — neither is universally better.
- Use a table only for genuinely tabular data — a chart or a different format often communicates trends and patterns better.