HTML Table Generator

How to Use This HTML Table Generator

Building a table by hand means counting columns, nesting <thead> and <tbody> in the right order, and making sure every <th> is in the right place. This generator does all of that in under 60 seconds:

1. Set dimensions. Click + or − next to Rows and Columns. The default is 4 × 4 — go up to 20 rows and 10 columns.
2. Fill in your data. Click any cell and type. Press Tab to move to the next cell, or click directly.
3. Configure styling. Toggle "First row as header" to emit <th> elements. Enable Striped, Bordered, or Responsive for Bootstrap-compatible output. Add a Caption for accessibility.
4. Choose format. Click HTML, Markdown, or CSV above the output panel. Hit Preview to see your table rendered live.
5. Copy and paste. Click the Copy button and drop the code directly into your HTML file, Markdown document, or spreadsheet application.

All processing happens locally — nothing is sent to a server and no data is stored.

When to Use HTML Tables (and When Not To)

The right moment to reach for an HTML table is when your data is genuinely tabular — every row represents a record and every column represents the same attribute across all records. Good examples:

• Pricing tables: Three tiers (Basic, Pro, Enterprise) × five features (price, users, storage, support, API). The grid relationship is the whole point.
• Schedules and timetables: Columns are days, rows are time slots.
• Statistical data: Countries × GDP, population, area, and life expectancy.
• Comparison guides: Feature matrices, spec sheets, and compatibility charts.

Where you should not use a table:

• Page layout: Using <table> rows and columns to arrange a header, sidebar, and footer was a practice from the late 1990s. Modern CSS Grid and Flexbox handle layout — tables impose terrible maintenance costs and break screen readers.
• Single-column data: If you have one column, you want a <ul> or <ol>, not a table.
• Image galleries: Arranging images in a grid is a visual layout choice, not relational data — CSS Grid is the right tool.

Google and other search engines also reward semantic HTML. A table used for data improves crawlability because bots can understand the relationship between headers and cells. A table used for layout confuses both crawlers and accessibility tools.

HTML Table Structure Explained

Understanding what each element does helps you write better markup — with or without a generator.

<table>

The outer container. Add a class attribute here for Bootstrap utility styles (e.g. class="table table-striped").

<caption>

Goes immediately inside <table>. Screen readers announce the caption before reading any cells — think of it as an alt attribute for the whole table. Always add one to data tables.

<thead>

Groups header rows. Browsers repeat <thead> on each page when the table is printed — essential for long reports. Only one per table.

<tbody>

Groups data rows. You can have multiple <tbody> sections to segment large datasets logically (e.g. one per quarter).

<th>

A header cell. Browsers render it bold and centered by default. Add scope="col" for column headers and scope="row" for row headers — this is critical for screen reader users navigating large tables.

<td>

A data cell. Spans one row and one column by default. Use colspan and rowspan to merge cells (hand-write these — the generator produces simple tables with no merging).

A minimal, semantically correct table looks like this:

<table>
  <caption>Monthly Sales</caption>
  <thead>
    <tr>
      <th scope="col">Month</th>
      <th scope="col">Revenue</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>January</td>
      <td>$12,400</td>
    </tr>
    <tr>
      <td>February</td>
      <td>$14,100</td>
    </tr>
  </tbody>
</table>

Making Your Table Responsive

A fixed-width table overflows its container on small screens — the content is cut off or the browser shrinks the text to an unreadable size. The simplest fix is a scroll wrapper:

<div class="table-responsive">
  <table class="table">...</table>
</div>

This sets overflow-x: auto on the wrapper so narrow screens can scroll the table horizontally while the rest of the page layout stays intact. It is the Bootstrap convention, but it works without Bootstrap if you add style="overflow-x:auto" manually.

For tables where horizontal scrolling is awkward — like simple name/value tables on mobile — a card-layout technique works better. Each row becomes a labeled card via CSS display: block and data-label attributes on each <td>:

@media (max-width: 600px) {
  table, thead, tbody, th, td, tr { display: block; }
  thead tr { position: absolute; left: -9999px; }
  td { border: none; position: relative; padding-left: 50%; }
  td::before {
    content: attr(data-label);
    position: absolute; left: 0;
    font-weight: bold; width: 45%;
  }
}

The scroll wrapper (enabled by the Responsive checkbox above) is best for wide data tables with many columns. The card layout is best for simple 2–4 column tables where each row is a self-contained record.

Bootstrap Tables: A Quick Reference

Bootstrap 5 includes a comprehensive table system. All classes go on the <table> element (except table-responsive, which goes on the wrapper <div>):

• table — Required base class. Resets browser defaults and adds consistent padding.
• table-striped — Alternating background on even rows via :nth-child.
• table-bordered — Borders on all sides of every cell.
• table-borderless — Removes all borders for a clean, minimal look.
• table-hover — Highlights rows on hover.
• table-sm — Reduces cell padding for compact tables.
• table-dark — Dark background with light text.
• table-responsive — On the wrapper div, not the table. Enables horizontal scroll on all screen sizes.
• table-responsive-md — Enables horizontal scroll only below the md breakpoint (768 px). Replace with sm, lg, or xl as needed.

A common combination for data tables:

<div class="table-responsive">
  <table class="table table-striped table-bordered table-hover">
    ...
  </table>
</div>

Markdown Tables vs HTML Tables

GitHub-Flavored Markdown (GFM) tables use a pipe syntax that renders in README files, pull request descriptions, wikis, and platforms like Notion and Obsidian:

| Column A | Column B | Column C |
|----------|----------|----------|
| Data 1   | Data 2   | Data 3   |
| Data 4   | Data 5   | Data 6   |

Key rules for Markdown tables:

• The separator row (|---|) is required. The number of dashes doesn't matter.
• Align columns: |:---| left, |:---:| center, |---:| right.
• Pipes inside cell content must be escaped: \| (this generator handles it automatically).
• No support for colspan, rowspan, <caption>, or scope attributes.

Use Markdown for documentation, README files, wikis, and anywhere you write plain text and don't control the final HTML. Use HTML when you need responsive behavior, Bootstrap styling, a caption, or any accessibility attributes.

Common HTML Table Mistakes to Avoid

1. Using tables for page layout. Tables confuse screen readers, break responsive design, and hurt SEO. Use CSS Grid or Flexbox for layout.
2. Skipping <thead> and <tbody>. Browsers tolerate the omission, but assistive technology expects the structure. Always wrap your header row in <thead>.
3. Missing scope on <th> elements. Screen reader users navigating a large table need to hear whether a header applies to the current column or row. Add scope="col" or scope="row" accordingly.
4. No caption. A <caption> tells assistive technology what the table is about before the user reads any cells — the equivalent of alt text for images.
5. Not escaping special characters in cell content. Angle brackets (<, >) and ampersands (&) inside cell text can break the HTML. Use HTML entities or ensure your CMS handles escaping before inserting cell content into a template.
6. Putting table-responsive on the <table> element. Bootstrap's responsive wrapper must go on the parent <div>, not the table itself — a mistake that silently does nothing.
7. Making every table responsive unnecessarily. A two-column, three-row table embedded in a blog post doesn't need a scroll wrapper — the extra DOM nesting adds complexity with no benefit on any screen size.

Frequently Asked Questions