editsqlite runs in your tab · nothing uploads

Open, edit and re-export a database — right in your browser.

Open a SQLite file, a .sql dump or a CSV, edit the data in a grid or with SQL, then download a fresh file. Read once, never written to, never uploaded.

.sqlite / .db · .sql dumps (MySQL, Postgres, SQLite) · .csv — or drop a file anywhere on the page. Exports are fresh files built by our own writer; for CSV, the import wizard types each column before the table is created.

What editsqlite does

a full editor, no server, no account

Opens the files you have

SQLite databases (.sqlite / .db), .sql dumps from MySQL, Postgres or SQLite, and plain CSV. Drop one anywhere, or start from a blank database.

Edit like a spreadsheet

Double-click a cell to change it, add or delete rows and columns, rename tables, undo and redo. A side panel shows every table's columns, types and row counts.

Or edit with SQL

A hand-written console runs SELECT, UPDATE, DELETE and INSERT with a real WHERE. It loads instantly, works offline, and every result is explainable.

Export a fresh, valid file

Download a clean .sqlite our writer builds byte by byte, a .sql dump in any of three dialects, or CSV. Each .sqlite passes the official engine's integrity check.

How it stays safe

rebuild, don't operate in place

Every editor of precious files picks one of two paths: change the bytes inside the file (fast, and one wrong offset corrupts it for good) or rebuild the whole file on save. editsqlite always rebuilds. Your original is read once and never written; edits live in a working copy in the tab; and each export runs our SQLite writer over the entire model — every page laid out fresh, every offset recomputed — then holds the result to an outside standard: the official SQLite engine's own PRAGMA integrity_check passes on our output, and the engine will happily insert its own rows into files we built. Corruption needs something to touch, and we touch nothing.

Under the hood

four small pieces, each written by hand

  1. The reader — SQLite's b-trees, varints and overflow chains, parsed value for value and checked against the reference engine on awkward files.
  2. The dump parser — mysqldump, pg_dump and sqlite3 output, with each dialect's escapes and COPY blocks handled the way the real tools write them.
  3. The console engine — a compact SQL interpreter (four statements, an honest WHERE) built from scratch: instant load, predictable behavior, and the editor's default. Heavier read-only analysis (joins, grouping, subqueries) hands off to the real SQLite engine, summoned only when a query needs it.
  4. The writer — records encoded, pages packed, trees stacked, header stamped: the part that lets an export call itself certified.

Where the limits are

said up front, not discovered later

editsqlite started with a stuck afternoon. A lab's specimen catalog — a SQLite file a postdoc had built years earlier — needed a few hundred rows corrected, and the only sanctioned way in was a web form wired to an old server, one row per page load. Every faster option wanted the whole catalog uploaded to someone else's cloud. What I wanted felt obvious and turned out to be rare: open the file, fix the cells like a spreadsheet, save a clean copy, without the data ever leaving the building. So this got built — a reader, a writer and a small honest SQL engine, all running right here. The corrections took an afternoon, the file never left the room, and the tool stuck around.

— the engineer behind editsqlite

Questions people ask

the ones that actually come in

Can I trust it with the only copy of a database?

The design protects you twice — the original is never written to, and every export is a new file — but the honest answer is still: keep a copy. Any tool that asks you to trust it instead of checking its work shouldn't hold your only copy, this one included.

Why did my exported .sqlite get smaller?

A rebuild writes only live data — no freelist pages, no fragmentation, no leftover index trees — so a well-used database often exports smaller than it arrived. Same rows, tighter pages; the integrity check is the receipt.

UPDATE without WHERE just changed every row!

As SQL has always done — and undo has your back, since the console checkpoints before every mutation. The lesson costs one click here; on a production server it traditionally costs a much longer story. Consider this the safe place to learn it.

Could it edit MySQL or Postgres servers directly?

No — browsers can't speak those wire protocols, and honestly shouldn't. The workflow is: dump the table (one command), edit it here, export the dialect dump, load it back. Files are the interface, and your credentials stay yours.

Convert between formats

the same tool, pointed at a job — all on your device, nothing uploaded

CSV → SQLite Turn a spreadsheet export into a typed .sqlite database — each column typed before the table is built. MySQL → SQLite Open a mysqldump .sql file and leave with a working .sqlite — no local MySQL needed. Postgres → SQLite Read a pg_dump file, COPY blocks and all, and export a clean SQLite database. SQLite → CSV Open any .sqlite / .db and export a table — or a query result — as CSV. SQLite → SQL dump Export a database as a .sql dump in SQLite, MySQL or Postgres dialect. All converters → Every direction the reader, dump parser and certified writer handle.

Build notes

longer reads on how the editor works inside

Writing a database by hand Records, pages, trees and one off-by-one that pointed a whole b-tree the wrong way — building the writer the official engine signs off on. Rebuild, don't operate in place Why safe editing means never touching the original file — an architecture argument with corrupted-file scars behind it. Four statements are enough SELECT, UPDATE, DELETE, INSERT — what a hand-written mini-SQL engine covers, refuses, and quietly teaches.