SQLite Manager

SQLite workspace

{{ dbName || 'Preparing sample database' }}

{{ sourceBadge }} {{ list.tables.length }} tables {{ list.views.length }} views {{ visibleRowsLabel }}

{{ dbReady ? summaryLine : 'Loading the local sample database in this browser.' }}

SQLite File

Database file:

Use .db, .sqlite, .db3, or .sqlite3; drop or browse one database file.

{{ fileLoading ? 'Opening database...' : (dbReady ? 'Database ready' : 'Drop a SQLite file here') }}

{{ dbReady ? dbName : 'Browse or drop a database file, or use the auto-loaded sample.' }}

Reloading the sample replaces the current browser database copy.

{{ statusMessage }}

{{ error }}

Table or view:

Choose one object; previews honor the Browse row limit.

Enable edits in Advanced. {{ statusMessage }}

{{ header }}	Copy

Run a query or choose another object to show rows.

SQL query:

Example: SELECT id, status FROM invoices ORDER BY issued_on DESC LIMIT 10;

{{ statusMessage }} {{ error }}

Browse row limit:

Enter 1-1000 rows; the selected table or view reloads after change.

Allow table cell edits:

Keep off for inspection; turn on only before small rowid-table cell fixes.

{{ allow_writeBool ? 'On' : 'Off' }}

Query history limit:

Enter 5-100 statements; older local history is trimmed after change.

{{ header }}	Copy

Run a query or choose another object to show rows.

SQL	Saved	Use	Copy
{{ item.sql }}	{{ item.saved }}

Run SQL to build local query history.

Metric	Value	Copy
{{ row.metric }}	{{ row.value }}

Embed:

Customize

Include current inputs

Size

Loading

Advanced

Width

Height

Aspect ratio

:

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Many application databases arrive as one quiet file with a familiar extension such as .sqlite or .db. That file can contain a complete relational database: schema records, table rows, indexes, triggers, views, and enough stored state to explain what an app believed at the moment the copy was made. This is why SQLite appears in desktop products, mobile apps, browser profiles, test fixtures, embedded devices, local caches, and support exports.

A SQLite file should be read as a database snapshot, not as a spreadsheet with extra syntax. Table names show part of the application model. Views can join or filter rows before they are displayed. Triggers can cause a write to do more than the statement appears to say. Indexes reveal which columns the original application expected to search. The first visible rows are useful orientation, but they rarely answer the real support, QA, audit, or repair question by themselves.

Common SQLite file situations and what they usually require.
Situation	What usually matters	Common mistake
Support export	Locate a customer, order, device, log row, setting, or failed state.	Exporting the first preview rows before filtering for the case.
QA fixture	Confirm seed data, migration output, constraints, and edge cases.	Checking object names without reading the stored row values.
Local app data	Understand how a local app stored account, cache, or profile state.	Assuming the main file is complete while a live app may still be writing beside it.
Small repair	Identify one row clearly, change the smallest value, and verify it.	Editing a derived view or broad condition instead of one base-table row.

A few SQLite terms change the risk level of an inspection. A table stores rows directly. A view stores a SELECT definition and may hide joins, filters, or calculated columns. A trigger runs stored SQL when matching events occur. An ordinary rowid table has a built-in row address, while a WITHOUT ROWID table depends on its declared primary key.

Good database review is repeatable. Identify the object first, keep the first preview small, write explicit conditions, and verify any change with a fresh SELECT. A copied database or SQL dump is useful evidence only when the query, row count, object names, and file state are clear enough for another person to reproduce the same finding.

Diagram showing a SQLite file containing a schema catalog, tables, views, read queries, and careful verified writes.

How to Use This Tool:

Open one .db, .sqlite, .db3, or .sqlite3 file. Use the sample database when you want to test queries or exports without touching real data.
Choose a table or view from the object list, then read the preview and schema text before writing a custom statement.
Set the browse row limit between 1 and 1000 rows. Start small, then add explicit columns, WHERE filters, and ORDER BY when ordering or evidence quality matters.
Run SQL from the query box. Format the statement when it needs review by another person; the visible grid shows the last row set returned by the executed SQL.
Keep cell editing off for inspection. If you turn it on, edit only a small value in an ordinary rowid table, save the queued changes, and prove the result with a fresh query.
Export the displayed rows when someone needs the query result. Export query history, a SQL dump, or the database copy only after confirming the browser working copy is the version you mean to keep.

