To open an HTML document in Excel, start Excel, choose File, then Open, set the file type filter to All Files, and pick the .html file. Excel parses the markup and lays out any tables as rows and columns.
Double clicking is not how to open an HTML document in Excel. The .html extension belongs to a browser, so the page renders in a browser tab and Excel never sees the file.
The import is reliable for tables and lossy for everything else. This guide covers what survives, what does not, and when a plain copy and paste is the faster answer.
How to open an HTML document in Excel: two routes
| Route | Use when | Result |
|---|---|---|
| File, Open | The file is on your machine | Tables become sheets, styling mostly dropped |
| Data, From Web | The page is at an address | Table picker, and the query can be refreshed |
| Copy and paste from a browser | You need one table | Rows and columns kept, nothing else touched |
| Drag the file onto Excel | Quick look | Same as File, Open |
Data, then From Web is the better route for anything you will need again. It stores the address as a query, so a later Refresh All pulls the current numbers instead of re-running the import by hand.
It also gives you a table picker. A page with several tables is presented as a list, and you take the one you want rather than importing the whole document and deleting the rest.
The catch is that it needs an address. A file sitting on your desktop has no address, so that route only opens once the page is served from somewhere.
What survives the import
Excel maps HTML table elements onto the grid. A <table> with <tr> rows and <td> cells arrives intact, including merged cells built with colspan.
Everything else is treated as loose text or discarded. That includes charts, tabs, buttons, sorting, and most of the appearance.
| In the HTML | In Excel |
|---|---|
<table> rows and cells |
Rows and columns |
| Headings and paragraphs | Text in single cells |
| Number formatting from CSS | Lost, values come in raw |
| Charts drawn by script or SVG | Not imported |
| Tabs, filters, sort buttons | Not imported |
| Images | Sometimes placed, often missing |
Numbers are the part to check first. A cell reading 1,240 may arrive as text rather than a number if the page included the separator as characters.
Sort a column to find out. Text sorts as text, so 9 lands above 1,240 and the order is visibly wrong.
Dates have the same problem in a quieter form. A date written as 03/04 in the page arrives as whatever your regional setting decides it means, and nothing on screen says which reading was applied.
Encoding is the third thing to glance at. If the page declared UTF-8 and the import shows accented characters as symbols, re-import and set the file origin explicitly in the dialog.
When the page gives Excel nothing to work with
If the import produces one long column, the page did not use a real table. Modern report generators often lay figures out with <div> blocks and CSS grid, which looks like a table on screen and is not one in the markup.
Confirm it by opening the file in a text editor and searching for <table. No match means no import.
In that case the practical route is to select the block in a browser, copy, and paste. The browser hands over a rendered layout, and Excel reconstructs a grid from it.
The .xls file that is really HTML
A common case has nothing to do with opening HTML on purpose. An export from a reporting tool or a database client arrives named report.xls, and Excel warns that the file format does not match the extension.
That file is HTML. The tool wrote a web table and gave it a spreadsheet extension so it would open in Excel.
- Choose Yes to open it anyway. The content is legitimate.
- Check the numbers arrived as numbers, not text.
- Save it as
.xlsxstraight away. - Keep the original if the export cannot be repeated.
Until step three, the file on disk is still markup. Formulas you add will not survive a save.
Going the other direction
Excel can also write HTML, through Save As with Web Page as the type. The output is verbose, carries a great deal of Office specific markup, and often drags along a folder of supporting files.
If the point is to send a table to someone who does not have Excel, a cleaner route is to put the table on a page and send a link.
An editable HTML table produces markup you can paste anywhere, and turning a table into a link covers the sharing side.
Pasting that HTML into a NOS document renders it as a page of its own with a working address. The reader opens it in a browser on any device, and the cells stay clickable so a corrected figure does not mean a new file.
Choosing the route
- One table, needed once. Copy from the browser, paste into the sheet.
- One table, needed weekly from the same address. Data, From Web, then refresh.
- A whole report with charts. Excel is the wrong destination. Read it as a page, and see opening an HTML report.
- A file named .xls that opens as a web page. Open it anyway, then save as
.xlsx. - Data that has to reach people who will not open a spreadsheet. Put it on a page and send the address.
The rule underneath all of these: Excel wants a grid. If the HTML contains a real grid, the import is dependable. If it does not, no amount of import settings will invent one.