Why the exported database comes out smaller
This is the question that comes in most often: I opened a database, changed very little, exported it, and the new file is a fraction of the size. Did rows go missing? No. But a tool that says "trust me" about your data has not earned it, so here is one file worked through with real numbers, and the three commands that let you check your own.
The test file
It was built with the official sqlite3 command-line tool, not with this site: a table of 20,000 orders, one index on the customer column, and then four rows in every five deleted. That is roughly what an app database looks like after a year of clearing out old records.
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer TEXT, item TEXT, qty INTEGER, note TEXT);
CREATE INDEX idx_orders_customer ON orders(customer);
INSERT INTO orders ... 20,000 rows: 997 customers, 53 items, qty 1 to 7, a short random note
DELETE FROM orders WHERE id % 5 <> 0;
After the delete, 4,000 rows remained and the file was still 1,773,568 bytes: 433 pages of 4,096 bytes each. It did not shrink when the rows went. SQLite never hands space back by itself; pages that fall empty go onto a list for later reuse, called the freelist, and the file keeps its size.
That file then went through editsqlite's reader and writer. These are the same sqlite.js and sqlwrite.js the editor page loads, run under Node instead of a browser tab so the numbers could be captured. The export came out at 274,432 bytes, which is 67 pages. The rebuild took 19 milliseconds.
Where the 366 pages went
Free pages: 306 of them. PRAGMA freelist_count on the original reported 306. That is 1.25 MB of pages holding nothing at all. The writer lays out only pages that carry live data, so these simply do not exist in the new file. This is most of the difference, and it is the same thing SQLite's own VACUUM command removes.
Half-empty table pages: 16 of them. Before the export, the orders table sat on 82 pages. Deleting four rows in five left many of those pages partly empty; SQLite tidies some of that up as it goes, but not all. The writer packs rows into fresh pages from the start, so the same 4,000 rows fit in 66.
The index: 44 pages. This is the part worth knowing about. The export writes tables. Indexes, views and triggers are not rebuilt into the file; after the export the editor says so ("1 indexes/views not included") and offers their CREATE statements as a script to download. An index holds no data of its own. It is a lookup structure SQLite builds from the table, so nothing is lost, but queries that filter on the customer column will scan the whole table until you run that script.
The sums close exactly. Original: 1 schema + 82 table + 44 index + 306 free = 433. Export: 1 schema + 66 table = 67.
Checking it yourself
Three commands in sqlite3, run against the exported file and then the original:
PRAGMA integrity_check; on the export returned ok. That is the official engine walking every page and b-tree and finding nothing wrong.
SELECT count(*), min(id), max(id), sum(qty) FROM orders; returned 4000|5|20000|16000 on both files. Pick columns from your own table that would change if a row were dropped or altered; a sum over a numeric column is a cheap fingerprint.
CREATE INDEX idx_orders_customer ON orders(customer); run on the export brought it to 88 pages, 360,448 bytes. Running VACUUM on a copy of the original gave 88 pages too, with the index on 21 of them. Two different routes arriving at the same size is a good sign that neither is hiding anything.
When the size change means something else
The writer always uses 4,096-byte pages. A database created with 1,024-byte or 65,536-byte pages can change size for that reason alone, in either direction; PRAGMA page_size; tells you which you have. A file that barely shrinks has usually been vacuumed recently or has never had many deletes, and that is fine too. And if the row counts or sums ever disagree between the two files, keep the original, and write to the address on the contact page with the numbers from both. An export that loses a row is the most serious defect this tool can have.
The short version: a database file is sized by its history, and an export is sized by what is in it now. Keep the original either way, as the editor page says; the checks above take a minute and turn "it looks right" into "it is right".