Paste CREATE TABLE + INSERT statements, edit data inline, then download a ready-to-open.xlsx file. All parsing happens in your browser — your SQL never leaves your device.
MySQL, PostgreSQL and SQLite CREATE TABLE / INSERT are all parsed correctly. Identifiers can be wrapped in backticks, double quotes or square brackets. Multi-row INSERT (VALUES (...), (...), (...)) is supported.
No. Parsing and.xlsx generation both happen entirely inside your browser via JavaScript. The resulting file is saved directly to your device.
Click any cell to edit · Tab to move · Enter to go down · Esc to cancel
Fast, private, zero install — turn SQL dumps into a ready-to-open Excel workbook.
One sheet per CREATE TABLE / INSERT target table. Column names come from CREATE TABLE, or are inferred from the INSERT column list.
Produces a genuine Office Open XML.xlsx file. Opens cleanly in Excel, Numbers, LibreOffice and Google Sheets.
All parsing and workbook generation happen in your browser. Your SQL is never uploaded to our servers.
Numbers stay numeric (right-aligned), booleans stay booleans, NULL stays blank, strings stay text. No silent conversion to dates.
Understands MySQL, PostgreSQL and SQLite syntax: backticks, double-quoted identifiers, escaped strings, multi-row INSERT.
Click any cell to edit data before downloading. Add or delete rows and columns, rename headers, and remove blank rows — all in your browser.
Parse INSERT statements client-side, build a real.xlsx file in your browser.
Paste any combination of CREATE TABLE and INSERT INTO statements from MySQL, PostgreSQL, or SQLite dumps. Our parser handles multi-row inserts, escaped quotes, NULL values, dates, numerics, and binary BLOBs (rendered as Base64 strings).
Once parsed, the data appears in a spreadsheet-style grid. Edit any cell, add or delete rows, rename columns. Changes are kept in browser memory — no server round-trip per edit, no "saving..." delay.
When you click download, we use SheetJS (xlsx.js) to construct an Office Open XML .xlsx file directly in JavaScript. Each table becomes a separate worksheet. The file is bit-identical to one Excel itself would produce.
The Blob is saved via a virtual <a download> click. Open it in Excel, Google Sheets, Numbers — anything that reads.xlsx. The data path was: SQL paste → JS memory →.xlsx Blob → download. No server, no log, no upload.
When you need data in a spreadsheet, fast.
A non-technical colleague needs the latest customer list as an Excel file. Run your SQL query, paste the results, get an.xlsx. No need to build an export feature, no compliance review for sending the data through a third-party tool.
Open a mysqldump file from a backup, find the relevant tables, see their content as readable rows. Often easier than spinning up a sandbox database.
Move a small table from one system to another by routing through.xlsx. Edit the data on the way (rename columns, add fields, fix typos) before re-importing.
Engineer pastes a customer's row from the database into the tool to debug a reported issue, with the data never leaving their laptop. The customer's row was sensitive — making sure it stays sensitive matters.
Database dumps usually contain real customer information — names, emails, addresses, sometimes hashed passwords or financial data. Most online SQL converters ask you to upload the file, which is exactly the wrong thing to do with PII. iKit parses everything in your browser, so the data never leaves your machine.
Deep-dive tutorials and tool comparisons from the iKit blog.
MySQL, PostgreSQL and SQLite CREATE TABLE / INSERT are all parsed correctly. Identifiers can be wrapped in backticks, double quotes or square brackets. Multi-row INSERT (VALUES (...), (...), (...)) is supported.
No. Parsing and.xlsx generation both happen entirely inside your browser via JavaScript. The resulting file is saved directly to your device.
There is no hard server-side limit. In practice, modern browsers handle a few tens of thousands of rows comfortably. For multi-megabyte dumps a CLI tool is usually faster.
Yes. If CREATE TABLE is present we use its column names. If only INSERT INTO... (col1, col2) VALUES... is present we use those column names. If INSERT has no column list we fall back to col1, col2 …
No. Timestamps such as '2024-01-05 10:12:33' are exported as plain text to avoid Excel's aggressive auto-conversion. In Excel, select the column and apply Format Cells → Date if you want the native type.