Almost every database import tool - from psql \copy to BigQuery's load jobs to a simple ORM seed script - expects CSV, not XLSX. Excel's binary-adjacent format is great for humans working in a spreadsheet, but it's not something most database tooling parses directly. Converting to CSV first is the standard bridge between "data in a spreadsheet" and "data in a table."
Why databases prefer CSV over XLSX
XLSX is technically a ZIP archive of XML files describing sheets, styles, formulas, and metadata - a rich format built for spreadsheet applications, not database engines. CSV, by contrast, is about as simple as tabular data gets: one line per row, values separated by commas. That simplicity is exactly what makes it universally supported - every major database's bulk-import tool, every ETL pipeline, and every scripting language can read CSV with zero special libraries.
Importing XLSX directly would require the database tool to understand Excel's internal format, parse out styling and formulas, and decide what to do with multiple sheets - complexity that CSV sidesteps entirely by only ever representing one flat table.
What gets lost (and preserved) in the conversion
Converting XLSX to CSV is lossless for the data itself - every cell value carries over - but it does discard everything CSV has no concept of: cell formatting (colors, bold, borders), formulas (converted to their last calculated value, not the formula itself), multiple sheets (only one sheet exports per CSV file), and charts or embedded objects. For a database import, this is exactly the right trade-off: databases store values, not formatting, so nothing meaningful is actually lost for that use case.
Step-by-step: XLSX to CSV in your browser
1. Confirm your data is on the first sheet (or the sheet you intend to import), since a single conversion pass exports one sheet at a time.
2. Drop the file into the converter. Using the XLSX to CSV tool, your file is parsed locally using SheetJS, entirely in the browser - nothing is uploaded.
3. Download the CSV and inspect the first few rows before importing, especially checking that headers ended up in row one and that no stray blank rows were included.
Preparing CSV for PostgreSQL, MySQL, and BigQuery
Most databases are picky about a few specific things in CSV: consistent column counts across every row, a clear decision about whether the first row is a header (most bulk-load commands have a flag for this, like PostgreSQL's COPY ... WITH (FORMAT csv, HEADER)), and consistent date formatting, since spreadsheet date formats often don't match a database column's expected format and need reformatting before import.
BigQuery in particular auto-detects schema from CSV headers when using its load UI or bq load --autodetect, which makes a clean, well-headered CSV export from XLSX especially convenient - the schema step becomes nearly automatic.
Handling large spreadsheets and multiple sheets
If your workbook has multiple sheets you need imported as separate tables, you'll need to convert each sheet individually - export, switch the active sheet in your source file, export again. For very large spreadsheets (tens of thousands of rows), browser-based conversion still works but may take a moment longer since parsing happens using your device's own memory rather than a server's.
If your end goal is actually an API or application rather than a relational database, it's often more useful to skip CSV entirely and convert straight to XLSX to JSON, which produces the same row-per-object structure without an intermediate CSV step.