SQL to XLSX is a lightweight dump parser for INSERT rows, not a database restore followed by a relational export.
From real runs
| Element | Result | What happens |
|---|---|---|
| Workbook output | Changed | The API returned a 16,363-byte XLSX with one sheet named orders after parsing the tested two-table dump. |
| Multi-row inserts | Kept | The orders INSERT with two tuples produced two workbook rows for ids 10 and 11. |
| NULL | Changed | SQL NULL values became blank worksheet cells, including the final orders total. |
| Escaped quotes | Kept | The parser unescaped doubled apostrophes, so the users note displayed as Ada's first import in the workbook inspection. |
| Multiple tables | Changed | Rows from users and orders were combined into a single sheet rather than separate worksheets. |
| Column alignment | Lost | Earlier users rows were placed under the later orders headers id, user_id, and total, leaving the notes value in an extra cell beyond the header. |
| Database schema | Lost | CREATE TABLE types, constraints, indexes, and table boundaries were not preserved as workbook metadata. |
The API returned a 16,363-byte XLSX with one sheet named orders after parsing the tested two-table dump.
The orders INSERT with two tuples produced two workbook rows for ids 10 and 11.
SQL NULL values became blank worksheet cells, including the final orders total.
The parser unescaped doubled apostrophes, so the users note displayed as Ada's first import in the workbook inspection.
Rows from users and orders were combined into a single sheet rather than separate worksheets.
Earlier users rows were placed under the later orders headers id, user_id, and total, leaving the notes value in an extra cell beyond the header.
CREATE TABLE types, constraints, indexes, and table boundaries were not preserved as workbook metadata.
orders with header ["id","user_id","total"], then a users row ["1","ada@example.com","2026-09-10T18:30:00Z","Ada's first import"].["10","1","1250.5"] and ["11","2"], with the null total represented by a blank trailing cell.We converted our SQL sample (455 B) with Table engine on 2026-10-20. It took 1 ms and produced a 17 KB Excel XLSX file, 38× larger than the input. The engine raised no warnings.
Input · sample.sql · 455 B
1 CREATE TABLE, 4 INSERT statements
Output · sample.xlsx · 17 KB
Workbook with 1 sheet (pipeline); first sheet 5 rows, 25 cells, 0 formulas, header filter, fitted column widths
sqlite3 and pandas
sqlite3 scratch.db < dump.sql
python - <<'PY'
import sqlite3, pandas as pd
con = sqlite3.connect("scratch.db")
pd.read_sql_query("select * from orders", con).to_excel("orders.xlsx", index=False)
PYThis executes the dump locally; use a disposable database and export each table deliberately.
The HTTP API and the MCP server run the exact engine this page uses (Table engine); the response carries the same warnings the web converter shows. Check support first with GET /api/v1/pairs?from=sql&to=xlsx.
curl -X POST https://filetypeconverters.com/api/v1/convert \
-H "Authorization: Bearer $FTC_API_KEY" \
-F "file=@input.sql" -F "from=sql" -F "to=xlsx" \
-F 'options={"encoding":"utf-8"}' \
--output output.xlsx| Key | Applies to | Type | Default |
|---|---|---|---|
| encoding | Reading SQL | utf-8 · latin1 | utf-8 |
| sheetName | Writing Excel XLSX | string |
/convert/sql-to-json when an API consumer needs objects rather than an Excel workbook.Not in the current parser path. Our two-table dump came back as one sheet named orders, with users rows mixed into the same worksheet.
They become blank cells. In the orders row with total NULL, workbook inspection showed no value in the final total position.
No. It parses simple INSERT values and writes a workbook. It does not execute DDL, build indexes, evaluate expressions, or enforce constraints.