See Inside Your Database thumbnail

How to View the Contents of a SQLite Database

Opening a SQLite database is easy. Understanding what’s inside can take longer. A real app database might have 40 tables with names like ZSYNCSTATE or android_metadata. Where do you even start?

This guide shows you how to view the contents of a SQLite database in an organized way. You’ll learn how to see every table, peek at the data, understand the structure, and find specific values. It works for any SQLite file, whatever app made it.

The fastest way to see what’s inside

Drop the file into our online SQLite viewer. In about a second you get:

  • A list of every table and view, with row counts
  • The rows of whichever table you click
  • A Structure tab with columns, keys and indexes
  • A Run SQL tab for custom questions

Nothing is uploaded, so you can safely explore private files like chat backups or browser history. If you haven’t opened a SQLite file before, our guide on how to open a SQLite file covers the basics first.

What a SQLite database contains

Before you explore, it helps to know the pieces. A SQLite database can hold five kinds of objects.

ObjectWhat it isWhere you see it
TableStores rows of dataSidebar, Data tab
ViewA saved query that acts like a tableSidebar under Views
IndexSpeeds up searches on columnsStructure tab
TriggerCode that runs when data changesSchema (CREATE statements)
SchemaThe blueprint of all the aboveStructure tab, sqlite_master

Most of what you care about lives in tables. Views are helpful shortcuts. Indexes and triggers tell you how the app uses the data, but they don’t hold data themselves.

Step 1: Get the full list of tables

In the viewer, the sidebar already lists them. If you prefer SQL, run this in the Run SQL tab:

SELECT type, name FROM sqlite_master
WHERE type IN ('table', 'view')
ORDER BY type, name;

sqlite_master is a special built-in table. It stores one row for every table, view, index and trigger in the database. It’s the table of contents.

We have a full guide on listing all tables in SQLite if you want more variations.

Step 2: Find the tables that matter

Big databases hide a few important tables among many small ones. Use these clues:

  • Row counts. Sort by size mentally. Tables with thousands of rows usually hold the main content.
  • Clear names. messages, contacts, notes, orders and history are obvious starting points.
  • Skip internal tables. Names like sqlite_sequence, sqlite_stat1, android_metadata and room_master_table are bookkeeping.
  • Check views first. Developers often create views that already join the useful data together.

To count rows in every table at once, you can run a query per table, or just read the counts in the viewer’s sidebar.

Step 3: Look at a sample of rows

Click a table. You see the first 100 rows. That’s usually enough to understand what it stores.

With SQL, grab a small sample like this:

SELECT * FROM messages LIMIT 10;

Always add LIMIT when exploring. It keeps results small and fast, even on huge tables.

Step 4: Understand each table’s structure

Open the Structure tab for the selected table. You’ll see each column’s name, type, whether it can be empty, its default value, and whether it’s part of the primary key.

The SQL way uses a PRAGMA command:

PRAGMA table_info(messages);

This returns one row per column. To see the exact statement that created the table:

SELECT sql FROM sqlite_master WHERE name = 'messages';

Reading column types

SQLite is flexible about types. You’ll commonly see:

  • INTEGER for whole numbers and IDs
  • TEXT for words, names and many dates
  • REAL for decimal numbers
  • BLOB for binary data like images
  • NUMERIC for values the app treats as numbers

A column’s declared type is a hint, not a strict rule. SQLite can store a text value in an INTEGER column. So always look at real rows too.

Step 5: See how tables connect

Most databases split data across tables. An order row holds a customer_id rather than the customer’s name. To read it properly, you follow that link.

Foreign keys show these links. In the viewer they appear in the Structure tab. In SQL:

PRAGMA foreign_key_list(orders);

Not every app declares foreign keys, though. If the list is empty, look for columns that end in _id and match another table’s name. That’s usually the link.

Once you know the link, a JOIN puts the data together:

SELECT o.id, c.name, o.total
FROM orders o
JOIN customers c ON c.id = o.customer_id
LIMIT 20;

Step 6: Search the whole database for a value

Sometimes you know a word, name or number but not where it lives. In the viewer, open each likely table and use the search box. It checks every column in that table.

In SQL, you can search one table across several columns:

SELECT * FROM contacts
WHERE name LIKE '%anna%'
   OR email LIKE '%anna%'
   OR phone LIKE '%anna%';

The % signs mean “anything before or after.” LIKE is not case sensitive for normal English letters.

Step 7: Check indexes and triggers

Indexes show which columns the app searches often. That hints at what matters. List them with:

SELECT name, tbl_name, sql FROM sqlite_master WHERE type = 'index';

Triggers show automatic actions, like updating a count when a message is added:

SELECT name, sql FROM sqlite_master WHERE type = 'trigger';

You don’t need these to read data. They’re useful when you want to understand how an app behaves.

A simple exploration routine you can reuse

When you open a database you’ve never seen, follow the same routine every time. It stops you from getting lost.

  1. Read the file size. A 50 KB file has little data. A 500 MB file has a lot. Set your expectations.
  2. List tables and row counts. Write down the three or four biggest tables.
  3. Open each big table and read ten rows. Don’t try to understand every column yet. Just get a feel for it.
  4. Check the Structure tab. Note the primary key and any columns ending in _id.
  5. Draw the links. On paper, draw arrows from each _id column to the table it points at.
  6. Write one JOIN. Combine the two most important tables so the rows make sense on their own.
  7. Export the result. Save it as CSV so you have a readable copy.

This takes ten to fifteen minutes on most app databases. After that, the database stops feeling like a puzzle.

Viewing contents of databases from common apps

Different apps have different layouts. A few quick pointers:

  • Chrome history: the urls and visits tables. See our Chrome history guide.
  • WhatsApp (Android): the message table in newer versions, messages in older ones. Our msgstore.db guide explains the rest.
  • Django projects: tables start with the app name, like blog_post, plus auth_ and django_ tables.
  • Android apps using Room: look past room_master_table to the real tables.

Exporting what you find

When you’ve found the data, export it. In the viewer, click Export CSV or Export JSON for a table or for any query result. Then open it in a spreadsheet. Our guides on SQLite to CSV and SQLite to Excel cover every detail.

Troubleshooting

I can’t see any tables

The file may be empty, or the real data may still be in a -wal file. Close the app that created the database, copy the database and any -wal file together, and try again.

The viewer says it’s not a database

The file may be encrypted or compressed. Our guide to the file is not a database error explains how to check.

Queries are slow

Add LIMIT to your queries. Searching huge tables with LIKE '%word%' can’t use indexes, so it scans every row. That’s normal.

Some text looks scrambled

The column may hold binary data, compressed text, or text in another encoding. Click the cell to see the full value. If it’s a BLOB, the viewer shows it as hex so you can tell it apart from normal text.

Want the technical detail? See the official SQLite schema table documentation.

Frequently asked questions

How do I see all the data in a SQLite database at once?

You look table by table. There’s no single view of everything, because each table has its own columns. Start with the biggest tables.

Can I view a SQLite database without SQL?

Yes. Our viewer lets you click through tables, sort, search and export without writing SQL.

What is sqlite_master?

It’s a built-in table that lists every table, view, index and trigger in the database, along with the SQL that created each one.

Is it safe to explore a database from an app I use?

Yes, if you work on a copy. Viewing never changes the file. Just don’t edit the live database an app is using.

Summary

To view the contents of a SQLite database, start with the table list, look at a sample of rows, check the structure, and follow the links between tables. Use the search box or a quick LIKE query to find specific values. You can do all of it in our free SQLite viewer without installing anything.

Similar Posts