Interpreting Results:

The summary identifies the open database copy, its source, the selected object, and the visible row and column count. Treat those values as orientation, not as a completeness audit. Internal SQLite objects are filtered away from the main catalog view, and a mature application can spread one business question across several ordinary-looking tables.

A preview is capped by the browse row limit. It helps you recognize columns and sample values, but it does not prove row order, uniqueness, or full coverage. If order matters, add an explicit ORDER BY. If matching matters, add a WHERE condition that names the key, date, status, or identifier being checked.

No displayed rows can mean the query matched nothing, the SQL changed data without returning a result set, or a multi-statement run ended without a final row set. Read the status or error message, then run a narrow SELECT that proves the state you care about.

SQLite manager result signals and reliable follow-up checks.
Signal	Meaning	Reliable follow-up
Table or view count	The database catalog contains user-facing objects.	Choose the object that matches the question before running broad SQL.
Schema SQL	The selected object has a stored definition that can reveal keys, joins, or trigger-related assumptions.	Check primary keys and object type before treating a row as editable.
Visible rows	The current preview or query returned rows for display.	Verify limits, filters, and ordering before exporting the row set.
Queued edits	Inline changes are waiting to be saved to the browser working copy.	Save only after confirming the target is an ordinary table row and not a derived view.
Database export	A downloadable copy of the current browser database state is available.	Run a verification query first, especially after writes or schema changes.

Technical Details:

SQLite stores relational data inside a single database file whose schema catalog records tables, indexes, views, and triggers. The catalog also stores the SQL text for many objects. Reading that catalog before editing prevents a common mistake: treating every visible object as a base table with directly editable rows.

Row identity is central to safe correction work. Ordinary SQLite tables have a hidden signed 64-bit rowid unless they are declared WITHOUT ROWID. An INTEGER PRIMARY KEY column aliases the rowid in an ordinary table. Views are saved queries and are read-only by default, though SQLite can redirect writes through INSTEAD OF triggers when a database designer has created them.

SQL statements can read and write within the same working copy. A SELECT returns a row set. UPDATE, INSERT, DELETE, and schema statements can succeed without returning rows. In a multi-statement run, the visible grid reflects the last result set returned, so verification should be a separate query with explicit conditions.

Rule Core

SQLite object and action rules that affect browsing, editing, and verification.
Object or action	SQLite rule	Practical reading
Base table	Stores persistent rows according to its declared columns and constraints.	Use for row review, filtered queries, exports, and small data corrections.
View	Stores a `SELECT` definition and behaves like a virtual table when read.	Use for inspection and export unless you know the database has write triggers for it.
Rowid table	Has a hidden rowid, or an `INTEGER PRIMARY KEY` column that aliases it.	Suitable for identifying the displayed row during small inline edits.
`WITHOUT ROWID` table	Stores rows by the declared primary key instead of a hidden rowid.	Use explicit key-aware SQL rather than rowid-based editing assumptions.
Trigger	Runs stored SQL when a matching table or view event occurs.	Expect a write to do more than the visible statement when triggers exist.
Write statement	Can change the database and still return no row set.	Follow with a targeted `SELECT` that proves the intended final value.

Mechanism Path

How a local SQLite file moves from inspection to query, edit, and export.
Stage	What happens	What to verify
Open file	The selected database is loaded as a browser working copy.	Confirm the filename and object names match the expected app or fixture.
Read catalog	User-facing tables, views, indexes, and triggers are counted or exposed through schema details.	Check whether the selected object is a base table or a derived view.
Run SQL	The query returns a row set, changes the working copy, or reports a SQLite error.	Use explicit columns, conditions, ordering, and limits for repeatable evidence.
Save edits	Queued cell changes are applied inside a transaction and rolled back if saving fails.	Run a fresh query against the changed row or unique condition.
Export	Rows, query history, summary data, a SQL dump, or the current database copy can be downloaded.	Record the query and row count so the exported evidence is reproducible.

File-State Cautions

