Where does SQLite store its schema?

Every SQLite database keeps its schema in a built-in table called sqlite_master, which has one row per table, index, view and trigger. Each row stores the object's name, type, root page and the exact CREATE statement used to define it.

Does this modify my database?

No. The viewer is strictly read-only. It parses the file in memory in your browser to display the schema and never writes back or sends anything to a server.

How are foreign keys detected?

Foreign keys are counted by scanning each table's CREATE statement for REFERENCES clauses. This gives a quick relationship indicator; the full constraint text is visible in the displayed CREATE TABLE statement.

Will it show indexes I didn't create explicitly?

Auto-created indexes that back UNIQUE or PRIMARY KEY constraints are named like sqlite_autoindex_* and are hidden, while indexes you defined with CREATE INDEX are shown in full.

What is the SQLite Schema Viewer?

Inspect a SQLite database's schema in your browser: every CREATE TABLE, CREATE INDEX, CREATE VIEW and CREATE TRIGGER statement, plus a foreign-key count per table. Parsed locally from sqlite_master — no upload. It runs free in your browser on Gera Tools, with nothing uploaded.

SQLite Schema Viewer

Name: SQLite Schema Viewer
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

The SQLite Schema Viewer reveals the complete structure of a SQLite database — its tables, columns, indexes, views and triggers — without opening a desktop GUI or typing .schema at a prompt. Because SQLite records every object’s definition in a built-in catalogue, the schema can be read directly from the file in the browser. This is ideal for understanding an unfamiliar database, reviewing migrations or documenting a data model.

How it works

SQLite stores its catalogue in a table named sqlite_master, whose b-tree always begins on page 1 of the file. The viewer reads the database header to find the page size, then walks that b-tree, decoding each record into five fields: type, name, tbl_name, rootpage and sql.

The sql field contains the original CREATE TABLE, CREATE INDEX, CREATE VIEW or CREATE TRIGGER statement exactly as it was written. The tool groups objects by type and renders each statement so you can read column definitions, types, default values and constraints verbatim.

For each table it also scans the statement for REFERENCES clauses and shows a foreign-key count, giving a quick sense of how tables relate. Internal objects whose names start with sqlite_ are filtered out so the view stays focused on the schema you authored.

What you can read from the schema

A CREATE TABLE statement in SQLite preserves the complete column specification including:

Column names and declared types (note: SQLite is loosely typed, so these are advisory)
PRIMARY KEY designations and whether they are AUTOINCREMENT
NOT NULL constraints
DEFAULT values including expressions like CURRENT_TIMESTAMP
UNIQUE constraints both inline and as table-level constraints
CHECK expressions
FOREIGN KEY ... REFERENCES clauses (if foreign key enforcement is on)

Indexes appear as separate CREATE INDEX statements showing which columns are covered and whether the index is UNIQUE. Views show the query they encapsulate. Triggers show their event (BEFORE/AFTER, INSERT/UPDATE/DELETE) and the action SQL.

Common uses

Reverse-engineering an app’s data model. Many mobile apps and desktop tools embed a SQLite database. Dropping the .db file here reveals the full schema without needing the app’s source code.

Reviewing a migration. After running a migration script, open the updated database and verify that the new columns, indexes, and constraints were applied exactly as intended.

Documenting a data model. The unmodified CREATE statements are the most precise documentation of the schema — more reliable than hand-written notes.

Finding missing indexes. Scan the index list and check whether heavily queried columns have covering indexes. A table with many foreign keys and no indexes on those columns is a common performance problem.

Tips and notes

The CREATE statements are shown unmodified, so any CHECK constraints, DEFAULT values and COLLATE clauses are preserved.
A high foreign-key count on a table usually marks it as a join or fact table in the data model.
To inspect the actual data behind the schema, use the SQLite Database Viewer or export with the SQLite to CSV exporter.

Everything runs locally in your browser — no upload, no account, read-only.