When you need to repair a SQLite database, the situation usually announces itself with a blunt error: database disk image is malformed. A query that ran fine yesterday now returns SQLITE_CORRUPT, an application refuses to open its store, or a backup you were counting on turns out to be unreadable. The good news is that SQLite corruption is rarely total. A database is a single file made of fixed-size B-tree pages, and when one page is damaged the thousands of pages around it are often perfectly intact. Repair is largely the craft of reading every good page and leaving the bad ones behind.

This guide walks through the full process for developers: how to confirm the file is really corrupt, how to salvage what survives, and how to rebuild a clean database you can trust. You can follow along with the browser-based repair SQLite tool, which performs the salvage and rebuild without installing anything, or with the sqlite3 command-line tools if you prefer to work in a terminal.

What Corruption Actually Means in SQLite

A SQLite database is not a folder of files or a running service. It is one ordinary file on disk, divided into pages of a fixed size (4096 bytes by default). Those pages form B-trees: one tree per table and per index. A special table called sqlite_master lives on page 1 and holds the schema, the CREATE statements that describe every table and index and where each tree begins. When SQLite opens a database it reads that schema, then walks the trees to find your rows.

Corruption means one or more of those pages no longer contains what SQLite expects. A page header may be wrong, a pointer may lead somewhere invalid, or a byte range may have been overwritten with garbage. The error database disk image is malformed is SQLite refusing to trust a structure it can no longer verify. Crucially, the damage is usually local. A torn write during a power loss might wreck a handful of pages, while every other table remains readable. That is why salvage works so reliably: the engine can skip the broken pages and still hand back the majority of your data.

Step One: Confirm the Corruption

Before repairing anything, confirm what you are dealing with. The authoritative check is a single pragma:

  • PRAGMA integrity_check; walks the entire database and reports structural problems. A healthy file returns the single word ok. A corrupt one lists specific faults, such as pages with wrong page-numbers, rows missing from an index, or a malformed B-tree.
  • PRAGMA quick_check; is a faster, lighter version that skips some index cross-checks. Use it when the full check is too slow on a large file.

Run these on a copy, never the original. If integrity_check reports errors but the database still opens, you can often export the data with a normal dump. If the file will not open at all and every command returns database disk image is malformed, you need the recovery path described below.

How to Repair a SQLite Database: The Reliable Path

The dependable way to repair a SQLite database is to recover it: read every table and row the engine can still parse and write them into a brand-new, structurally perfect file. This throws away the corrupt scaffolding and keeps the data. The browser tool does exactly this in a few clicks.

  1. Work on a copy. Duplicate the corrupt file so the original is never at risk. If the database used WAL mode, copy the companion -wal and -shm files alongside it, since recent changes may still live there.
  2. Open the repair tool. Go to the repair SQLite page.
  3. Upload the database. Drag the file in or browse to select it.
  4. Run the recovery. The tool reads the schema from sqlite_master, walks each B-tree, salvages every readable row, and writes them into a fresh database.
  5. Download and verify. Save the rebuilt file, then run PRAGMA integrity_check; on it. A clean ok means the rebuild succeeded.

For most corrupted databases this single pass returns a working file with all or nearly all of your data intact.

The Command-Line Equivalent

If you would rather use the sqlite3 CLI, the modern recovery command mirrors what the tool does:

  • .recover is the preferred option. Run sqlite3 broken.db ".recover" | sqlite3 recovered.db. It reconstructs as much of the database as it can from the raw pages, even reading rows that a plain dump would choke on, and pipes SQL to build a new file.
  • .dump is the older approach: sqlite3 broken.db ".dump" | sqlite3 recovered.db. It works when the file still opens and only some rows are affected, but it stops at the first serious error, so .recover is more resilient on badly damaged files.

Both routes end the same way: a new database rebuilt from salvaged SQL statements. Always run integrity_check on the result to confirm it is clean.

What You Can and Cannot Recover

Recovery salvages data that is physically present on disk. If a table's pages are readable, the rows come back. The honest limits are worth stating plainly:

  • Damaged pages are skipped. Rows that lived only on corrupt pages cannot be reconstructed, because their bytes are gone or unreadable. You may recover 99 percent of a table and lose a handful of rows.
  • Truncated files lose their tail. If a download or copy was cut short, the missing pages were never written, and no tool can invent them.
  • Indexes are rebuilt, not recovered. That is fine, since indexes are derived from table data and the new schema recreates them.

The practical takeaway: recovery is about maximising what you get back, not guaranteeing a byte-perfect twin. When integrity_check on the rebuilt file returns ok, you have a sound database, even if a few rows from the worst-hit pages did not survive.

When Repair Is Not the Answer

Sometimes another route is faster or better. If you keep a recent backup, restoring it gives a perfect file in seconds and beats any salvage. If the database is a cache or is regenerated from an upstream source, rebuilding from that source is cleaner than recovering a damaged copy. And if the file is encrypted with something like SQLCipher, you must decrypt it with the correct key before any structural repair is meaningful.

Conclusion

To repair a SQLite database, remember what the file really is: pages of B-trees with the schema in sqlite_master. Confirm the damage with PRAGMA integrity_check, then recover the data by reading every good page into a fresh file, either through the repair SQLite tool or the .recover command. Verify the rebuilt file with another integrity_check and you are back in business. To understand why the failure happened, read why SQLite databases get corrupted, and to keep it from recurring, see how to prevent SQLite corruption. For a deeper look at the salvage internals, our guide to recovering data from a corrupt SQLite file covers exporting individual tables.