A SQLite database taken from a running application may not be self-contained if the app was using a rollback journal or write-ahead log at the time of copying. For review or repair work, prefer a clean backup, an application export, or a database copy made after the source app has closed or checkpointed pending writes. That reduces the chance of reading stale rows or missing committed changes that lived beside the main database file.

Privacy and Accuracy Notes:

Open, browse, query, edit, and export actions work on a browser-side copy of the database. The original file on disk is not rewritten automatically. To keep a changed database, download the database export and treat that download as the version under review.

Database content remains sensitive while it is loaded in the tab. Query history is kept in the browser for convenient reruns, so avoid leaving statements that contain names, account identifiers, tokens, investigation details, or proprietary table names on a shared machine.

Very large databases, encrypted databases, extension-dependent SQL, files copied while an app was writing, or databases that depend on missing journal or write-ahead log state may fail to open or may not match the source application. When a result will drive a production repair, compare it against a trusted backup or run the same SQL in the application's normal database environment.

Advanced Tips:

Keep the browse row limit low while exploring an unknown file, then raise it only after a filtered query proves which table or view matters.
Use rowid display for small rowid-table fixes, but switch to explicit key-aware SQL when a table uses composite keys, WITHOUT ROWID, or application-managed identifiers.
Save or discard queued cell edits before exporting a database copy so the downloaded file does not mix confirmed work with accidental pending changes.
Export query history when an audit trail matters. It helps another reviewer see the exact statements that produced the row evidence.
Prefer a SQL dump for review or migration notes and a database copy for a runnable changed file. The two exports answer different handoff questions.

Worked Examples:

Triage a support database

Suppose a customer sends orders.sqlite and asks why an invoice still appears open. Open the file, inspect the table and view names, then run a narrow query such as SELECT id, status, updated_at FROM invoices WHERE invoice_no = 'INV-1002';. If the row is found, export only that result set or a short ordered context query so the evidence does not include unrelated customer data.

Make one small correction

If a city name is misspelled in an ordinary customer table, enable edits only after confirming that the row preview comes from the base table. Change the one cell, save the queued edit, then run a check such as SELECT rowid, city FROM customers WHERE rowid = 42;. The verification query is the proof, not the fact that the grid accepted a typed value.

Review a view without overreading it

A view named open_invoices may already filter out paid rows and join customer names from another table. That makes it useful for export, but it does not mean the view owns those rows. For a correction, inspect the view definition, find the base table, and use a key-aware write against the real table row.

FAQ:

Does opening a SQLite file modify the original file?

No. Opening a file loads a working copy for the browser session. Saved edits affect that copy, and you need to export the database if you want a changed file.

Why can a write succeed but show no rows?

Many SQL write statements do not return a row set. Run a follow-up SELECT that checks the exact row, key, or condition affected by the write.

When is inline cell editing appropriate?

Use it for small, obvious fixes on ordinary rowid tables. Use SQL for composite keys, WITHOUT ROWID tables, typed values, joins, broad changes, or anything that needs a precise condition.

Why should I be careful with views?

A view is a saved query, not a stored set of rows. It can be excellent for inspection and export, but corrections usually belong in the underlying base table unless the database has explicit view-write triggers.

What should I export after checking a database?

Export rows when someone needs the displayed query result. Export the database or SQL dump when someone needs the current working copy after verified edits or schema changes.

Glossary:

SQLite database: A self-contained relational database stored in a portable file.
Schema catalog: The SQLite record of tables, indexes, views, triggers, and stored object definitions.
rowid table: An ordinary SQLite table with a hidden 64-bit row identifier, unless an INTEGER PRIMARY KEY column aliases it.
WITHOUT ROWID table: A table that stores rows by its declared primary key instead of a hidden rowid.
View: A saved SELECT statement that behaves like a virtual table when read.
Trigger: Stored SQL that runs automatically when a matching database event occurs.
SQL dump: A text export of schema and row statements that can be reviewed or replayed in another SQLite environment.

References:

About SQLite, SQLite.
Database File Format, SQLite.
The Schema Table, SQLite.
Rowid Tables, SQLite.
WITHOUT ROWID Tables, SQLite.
CREATE VIEW, SQLite.
CREATE TRIGGER, SQLite.