SQLite Manager

Introduction

SQLite keeps a complete relational database inside one portable file. That file can hold tables, indexes, triggers, and views without a separate database server, which is why SQLite appears in desktop software, mobile apps, local caches, test fixtures, and exported app data. The format is easy to move around, but that portability also means inspection often starts with an unfamiliar file dropped into your lap.

The job is rarely abstract. You might need to confirm whether a table still has the expected columns, check one customer's row before a support reply, review a view definition from a shipped app, or make a tiny correction in a copied database before handing it back. In each case the file itself is the source of truth, so the useful workflow is to open it quickly, see its schema clearly, and run narrow checks instead of building a full administration stack around it.

Browser-based inspection fits that situation well because the database can be examined where it already sits. That convenience still has boundaries. A visible row grid does not mean every object is safely editable, a quick export is not the same thing as a backup policy, and a successful preview does not replace a deliberate verification query after a write.

The safest habit is to treat each SQLite file as a portable database snapshot. Read the schema first, identify the exact object you are working with, then make small, deliberate checks or edits and confirm them with a fresh query before you move on.

Technical Details

SQLite stores both structure and data in the same database file. The schema table, historically exposed as sqlite_master and formally documented as the schema table, records one row for each table, index, view, and trigger together with the SQL text that created it. That catalog is the reason a SQLite inspection workflow can answer two different questions from the same file: what objects exist, and how each object was defined.

Row addressing matters just as much as schema. 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 becomes an alias for the rowid. Views are different again: SQLite treats views as read-only unless they are paired with INSTEAD OF triggers. Those rules explain why some objects are comfortable to browse and edit quickly while others are better handled as read-mostly inspection targets or through precise SQL statements.

On this page, the summary counts come from user-defined entries in the schema table, the schema panel shows the stored CREATE statement for the selected object, and the fastest browse path asks SQLite for the selected object's first 100 rows together with a helper __rowid__ column. The custom query area can run broader SQL, but the results grid shows only the first returned result set. That makes ordinary rowid tables the smoothest path for quick browsing, while views, WITHOUT ROWID tables, and write-only statements need a more careful reading of the output.

Everyday Use & Decision Guide

Start in Browse when the file is unfamiliar. Selecting a table or view gives you three fast orientation cues at once: the database name and object counts, the stored schema text, and a capped preview of the object's first rows. That is usually enough to answer early questions such as whether you opened the right file, whether the object is a base table or a view, and which columns deserve a narrower follow-up query.

Move to Query as soon as the job needs joins, aggregation, typed values, or exact filtering. It is also the better path when the schema shows WITHOUT ROWID, when the selected object is a view, or when you need to write real SQL expressions such as NULL, arithmetic, or date functions. Keep multi-step work small and readable, because the grid shows only the first returned result set and because a narrow verification query is easier to trust than a long batch pasted all at once.

The inline grid edit mode is best treated as a quick text-fix lane. Each changed cell is queued and then written back in one save step keyed by the helper __rowid__ column. That is convenient for fixing a misspelled name, a short status value, or another obvious textual correction in an ordinary rowid table. It is the wrong fit for typed SQL updates, for complex predicates, and for objects whose write path depends on a composite key or trigger logic.

• Use the row-set downloads when you need the current query result in CSV, JSON, or DOCX.
• Use History to rerun past checks, but remember it keeps up to 40 unique query strings on the device until you delete them or clear site data.
• Use Export only when you want the whole current database file as a snapshot. The download is named with a .sql extension, but it is produced from the database bytes rather than rendered SQL text.

Before you trust any write, rerun a tight SELECT that isolates the changed row and compare the returned values against the schema you intended to edit. That follow-up query is the clearest checkpoint this page gives you.

Step-by-Step Guide

1. Load a local .db or .sqlite file through SQLite File and wait for the database summary badges to appear.
2. Stay in Browse for the first pass, pick a table or view, and read the Schema panel before you decide whether this is a read-only check or a candidate for a small edit.
3. If the default preview already answers the question, export that row set as CSV, JSON, or DOCX. If not, switch to Query and write a narrower SELECT.
4. Use Edit only for small text corrections on an ordinary rowid table. For anything that depends on the real primary key, typed values, or SQL functions, write the change in Query instead.
5. After any write, run a fresh SELECT that isolates the affected row or rows. Do not rely on the previous grid alone.
6. When you need a full-file handoff rather than a row-set export, use Export as the final snapshot step and then Unload if you want to clear the active file from the page.

Interpreting Results

The summary badges tell you what kind of database you opened, not whether the data is healthy. A high table count may simply mean the file belongs to a feature-rich app. A trigger count can signal background logic, but it does not say whether those triggers are good or bad. Treat the counts as orientation, then use the selected object's schema and row output to answer the real question.

The schema text is the most important trust check on the page. If it starts with CREATE VIEW, read the result as a derived row set rather than a base table. If it ends with WITHOUT ROWID, do not assume the browse-and-edit shortcut will behave like an ordinary rowid table. If it shows trigger references, remember that apparently simple writes may have side effects elsewhere in the file.

No results is easy to overread. Here it means the executed SQL did not produce a displayed row set. That can happen because the statement was a write, because it matched no rows, or because the first result set was empty. The right next step is not guesswork. Run a targeted SELECT that proves what changed or confirms that nothing matched.

Worked Examples

Example 1: review a handed-off app database before answering a support question

Suppose you receive orders.sqlite from a desktop app and need to confirm whether the last few orders have the right status. Load the file, stay in Browse, choose the orders table, and read the schema first. If the preview already shows the right columns, switch to Query and run SELECT id, status, updated_at FROM orders ORDER BY updated_at DESC LIMIT 20;. That gives you a tight answer without wandering through unrelated tables, and you can export the returned row set as CSV or JSON if someone else needs the same slice.

Example 2: make one safe text correction in an ordinary rowid table

Imagine the customers table contains one misspelled city name and the schema shows an ordinary base table rather than a view. Open that table in Browse, click Edit, fix the cell, and confirm the save button shows one pending change. Save it, then move to Query and run a narrow check such as SELECT rowid, city FROM customers WHERE rowid = 42;. That is the right pattern for a tiny text correction because the write is small, the row is isolated, and the verification query is explicit.

Example 3: treat a view or WITHOUT ROWID table as a precision job

Now imagine the schema says CREATE VIEW recent_orders ... or shows a table definition ending in WITHOUT ROWID. In that case, use the preview to understand the shape and then move to Query for any serious work. A read check such as SELECT * FROM recent_orders LIMIT 20; is fine. A write should be aimed at the real base table and real key columns, not at the browse shortcut. The preview still helps you understand the file, but the safe write path becomes deliberate SQL rather than inline editing.

FAQ

Glossary

Schema table

SQLite's internal catalog of tables, indexes, views, triggers, and their stored SQL definitions.

rowid table

An ordinary SQLite table that has 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 you read from it.

INSTEAD OF trigger

A trigger type SQLite uses to make writes against a view do useful work on underlying tables.

References

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