a full editor, no server, no account
SQLite databases (.sqlite / .db), .sql dumps from MySQL, Postgres or SQLite, and plain CSV. Drop one anywhere, or start from a blank database.
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.
A hand-written console runs SELECT, UPDATE, DELETE and INSERT with a real WHERE. It loads instantly, works offline, and every result is explainable.
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.
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.
four small pieces, each written by hand
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
the ones that actually come in
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.
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. One file worked through, page by page.
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. What happened, and the two ways back.
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.
the same tool, pointed at a job — all on your device, nothing uploaded
longer reads on how the editor works inside
UPDATE without WHERE changed every row 250 rows changed when one was meant: why SQL does that, the two ways back here, and the habit that stops it. Why the exported database comes out smaller 1.8 MB in, 274 KB out, every row intact: where the space went, page by page, and three commands to check your own file. 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.