SQLite Manager

{{ summaryHeading }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

Database file:

Browse or drop one DB, SQLITE, DB3, or SQLITE3 file. The shipped sample opens automatically and all work stays in this browser.

{{ databaseReady ? databaseName : 'Preparing SQLite workspace' }}

{{ databaseReady ? sourceLabel : 'Loading the local sample database.' }}

{{ sourceHint }}

Table or view:

Choose a table or view to inspect it, or leave the current choice and write a custom query below.

SQL:

SELECT, WITH, EXPLAIN, and read-only PRAGMA statements run by default. Enable writes only for deliberate local-copy changes.

{{ queryActionHint }}

Local row edits

Edit visible cells in the working copy, then save or discard the queued changes.

{{ displayHeader(header) }}

{{ workflowFeedback }}

Browse row limit:

Use 1–500 rows. The default of 100 leaves the primary sample result unchanged.

rows

History limit:

Use 5–100 entries; the neutral default keeps up to 25 statements.

entries

Write access:

Keep off for inspection. Turning it on does not run or change anything by itself.

{{ allowWrite ? 'Enabled for local copy' : 'Read only' }}

{{ displayHeader(header) }}	Copy
{{ displayCell(row[header]) }}

The latest statement returned no row set.

Type	Name	Table	Definition	Copy
{{ row.type }}	{{ row.name }}	{{ row.table_name \|\| '—' }}	{{ row.sql \|\| 'Internal definition' }}

Run	Statement	Kind	Rows	Changes	Status	Copy
{{ row.run }}	{{ row.sql }}	{{ row.kind }}	{{ row.rows }}	{{ row.changes }}	{{ row.status }}

Current browser working copy

{{ databaseName }}

Includes the current schema and any explicitly saved local edits. Neither action overwrites the original file.

A SQLite database can hold an application's working state in one portable file. Tables store rows, indexes speed selected searches, views present saved queries, and triggers can run extra statements when data changes. Opening the first table is useful orientation, but the schema often explains the file more clearly than any single result set.

This format appears in desktop and mobile apps, browser profiles, embedded devices, test fixtures, local caches, and support exports. Investigations commonly begin with a narrow question: which account owns a record, which setting was saved, why a status changed, or whether a schema object exists. A focused query is safer and easier to verify than browsing hundreds of unrelated rows.

SQLite objects and their diagnostic meaning
Object	What it represents	Interpretation caution
Table	Stored rows organized by columns and constraints	A table may be incomplete without related tables
View	A saved SELECT statement	Rows are derived and may filter or join source data
Index	An access structure for selected columns or expressions	It does not establish business meaning or uniqueness unless declared
Trigger	SQL that runs after a defined database event	A write may have effects beyond its visible statement

Read-only inspection should be the default. A copied database may contain production identifiers, deleted-state remnants still reachable through tables, or data covered by access rules. Even when analysis stays on the device, exported rows, dumps, and edited copies need the same care as the source file.

A browser working copy is intentionally temporary. Changes do not overwrite the selected file, and closing or replacing the working copy discards anything not downloaded. That separation is useful for triage, but it does not replace backups, migrations, integrity checks, or a review in the application's normal runtime.

How to Use This Tool:

A sample database opens automatically, so the workflow can be tested before loading a real file.

Browse or drop one .db, .sqlite, .db3, or .sqlite3 file no larger than 64 MB. Confirm the file name shown for the browser working copy.
Choose a table or view for a bounded preview, or enter a focused statement in SQL. Press Run SQL and check the returned rows and status message.
Leave Write access off for inspection. Enable it only for a deliberate local-copy change, then rerun a SELECT statement to verify the saved value and any trigger effects.
Download the SQLite working copy or SQL dump if the change must survive the session. Replacing the file or leaving the page does not update the original database.

Interpreting Results:

The result table shows the final row-producing result set from the statement. Zero rows can mean a correct query found no match, a view filtered the data, or a mutating statement returned no row set. Use the operation status and changed-row count before deciding which case occurred.

Schema counts summarize user tables, views, indexes, and triggers; internal names beginning with sqlite_ are excluded. Query history records recent unique statements for the current browser session, not a durable audit log. A successful local edit confirms that the working copy accepted the transaction, not that the application will accept or understand the modified file.

Technical Details:

The database runs through SQLite compiled for the browser. The selected file becomes an in-memory database, and all statements execute against that copy. The file-size ceiling is 64 × 1024 × 1024 bytes. Query text is limited to 100,000 characters, browse results to 1–500 rows, and history to the latest 5–100 unique statements.

Rule Core:

A conservative statement classifier removes comments and quoted text before scanning SQL. It allows common row-reading forms while Write access is off and blocks text that appears to mutate the database. This is a usability guard, not a database security boundary or a full SQL parser.

SQLite statement classification rules
Statement evidence	Read-only classification	Behavior with Write access off
Begins with SELECT, WITH, EXPLAIN, VALUES, or read-only PRAGMA	Read only	Allowed
Contains INSERT, UPDATE, DELETE, REPLACE, CREATE, DROP, ALTER, ATTACH, or DETACH	Mutating	Blocked
Contains transaction or maintenance terms such as BEGIN, COMMIT, ROLLBACK, VACUUM, or REINDEX	Mutating	Blocked
PRAGMA contains an equals sign	Mutating	Blocked
Unknown first keyword	Mutating by default	Blocked

Turning on Write access does not execute anything. It permits the current statement to reach the in-memory database. SQLite still applies its own syntax, constraints, foreign-key setting, and trigger behavior when the statement runs.

Mechanism Core:

Opening a database follows a short path: validate the extension and size, read the bytes into memory, open the SQLite image, query sqlite_schema for user objects, then preview the first table or view. Choosing a table builds a bounded query that includes its hidden rowid; choosing a view runs a bounded SELECT without assuming a writable row identity.

Inline cell editing is available only when Write access is enabled, a table is selected, rows were returned, and the result contains rowid. Queued cells are applied with parameterized UPDATE statements inside one transaction. Success commits every queued change and reloads the table; an error rolls the transaction back. Views and WITHOUT ROWID tables do not satisfy this edit path.

SQLite working-copy state transitions
Action	Working-copy effect	Original-file effect
Run SELECT or browse an object	Returns a snapshot of the final row set	None
Run mutating SQL with Write access	Changes the in-memory database	None
Save queued cell edits	Commits one local transaction and reloads the table	None
Download working copy	Serializes the current database to a new file	None
Replace or close the session	Discards unexported state	None

The generated SQL dump writes table definitions and rows first, then other stored schema definitions, inside a transaction with foreign-key enforcement disabled for import ordering. Treat it as a transport aid and test restoration in an isolated database before relying on it as a backup.

Privacy and Data Safety:

The database file, SQL statements, query results, and edits remain in the browser working copy. The SQLite runtime and optional SQL formatter are downloaded as generic dependencies; the selected database is not uploaded with those requests.

Review exports for credentials, tokens, personal data, and internal identifiers before sharing them.
Keep an untouched source copy. A valid SQLite file can still be semantically inconsistent with the application that created it.
The write classifier reduces accidental edits but does not make untrusted SQL safe. Run only statements you understand.
A browser crash, refresh, or file replacement can remove unexported changes without recovery.

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.