How to open and inspect a SQLite database

By Anil Gautam · Updated September 18, 2026

Open the SQLite file in a compatible desktop client, start read-only and look through its tables. You usually choose a file instead of entering a server address. If you just need a few records, a small SELECT is enough to get started.

First, identify the database file

SQLite files often end in .sqlite, .sqlite3 or .db. Check where the file came from too; the extension alone is not enough. Files used by other applications can share those names. If a client reports that a file is not a database, confirm that you selected the actual SQLite file rather than an archive, a log or an encrypted database requiring a different tool.

Prefer an application-supported export or a consistent backup when examining another app's live database. In WAL mode, recently committed changes may be held in the associated -wal file. Copying only the main file while it is in use can omit that state. Do not delete companion files to make a database look tidier. SQLite explains the relationship in its write-ahead logging documentation.

Open it in plainDB

  1. Create a connection and select SQLite.
  2. Choose the database file on your computer.
  3. Enable the read-only option for inspection.
  4. Connect, open a table and use the Data, Structure, Indexes and DDL views to understand it.
  5. Use filters to narrow the displayed rows, or open a query tab for a specific question.

plainDB implements SQLite browsing on macOS and Windows. The Windows build still needs its documented physical-PC acceptance checks. Check the download page for build availability and the feature matrix for tool capabilities and AI setup.

Find out what is inside

The following read-only query lists user tables and views, along with their definitions. It does not depend on any example business schema:

SELECT name, type, sql
FROM sqlite_schema
WHERE type IN ('table', 'view')
  AND name NOT LIKE 'sqlite_%'
ORDER BY type, name;

sqlite_schema is SQLite's schema table. Its SQL column describes how an object was created; it is metadata, not a sample of the table's records. SQLite schema table reference.

Once you know the real table and column names, select only what you need. This synthetic example assumes an events table with id, kind and created_at columns:

SELECT id, kind, created_at
FROM events
ORDER BY id DESC
LIMIT 50;

A bounded query keeps the initial result easy to inspect. Check the stored values before assuming a column's dates, booleans or identifiers use the format your application expects.

Exported rows are not a database backup

A CSV or JSON export is useful for analysis and sharing. It normally omits the full schema, indexes, triggers and other tables. SQL INSERT exports also need an appropriate destination schema. If you need a recoverable copy of the database, use a SQLite-aware backup process. SQLite provides an Online Backup API and documents other snapshot methods. SQLite backup documentation.

In plainDB, CSV, TSV, JSON, Markdown and SQL INSERT exports are implemented on both platforms. Confirm the scope: Table exports on both platforms can fetch every row matching the current filters. A query-result export represents the result that was fetched, not an automatic full-table backup.

If the database is locked

Check whether its owning application is writing to it. Avoid forcing changes to a live file just to inspect it. A consistent snapshot separates your investigation from the application's work. If you need to edit, keep a recoverable backup and understand the application's schema first; a syntactically valid change may still violate application assumptions.

Check plainDB availability