SQLite Manager

SQLite database

{{ dbName }}

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

{{ summaryLine }}

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

SQLite keeps a complete relational database in one portable file. That makes it common in desktop apps, mobile apps, local caches, test fixtures, and exported support data, but it also means inspection often starts with an unfamiliar file and a very specific question.

Use this tool when you need to open a local SQLite database, browse its tables or views, run focused SQL, make small rowid-table edits, or export a result set for review. The fastest path is usually to identify the object, read the row preview, then run a narrow query that answers the actual question.

Keep the workflow deliberate. A visible grid does not prove every row was reviewed, a write that returns no rows still needs a verification query, and a downloaded copy is a snapshot rather than a replacement for a backup process.

For support triage, data repair, QA checks, and one-off analysis, the safest habit is simple: read the object first, make the smallest useful change, then confirm the result with a fresh query before exporting anything.

Diagram showing a SQLite file feeding object browsing, SQL checks, careful row edits, and explicit exports.

How to Use This Tool:

Open a local .db, .sqlite, .db3, or .sqlite3 file, or load the sample database when you just want to test the workflow.
Select a table or view and read the preview before writing custom SQL. Set the browse row limit low enough to keep the first pass quick and high enough to cover the rows you expect.
Run focused SQL when you need filtering, joins, aggregation, write statements, or typed values such as NULL, dates, and arithmetic expressions.
Use cell editing only for small corrections on ordinary rowid tables. Turn editing on deliberately, review the queued changes, save them, then run a verification query.
Use the result exports when you need the displayed row set in CSV, JSON, or DOCX. Use the database export when you need a copy of the current database state.
If the output shows an error or no displayed rows, simplify the SQL and run a narrow SELECT that proves what happened.

Interpreting Results:

The summary area tells you what kind of database is open and how many user-facing objects were found. Treat those counts as orientation, not as a health check. A database can have many tables because the app is complex, and a trigger count only tells you that write-side logic exists.

The selected object matters most. A base table is usually the best target for row review and small corrections. A view is a stored query, so it is better suited to inspection and export. A table declared without a rowid needs key-aware SQL rather than assumptions about hidden row addresses.

No results means there is no row set to display from the last SQL action. That can happen after a successful write, an empty match, or a statement that does not return rows. The next step is a targeted SELECT, not a guess.

SQLite manager result signals and recommended follow-up checks.
Signal	What it means	What to check next
Object counts	Tables, views, indexes, and triggers were found in the database catalog.	Choose the object that matches your question before running broader SQL.
Table preview	The selected object returned a capped set of rows for quick orientation.	Use a narrower query if order, filtering, or completeness matters.
Queued edits	One or more visible cell changes are waiting to be saved.	Confirm the target object is an ordinary rowid table and the change is small enough for inline editing.
No displayed rows	The last SQL action did not produce a row set for the grid.	Run a verification `SELECT` that isolates the expected row or condition.
Export summary	The current row set or database copy is ready for handoff.	Check that the query and row count match the slice you intended to share.

Technical Details:

SQLite stores both database structure and data in the same file. Its schema table records user-defined tables, indexes, views, and triggers along with their stored creation SQL. That catalog is why one file can reveal both the available objects and the rules that shape them.

Row addressing controls the safest edit path. Ordinary SQLite tables have a hidden 64-bit rowid unless they are declared WITHOUT ROWID. If a table declares an INTEGER PRIMARY KEY, that column aliases the rowid. SQLite views are read-only unless they are made writable through INSTEAD OF triggers, so a view preview should usually be treated as a read or export target.

The query grid shows displayed rows, not a full audit trail. Write statements such as UPDATE, INSERT, and DELETE may succeed without returning a row set. When several statements are run together, keep the batch short and verify the final state with a separate query that returns the rows you care about.

Rule Core

SQLite object rules used to decide how to browse, edit, or verify database content.
Object or action	Rule	Practical reading
Base table	Stores persistent rows under its table definition.	Best starting point for row review, filtering, and small data corrections.
View	Stores a query definition and is read-only by default.	Use for inspection and export unless you know the underlying write rules.
Ordinary rowid table	Has a hidden rowid, or an `INTEGER PRIMARY KEY` alias for it.	Suitable for quick row identification and small inline cell edits.
`WITHOUT ROWID` table	Stores rows by the declared primary key instead of a hidden rowid.	Use explicit key-aware SQL rather than quick rowid-based editing.
Write statement	Does not have to return rows even when it changes data.	Follow with a `SELECT` that proves the changed values or confirms no match.

Lookup and Export Core

How to map common SQLite manager tasks to the most reliable action.
Goal	Most reliable action	Verification habit
Identify the file	Open it and inspect object counts plus the selected object's definition.	Confirm the table or view names match the expected app or fixture.
Answer a data question	Run a narrow `SELECT` with explicit columns, filters, order, and limit.	Check that the returned rows match the business question, not just the first preview rows.
Make a small correction	Edit an ordinary rowid-table cell or run a precise SQL write.	Run a fresh `SELECT` using the row key or unique condition.
Share evidence	Export the displayed rows as a structured file or download the current database copy.	Record the query or selected object alongside the export so the slice is reproducible.

Privacy and Data Notes:

Normal open, browse, query, and export actions work with the database in the browser session. That is useful for local files, but it also means you should treat the current tab as containing the loaded data until you replace or clear it.

Query history is a convenience feature for repeated checks. Do not store sensitive statements longer than necessary, especially when queries contain names, identifiers, customer values, or investigation details.

The database export represents the current in-browser copy after any edits you saved during the session. It does not automatically modify the original file on disk; keep the exported copy only when it is the version you intend to hand off.

Worked Examples:

Review a handed-off app database

Suppose you receive orders.sqlite and need to confirm the most recent order statuses. Open the file, choose the likely orders table, then run SELECT id, status, updated_at FROM orders ORDER BY updated_at DESC LIMIT 20;. Export that row set only after the returned columns and row order match the support question.

Make one small text correction

If a customer city is misspelled in an ordinary rowid table, enable editing, change only that cell, save the pending edit, and run a narrow check such as SELECT rowid, city FROM customers WHERE rowid = 42;. The verification query matters more than the earlier preview.

Inspect a view without treating it as a table

If the selected object is a view, use it to understand derived rows or export a filtered result. For a write, find the underlying base table and use SQL keyed by the real business identifier. A view preview is useful context, but it is not the same thing as a direct table edit target.

FAQ:

Does opening a database change the original file?

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

Why can I browse a view but not edit it like a table?

A SQLite view is a stored query. SQLite treats views as read-only unless they have special write triggers, so the safe default is inspection, filtering, and export.

Why did my write show no rows?

Many write statements change data without returning a result set. Run a follow-up SELECT that isolates the changed row or condition.

When should I use SQL instead of inline editing?

Use SQL for typed values, complex conditions, joins, composite keys, WITHOUT ROWID tables, and anything that affects more than a tiny obvious text fix.

What should I export?

Export rows when someone needs the displayed query result. Export the database when someone needs the current working copy after inspection or edits.

Glossary:

SQLite database: A complete relational database stored in a single portable file.
Schema table: SQLite's catalog of tables, indexes, views, triggers, and their stored creation SQL.
rowid table: An ordinary SQLite table with a hidden 64-bit row identifier.
WITHOUT ROWID table: A table that stores rows by its declared primary key instead of a hidden rowid.
View: A stored query definition that behaves like a virtual table when read.
INSTEAD OF trigger: A SQLite trigger type that can make writes against a view perform actions on underlying tables.

References:

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