Excel to SQL: Turning a Spreadsheet into a Real Database Table

A lot of real business data starts life in a spreadsheet, not a database — a customer list someone built in Excel, a pricing sheet maintained by hand, an inventory export from another system. Turning that into an actual SQL table mostly comes down to cleaning up a few things Excel does differently from a database.

Header row = column names, so clean it up first

The first row becomes your column list, and SQL identifiers have rules spreadsheet headers don't: no spaces, no leading digits, and dialect-specific reserved words (order, group, user) need quoting or renaming. "Customer Name" needs to become something like customer_name before or during conversion — check the generated column names rather than assuming they're already valid.

Merged cells and formatting break more than they help

• A merged cell (a category header spanning several rows, say) is visually clear in Excel but only actually has a value in its first cell — the rest read as blank once flattened into rows, which isn't usually what you want for a data table.
• Cells formatted as currency or with thousands separators ($1,250.00) can come through as text rather than a number if the underlying value includes the formatting characters rather than being a plain numeric cell.

Excel dates are a common source of silently wrong data

Excel stores dates internally as a serial number (days since December 30, 1899) and only shows a formatted date because of cell formatting — if that formatting doesn't carry through cleanly, a date column can come out as a meaningless five-digit number instead of a date. Worth spot-checking a date column in the output before trusting it, especially for a sheet that's been copy-pasted between files a few times (a common way date formatting quietly breaks).

One sheet at a time

A workbook with multiple sheets — a "Customers" tab and a "Products" tab, say — needs to be converted one sheet at a time into one table at a time. Make sure you're converting the sheet you think you are, especially in a workbook where the visible tab isn't always the first one.

Treat the inferred schema as a first draft

Whatever types get inferred from a spreadsheet — text, integer, decimal, date — are a reasonable starting point, not a schema you should assume is correct without looking. Spreadsheets mix formats within a column more often than CSVs do (a mostly-numeric ID column with one row typed in as text, for example), so it's worth a quick read-through of the generated CREATE TABLE statement before running it against a real database.

Paste your spreadsheet below

Excel to SQL below reads your spreadsheet directly in the browser — nothing is uploaded anywhere — and generates a CREATE TABLE statement plus INSERT rows you can review before running.