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.
editing:
SQL console — select / update / delete / insert · ⌘⏎ runs
saved queries — kept on this device · one tap re-runs
Import CSV — check each column's type, then create the table
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
- The reader — SQLite's b-trees, varints and overflow chains, parsed value for value and checked against the reference engine on awkward files.
- 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.
- 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.
- 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
- indexes, views, triggers leave as a recreate script — data is what gets edited here, and a stale index is worse than a missing one
- console SQL edits with four hand-written verbs (instant, offline); joins, GROUP BY, aggregates and subqueries summon the real SQLite engine on first use — read-only, so analysis never rewrites your data
- the schema panel only offers edits the writer can regenerate cleanly — rename table, add / rename / drop column, live row counts — because this editor models values, not constraints; declared types show where the source DDL kept them, otherwise the affinity is read from the data, and foreign keys and CHECK constraints are set aside rather than half-edited
- rows over ~4KB and databases larger than browser memory are declined by name — overflow-page writing isn't built yet
- blobs pass through every export intact but aren't editable in the grid — hex editing is a different tool
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. One file worked through, page by page.
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. What happened, and the two ways back.
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
Build notes
longer reads on how the editor works inside