Convert an Excel Table to HTML Code
Turn an Excel sheet into an HTML table ready to publish on any webpage — processed locally in your browser.
Drop your file here or click to browse
Excel files (.xlsx, .xls)
Your file stays on your device
Nothing to delete afterwards
Escaped output by default
Works in every modern browser
How it works
- 1
Drop your file
Add an .xlsx, .xls, or .csv file — drag it onto the page or click to browse.
- 2
Pick the sheet
Choose which sheet becomes the table and confirm which row supplies the headers.
- 3
Copy the markup
Paste it into a CMS, a documentation page, an email template, or a ticket.
Why use this tool
Markup you can actually read
A plain table with real structure, not thousands of lines of Office namespaces and inline styles.
Cell content is escaped
A `<` or `&` inside a cell is written as an entity, so it displays as text instead of breaking the page.
Real table semantics
Header cells become `th` inside a `thead`, which is what screen readers and sorting scripts rely on.
Merged cells map to spans
A merged range becomes `colspan` or `rowspan` rather than silently collapsing into blanks.
Nothing is uploaded
The workbook is read in your browser; a sheet of client or staff data never reaches a server.
Free, no account
No signup, no watermark, no cap on how many files you convert.
An HTML table is the one format that renders anywhere
This conversion exists because of a specific and stubborn problem: getting tabular data in front of people who cannot or will not open a spreadsheet. Attach an .xlsx to a support ticket and it becomes a download nobody clicks. Put it in a wiki and it sits as an icon. Paste it into an email and half your recipients get a paperclip. An HTML table has none of that friction — it renders in a browser, in a CMS, in a documentation page, in a knowledge base article, and inside most email clients, with no reader, no plugin, and no download step. What you are converting is not the data so much as its visibility. That is why the target is markup rather than a JSON array, which is for programs, or a CSV, which is for another spreadsheet.
Why Excel’s own “Save as Web Page” is not the answer
Excel will export HTML directly, and anyone who has tried it once remembers why they stopped. The output carries Office XML namespaces, conditional comments for versions of Internet Explorer that no longer exist, a stylesheet of generated class names, and inline styles on nearly every cell. A twenty-row table can produce several thousand lines. Worse, that markup fights whatever page it lands on: the hardcoded fonts, colours, and borders override your site’s design, and the class names collide with your own. A clean table is roughly one line per row, inherits your CSS, and can be read by a human in a diff. If the markup is going into a site you maintain, that difference is the entire point.
The character that ends up in a cell decides whether your page survives
Spreadsheets contain text people typed, and people type angle brackets. A product name like `<Special Edition>`, a note reading `a > b`, a company written `Smith & Sons` — each of these is ordinary in a cell and dangerous in markup, because `<` opens a tag and `&` opens an entity. Written straight through, the first swallows the rest of your table into an unknown element, and the third produces a validation error at best. Proper escaping turns them into `<`, `>`, and `&` so they display exactly as typed. This matters beyond tidiness: when a sheet contains anything users submitted, unescaped output is how a stored cross-site scripting problem gets built by accident. A converter that escapes by default removes the question.
Header cells are structure, not formatting
Making the first row bold does not make it a header. In HTML the distinction is real: a header cell is `<th>`, a data cell is `<td>`, and the header block is wrapped in `<thead>`. That structure is what a screen reader uses to announce “Price, 340” instead of reading a wall of unconnected numbers, and what sorting and filtering scripts look for when they attach to a table. It is also what search engines read when deciding whether your table is content worth understanding. A converter that emits `<td>` everywhere and applies bold to row one produces something that looks right and is, in accessibility terms, a grid of anonymous values. Adding `scope="col"` to the header cells costs nothing and completes the job.
Merged cells are the one thing that genuinely translates
Most spreadsheet features have no HTML equivalent, but merging is the exception, and it is worth knowing because the alternative is silent data loss. When four cells are merged in Excel, the value lives in the top-left one and the rest are empty; a naive conversion produces a value followed by three blanks and a row that no longer lines up. HTML has the same idea built in — `colspan` and `rowspan` — so a merged range can keep its exact shape in the markup. Everything else about the sheet is presentation and does not come along: conditional formatting, cell colours, comments, frozen panes, and column widths are all things you would restate in CSS if you wanted them, and usually you do not, because inheriting your site’s styling is the better outcome.
Where the markup is going changes what you should do with it
A table headed for a page you control wants exactly what this produces: bare markup that inherits your stylesheet. Email is the exception, and it is worth planning for. Most email clients strip `<style>` blocks and ignore external stylesheets, so a table that looks correct in a browser can arrive as unstyled rows in a colleague’s inbox — if it matters there, the styles have to be inlined on each cell after conversion. A CMS is the other case to watch: many editors sanitise pasted HTML and will quietly drop attributes, so paste into the source or code view rather than the visual one. Knowing the destination before you convert saves the round of confused debugging that otherwise follows.
Common mistakes to avoid
- Using Excel’s own “Save as Web Page”. The output carries Office namespaces, generated class names, and inline styles on every cell — it fights your site’s design and runs to thousands of lines for a small table.
- Pasting into a CMS visual editor. Many sanitise pasted markup and drop attributes silently; use the source or code view so `colspan` and `scope` survive.
- Expecting styling to arrive with the table. Cell colours, conditional formatting, and column widths are presentation and stay behind — that is deliberate, so the table inherits your CSS.
- Assuming a bold first row is a header row. Screen readers and sorting scripts look for `th` inside `thead`, not for font weight; without it the table is a grid of anonymous values.
- Sending an unstyled table to an email campaign. Most clients strip `<style>` blocks, so anything that must look styled in an inbox needs its CSS inlined per cell after conversion.
How it compares
| Aspect | This tool | Excel’s Save as Web Page | Online converters |
|---|---|---|---|
| Data sent to a server | Never | No | Usually yes |
| Output size for a small table | Tens of lines | Thousands | Varies |
| Inherits your CSS | Yes | No — styles are baked in | Varies |
| Semantic `thead` / `th` | Yes | Partly | Varies |
| Account or signup | Not needed | Not needed | Often required |
| Price | Free | Licence | Free / paid tiers |
Features
Reads .xlsx, .xls, and .csv
Whichever of the three you have, the output is the same clean table.
Semantic `thead` and `tbody`
The header row is marked as headers, not styled to look like them.
HTML entities handled
`<`, `>`, `&`, and quotes inside cells are escaped so the markup stays valid.
colspan and rowspan
Merged ranges keep their shape instead of leaving holes across the row.
UTF-8 output
Accented, Arabic, Turkish, and other non-ASCII text is written unchanged.
No styling imposed
The table inherits your page’s CSS instead of arriving with someone else’s design baked in.
Nothing to install
No Excel licence, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
Full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no file tracking and no third-party upload.
Who uses it
Technical writers
Getting a specification or comparison table into documentation without hand-typing every row.
Web developers
Turning a client’s spreadsheet into markup that inherits the site’s styling instead of fighting it.
Support teams
Putting a table inside a ticket or knowledge-base article where an attachment would go unread.
Content editors
Publishing a data table in a CMS without wrestling with the visual editor’s table controls.
Frequently Asked Questions
No. The conversion runs entirely in your browser — your data is never uploaded, stored, or shared.
Yes. Every row and column is converted faithfully; the structure is preserved.
Yes — completely free, with no account, no watermark, and no limit on how many files you convert.