VoriTools

SQLite Header and Schema Inspector

Select a SQLite database file to inspect its header and detected schema text. Schema detection is heuristic; the tool does not execute queries or browse table rows.

Runs locally in your browser
View category: SQL & Databases (12)
This tool processes all data locally in your browser.
SQLite database fileChoose a local SQLite 3 file. The inspector reads the file header and schema text only; it does not run SQL queries.
Database header
    

    


    How to inspect a SQLite database
    This page opens a local SQLite 3 file in the browser and reports what the file says about itself: the database header and the entries of the sqlite_schema table, which is where SQLite keeps every table, index, view and trigger. The file is read with the FileReader API, so nothing is uploaded and no query is executed.
    Choose the .sqlite, .db or .sqlite3 file with the button. The header appears as a JSON report, the schema objects appear as a table, and Clear removes the file from the page. The page never opens row data: it reads page 1 and the schema pages only.
    1. Press Choose local file and select the .sqlite, .db or .sqlite3 file you want to look at.
    2. Read the header report: file name, byte size, page size, page count, write and read format version, text encoding, schema format and application id.
    3. Check the schema table: one row per object, with its type, its name and the CREATE statement exactly as SQLite stores it.
    4. Read the findings: an empty schema table is explained there, and internal objects whose names start with sqlite_ are counted.
    5. Press Clear to drop the file from the page.
    What the inspector reads
    The header it reports
    The header report repeats the first 100 bytes of the file as named fields: bytes is the size of the file on disk, page_size is the page size the database declares (the value 1 means 65536), and pages is the file size divided by the page size. file_format_write_version and file_format_read_version are 1 for a rollback-journal database and 2 for a WAL database, and text_encoding is UTF-8, UTF-16le, UTF-16be or "not declared" as the header states it.
    schema_format and application_id come from the same header block. They are printed as numbers because that is what the file contains; the page does not guess what an application id means.
    Schema objects
    The table is read from the sqlite_schema b-tree on page 1, in the order the objects were created, and it keeps the SQL text unchanged, including quoted names such as "user data", non-ASCII names and multi-line trigger bodies. A 130-column table with a 6 KB CHECK clause was reported complete, and a database with 400 objects listed all 400.
    Objects SQLite creates itself are listed as well: a UNIQUE column gives a sqlite_autoindex_* index and AUTOINCREMENT gives the sqlite_sequence table. A finding tells you how many of these internal objects are in the list so they are not mistaken for user objects.
    What it cannot tell you
    Only the database file you select is read. In WAL mode the newest changes may still live in the separate -wal file, and this page does not read that sidecar file, so a schema that was created in an uncheckpointed WAL session may be missing. Row data is never decoded, so the page cannot show table contents, run integrity checks or repair a file.
    A file that does not begin with the SQLite format 3 signature, a file shorter than 100 bytes, or a header that declares an impossible page size is rejected with a message, and the previous report is cleared so nothing from an earlier file stays on screen.
    

    
    
    
        
    Recent tools: