editsqlite Edits SQLite Files in the Browser Tab and Declines Rows Over 4KB

editsqlite, a browser-based editor for SQLite databases, opens a database file, edits it in a spreadsheet-style grid or a SQL console, and exports a rebuilt file without sending anything to a server, according to its own page. It reached 64 points on Hacker News on Oct. 29.

The Terminal did not use the editor. This account rests on the page's claims and limits, and on the SQLite project's documentation for running the database engine in a browser.

What it opens and what it writes

The page says it accepts .sqlite and .db files, SQL dumps in the MySQL, Postgres or SQLite dialects, and CSV files, or starts a blank database. A CSV import wizard sets column types before creating the table.

Exports go to .sqlite, .sql in any of the same three dialects, or CSV. The page says each export is "rebuilt from scratch" and the original file is "Read once, never written to, never uploaded." Edits sit in a working copy in the tab, with undo and redo, and the SQL console takes SELECT, UPDATE, DELETE and INSERT with an undo checkpoint before changes.

The footer credits Saurav Kumar Sharma, in India. The page shows a 2026 copyright and build notes dated from July 5 to Oct. 19, 2026, the latest titled "UPDATE without WHERE." It states no licence.

How the privacy claim holds up

The page's wording is "runs in your tab · nothing uploads," and it adds that the file is "opened, edited and rebuilt on your own device" and works offline once loaded. The Terminal could not inspect network traffic, so this is the author's statement and not a measurement.

The page also says the reader, dump parser, writer and SQL console are written by hand, and that heavier read-only queries such as joins, grouping and subqueries go to "the real SQLite engine," loaded only when a query needs it. It does not say whether that engine is the official WebAssembly build.

The SQLite project does publish one. Its WASM subproject page calls it "the first effort 'officially' associated with the SQLite project" and names the Origin-Private FileSystem as the main persistent storage option. It describes the localStorage and sessionStorage option as "(very limited)."

What an exported file loses

The limits are on the page itself, which is unusual for a tool of this size.

Item	What the page says happens
Rows over about 4KB	Declined
Indexes, views, triggers	Exported as a recreate script, not live objects
Blobs	Pass through export, not editable in the grid
Foreign keys, CHECK constraints	Set aside, not edited
Schema panel	Rename table, add, rename or drop column, row counts only

The page gives no file-size ceiling beyond saying databases larger than browser memory are declined.

The first row is the one a maintainer of a real application would hit. A 4KB row is a modest limit: a TEXT column holding a page of JSON or a long log message crosses it. The second row matters for round trips. A file opened, edited and exported comes back with its indexes described in a script, so the first thing to run on it is that script.

Who the tool fits

The case for it is the small job: fixing a value in a configuration database, converting a CSV into a queryable file, or checking a dump before importing it elsewhere, with no install and no account. The Terminal covered the same pull toward tools that run locally in Survival LLM's offline assistant, and a separate small open-source tool in Impeccable's design skills for coding agents.

It is a poor fit for a production database with foreign keys and triggers, because the page says the first are set aside and the second become a script.

The next thing to watch is the build notes, which the author dates. The latest, on Oct. 19, is about UPDATE without a WHERE clause.