How to Open a .db File: SQLite Viewers for Windows, macOS, and Linux

You double-click a .db file and your computer either does nothing, opens the wrong app, or shows you a wall of unreadable text. If that's why you're here, the short answer is this: a .db file is almost always a SQLite database, and there are four practical ways to open one — the sqlite3 command line, DB Browser for SQLite, DBeaver, or a local-first admin panel like BaseVolt. Which one you want depends on whether you're poking at data once or actually working with it.

But "almost always" is doing real work in that sentence, so before I hand you a tool, let's spend thirty seconds confirming what you actually have. The .db extension is not a standard — it's a convention, and plenty of other software uses it too. Opening a non-SQLite file with a SQLite tool is the single most common reason people think a tool is broken when it isn't.

Here's how to check, then we'll walk through each way to open the file.

First, Confirm It's Actually SQLite

Every SQLite database file begins with the same 16 bytes: the ASCII string SQLite format 3 followed by a null byte. This is called the magic header, and it's how SQLite itself recognizes its own files. If those bytes are there, you have a SQLite database no matter what the file is called. If they're not, you don't.

On macOS or Linux, the fastest way to check is the file command:

file mydata.db
# mydata.db: SQLite 3.x database, last written using SQLite version 3045000

file reads the magic header for you and tells you straight away. If it says SQLite 3.x database, you're done — that's a SQLite file. If it says something else — data, Microsoft Access, Paradox, Zip archive, ASCII text — then you're dealing with a different format entirely.

If you want to see the raw bytes yourself, on macOS or Linux:

head -c 16 mydata.db
# SQLite format 3

Or with xxd:

xxd -l 16 mydata.db
# 00000000: 5351 4c69 7465 2066 6f72 6d61 7420 3300  SQLite format 3.

On Windows, PowerShell can do the same thing without extra tools:

Get-Content -Path .\mydata.db -Encoding Byte -TotalCount 16 | ForEach-Object { [char]$_ }
# S Q L i t e   f o r m a t   3

If the header is there, congratulations — everything below applies to you. If it's not, keep reading for a moment, because there are a few common impostors.

What to do if it isn't SQLite

A file named something.db that isn't a SQLite database is usually one of these:

• A Microsoft Access database. Access files are typically .mdb or .accdb, but people rename them to .db all the time. If file reports it as a Microsoft Access database, you need Access or a tool that understands the Jet/ACE format — not a SQLite tool.
• A Paradox database. Borland's Paradox used .db for its table files, and these show up in old desktop software. Each .db is one table, and you need a Paradox reader or an ODBC driver.
• A proprietary application database. Some desktop apps, especially older ones, dump their state into a file with a .db extension using their own format. These aren't openable by anything except the app that wrote them, and sometimes not even then.
• A SQLite file with a non-standard name. The reverse case: your file might be SQLite but named .sqlite, .sqlite3, .db3, .s3db, or with no extension at all. SQLite doesn't care about the filename. If the magic header is present, it's SQLite regardless of the name.

That last point is worth emphasizing: .db, .sqlite, .sqlite3, and .db3 are all just conventions. The file format is identical. The extension only exists to help humans and to let your operating system pick a default application. If your file is SQLite but named data.txt, a SQLite tool will still open it — you may just have to point the tool at the file explicitly rather than double-clicking.

Four Ways to Open a .db File

Now that we know it's SQLite, here are the four tools I actually use, roughly in order from "quickest to reach for" to "most useful for ongoing work." Each has a different shape, and the right one depends on whether you're doing a one-off query or living in this database for a while.

1. The sqlite3 Command Line

The sqlite3 shell is the reference implementation, it ships with most Unix-like systems, and it's the fastest way to answer a question about a database without installing anything. The official documentation is at sqlite.org/cli.html, and it's worth a skim if you use the CLI more than occasionally.

If it's not already installed:

• macOS: it's preinstalled. Just open Terminal and type sqlite3.
• Linux: install it from your package manager — sudo apt install sqlite3 on Debian/Ubuntu, sudo dnf install sqlite on Fedora.
• Windows: download the precompiled tools from the SQLite website, or use winget install SQLite.SQLite or the sqlite3 package from Chocolatey.

To open a file, pass it as an argument. If the file doesn't exist, SQLite creates an empty one — so be careful to type the name correctly, or you'll silently get a new empty database:

sqlite3 mydata.db

Once you're in, you're in an interactive shell. Some commands start with a dot — those are meta-commands handled by the shell itself, not SQL sent to the database. The essentials:

-- List all tables in the database
.tables

-- Show the CREATE statement for every table (the full schema)
.schema

-- Show the schema for one table
.schema users

-- Make the output readable (boxed table instead of pipe-delimited)
.mode box

-- Turn on column headers
.headers on

-- Now run an actual query
SELECT id, email, created_at FROM users ORDER BY created_at DESC LIMIT 10;

-- Get the row count of a table
SELECT COUNT(*) FROM users;

-- Exit
.quit

The default output mode is list, which crams everything into pipe-separated lines and wraps horribly when your columns are wide. Switching to .mode box is the single biggest quality-of-life improvement in the CLI (.mode column is more compact but truncates long values).

A few more meta-commands that earn their keep:

-- Import a CSV into an existing table
.mode csv
.import data.csv users

-- Export a query result to a file
.output results.txt
SELECT * FROM orders WHERE total > 100;
.output stdout

-- Show how the database is configured (page size, journal mode, etc.)
.dbinfo

-- Back up the database to another file while it's open
.backup backup.db

The CLI is unbeatable for speed and scripting — you can pipe queries into it from shell scripts and cron jobs. Its weakness is everything else. Browsing data is unpleasant, editing a value means writing an UPDATE and getting the WHERE clause right, and there's no concept of a relationship or a view. It's a precision tool: I reach for it constantly for inspection and automation, rarely for actual data work.

2. DB Browser for SQLite

If you want a graphical tool and you only care about SQLite, DB Browser for SQLite is the obvious starting point. It's free, open source, cross-platform (Windows, macOS, Linux), and it's been around long enough to be genuinely stable. You can get it at sqlitebrowser.org.

The workflow is straightforward: launch it, click "Open Database," pick your .db file, and you get a tabbed interface with four main areas — Database Structure (the schema, tables, indexes, views), Browse Data (a grid of the rows in any table), Edit Pragmas (journal mode, foreign keys, and the other settings), and Execute SQL (a query editor).

The things it does well:

• Browsing. The grid view is fast and readable, with a filter box per column. This alone makes it better than the CLI for looking at data.
• Light editing. You can double-click a cell and change a value directly, then write the change to disk. Useful for fixing a typo or a bad row.
• Schema inspection. The Database Structure tab shows you exactly what's defined, which is great for a database you inherited and don't understand.
• Running ad-hoc queries. The Execute SQL tab has syntax highlighting and saves your query history.

The limitations are worth knowing before you commit to it:

• It's a viewer/editor, not an admin interface. You can't build a custom view, a dashboard, or a kanban board. What you see is what the tool decides to show you.
• It's SQLite-only. If you also work with PostgreSQL or MySQL, you'll need a second tool.
• Direct editing is unforgiving. When you edit a cell and commit, it writes straight to the file. There's no undo, no preview, no "are you sure." On a database that matters, that's a real risk.
• Relationships are limited. It shows foreign keys that exist in the schema, but it doesn't help you work with relationships that were never formalized — which, as I've written about before, is most real-world SQLite databases.
• It can hold a write lock. Like any tool that opens the database for writing, DB Browser can block your application if you leave it open on the same file. More on that in the troubleshooting section.

For a one-off "what's in this file?" task, DB Browser is excellent. For ongoing work, it tends to feel like a decade-old desktop app — because it is one, and it hasn't changed much in that time.

3. DBeaver

DBeaver is a general-purpose SQL client — it talks to SQLite, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, and dozens more through a single interface. It's free (Community Edition) and open source, and you can get it at dbeaver.io. If you already use a half-dozen database engines, having one client for all of them is genuinely valuable, and it's why DBeaver has such a loyal following. (See the DBeaver comparison page for a fuller breakdown.)

Opening a SQLite file is a two-step process, and the second step is where people get stuck:

1. Create a new connection and choose SQLite as the driver.
2. Point it at your .db file.

Because DBeaver is built on the Java ecosystem, it talks to SQLite through a JDBC driver. The Community Edition usually downloads the driver for you the first time you connect, but if you're offline or behind a firewall, you'll need to supply the driver JAR yourself. This is the single most common friction point with DBeaver and SQLite, and it's worth knowing about before you start.

Once connected, DBeaver gives you a lot:

• A proper query editor with autocomplete, formatting, and multiple result tabs.
• Schema browsing in a tree, with tables, columns, indexes, and constraints.
• Data editing in a grid, with the ability to generate the SQL for your changes before running them.
• ER diagrams that visualize tables and their foreign keys.
• Export and import in a wide range of formats — CSV, JSON, SQL, and more.

The tradeoff is that DBeaver is IDE-shaped. It's a large application, it takes a while to start, the interface has a lot of surface area, and it's built for people who live in databases all day. If all you want is to look at the contents of one .db file, DBeaver is a lot of tool for the job.

The other thing to be honest about: like DB Browser, DBeaver is a database client, not an admin panel. It shows you the raw tables. It doesn't give you gallery views, kanban boards, or dashboards, and it won't help you work with relationships that aren't in the schema.

4. A Local-First Admin Panel (BaseVolt)

The fourth option is a newer category, and it's the one I've ended up using most for actual work. A local-first admin panel is a desktop app that runs entirely on your machine, points at your database, and gives you a polished interface for browsing and editing — the kind of UI you'd normally have to build yourself or upload your data to a SaaS to get.

BaseVolt is the one I use, so I'll describe it concretely. It's a local-first desktop app for macOS (Apple Silicon) and Windows. It runs entirely on your machine, works offline, encrypts your credentials locally, and never sends your data anywhere — everything stays on localhost. It connects directly to PostgreSQL, MySQL, SQLite, and Cloudflare D1, so the same tool covers your whole stack.

For a .db file specifically, the workflow is almost insultingly short. You install the app, click "Add Data Source," and point it at the file. That's it. There's no connection string, no migration, no config, no schema changes. For a typical database you have a working dashboard in about three seconds. There's a live demo at demo.basevolt.app if you want to see it before installing anything.

What you get once it's open:

• Multiple views. A grid view for standard table browsing, a gallery view for image-heavy or rich content, a kanban view where you group records by any field (status, priority, assignee), and a dashboard for charts and stats.
• Relationships. It auto-detects schema relations with an LLM and visualizes foreign keys, so you can navigate from a parent row to its children and back. Crucially, it also lets you define relationships that don't exist in the schema — the implicit links that most SQLite databases have but never formalized. That matters because, as I covered in the foreign keys guide, SQLite can't even add a foreign key to an existing table without a full rebuild.
• Non-destructive customization. You can rename fields, format values, and join tables in the UI without altering your schema. Your application code that reads the same file won't notice a thing.
• A built-in MCP server on localhost, which means Claude Desktop, Cursor, Windsurf, and Codex can query your database directly through the app. The AI talks to BaseVolt, BaseVolt talks to your file — nothing goes to a third party.

The honest tradeoffs: it's a desktop app, so it's not a shared web dashboard for a team by default (the Pro tier adds cross-device sync), and it's a newer tool than DB Browser or DBeaver, so it has less of a track record. But for the specific job of "I have a .db file and I want to actually work with it," it's the tool I reach for. You can see the feature list on the features page, and the Hobby tier is free forever with two data sources and no account required, so trying it costs nothing.

Comparison Table

Here's how the four stack up against each other. "Editing records" is about how pleasant and safe it is to change data, not just whether it's technically possible.

Tool	Platform	Install effort	Best for	Editing records
sqlite3 CLI	Windows, macOS, Linux	None on macOS/Linux; small download on Windows	Fast inspection, scripting, automation	Manual UPDATE/DELETE only; no safety net
DB Browser for SQLite	Windows, macOS, Linux	Small download	Browsing a single SQLite file, light edits	Direct cell editing; no undo, writes immediately
DBeaver	Windows, macOS, Linux	Larger download; JDBC driver setup	Developers already using a multi-engine SQL client	Grid editing with generated SQL preview
BaseVolt	macOS (Apple Silicon), Windows	Small download	Ongoing work: views, relationships, dashboards	Inline editing with non-destructive UI layer

There's no single winner here. If I need to answer one question about a file, I use the CLI. If I'm opening someone else's database for the first time, DB Browser. If I already have DBeaver running for Postgres, I add SQLite to it. And if I'm going to be working with this database for more than a few minutes — browsing, filtering, building views, navigating relationships — I use BaseVolt.

How to Inspect a .db File Without a GUI

Sometimes you don't want to install anything. You're on a server, over SSH, or in a container, and you just need to know what's in the file. The sqlite3 CLI handles all of this, and a few one-liners cover most of what you'd want.

List every table:

sqlite3 mydata.db ".tables"

Get the full schema — every CREATE statement:

sqlite3 mydata.db ".schema"

Get the schema for one table:

sqlite3 mydata.db ".schema users"

Row counts for every table in one shot:

sqlite3 mydata.db "SELECT name FROM sqlite_master WHERE type='table';" | while read t; do
  echo -n "$t: "
  sqlite3 mydata.db "SELECT COUNT(*) FROM \"$t\";"
done

List tables with their column counts and a quick peek:

sqlite3 -header -column mydata.db "PRAGMA table_info(users);"

Check the file's page size and encoding:

sqlite3 mydata.db "PRAGMA page_size; PRAGMA encoding;"

Check integrity (useful if you suspect corruption):

sqlite3 mydata.db "PRAGMA integrity_check;"

A PRAGMA integrity_check; that returns ok means the file's internal structure is consistent. If it returns anything else, the file is damaged — which is one of the few situations where a GUI won't help you and you'll want to restore from a backup.

The one thing you can't easily do without a GUI is see the relationships between tables. The schema will tell you which foreign keys exist, but it won't tell you which columns should be related. For that, a tool that can visualize and let you define relationships is worth the install.

Troubleshooting: When a .db File Won't Open

Most of the time, opening a .db file just works. When it doesn't, it's usually one of these five problems.

"Database is locked"

This is the most common error, and it's almost always self-inflicted. SQLite allows only one writer at a time. If another process — your application, a running dev server, or another GUI tool — currently holds a write lock on the file, your new connection can't get one, and you get database is locked (or SQLITE_BUSY).

The fix is to find and close the other connection. Some things to check:

• Is your application still running and holding the database open?
• Do you have the file open in another SQLite tool — DB Browser, DBeaver, the CLI — in a different window?
• Did a previous process crash without releasing the lock?

If a process crashed and left a stale lock, the lock file is usually the culprit. In WAL (write-ahead logging) mode, SQLite keeps two sidecar files alongside your database: mydata.db-wal (the write-ahead log) and mydata.db-shm (shared memory). These are normal and expected — they're not corruption, and you shouldn't delete them while any process has the database open. If you're certain nothing has the file open and the lock persists, deleting the -shm and -wal files (after confirming no process is using them) will let SQLite rebuild them on the next open.

One important nuance: readers don't block each other, and in WAL mode a reader doesn't block a writer. If you're getting database is locked on a read, it's usually a writer holding the lock — a long-running transaction, or an application that opened the database in rollback-journal mode rather than WAL. If your application sets PRAGMA journal_mode = WAL; on connect, you'll see far fewer of these errors.

The file is empty or 0 bytes

A 0-byte .db file is not a database — it's an empty file. This happens more often than you'd think: an app creates the file on first launch and then crashes before writing anything, a download fails partway, or a copy operation silently produces nothing.

An empty file has no magic header, so every tool will either error out or offer to create a new database in it. If you're sure the data should be there, the file is likely gone — check for a backup, a .db-wal file that still holds uncommitted data, or a .db-journal file. If a -wal file exists next to a 0-byte database, the committed pages might still be recoverable, but you'd need to open it with SQLite and let it recover rather than deleting the sidecar files.

The file is encrypted and opens as garbage

Some applications encrypt their SQLite databases with SQLCipher, which is a fork of SQLite that adds transparent encryption. An encrypted SQLCipher database is a valid file, but its first 16 bytes are not the SQLite magic header — they're the encryption salt. So file won't recognize it, and a standard SQLite tool will either refuse to open it or show you binary garbage.

If you know the file is SQLCipher-encrypted, you need either a SQLCipher-enabled build of the CLI or a tool that supports SQLCipher, plus the encryption key. Standard SQLite cannot read it, and no amount of renaming or coaxing will change that. If you don't know the file is encrypted, this is one of the more confusing failure modes: the file is real and non-empty, but nothing will read it.

The file isn't SQLite at all

Back to where we started. If file reports something other than SQLite 3.x database, you're dealing with a different format — Access, Paradox, a proprietary blob, or a plain text or archive file that someone renamed. No SQLite tool will open it. Identify the format first (the file command usually tells you), then find a tool for that format.

Opening a .db file from a phone app or an Electron app

This comes up often enough to deserve its own note. If the .db file came from an iOS or Android app, or from a desktop Electron app (Slack, Discord, VS Code, and countless others are Electron), it's very likely a real SQLite database — and it will open fine in any of the tools above. A couple of caveats:

• It may be encrypted. Some apps use SQLCipher. See above.
• It may use WAL mode with sidecar files. If you copied only the .db file and left the -wal file behind, you may be missing the most recent writes. Copy all three files (.db, .db-wal, .db-shm) together if you want a consistent snapshot.
• The schema is the app's, not yours. You can read it, but editing it directly can break the app. Treat a third-party app's database as read-only unless you know exactly what you're doing.
• iOS apps sometimes use a different location. On iOS, the database lives inside the app's sandbox, and getting to it usually requires a backup extractor or a jailbroken device. That's beyond the scope of this post, but it's why "I can't find the file" is a common complaint.

When to Use What

A quick decision guide, based on what you're actually trying to do:

• You just need to answer one question about the file. Use the sqlite3 CLI. No install, no fuss.
• You're opening an unfamiliar database to see what's in it. Use DB Browser for SQLite. The structure and browse tabs are the fastest path to understanding an inherited file.
• You already use DBeaver for other databases. Add SQLite to it and keep one client for everything.
• You're going to work with this database repeatedly. Use a local-first admin panel. The time you spend installing it pays back the first time you need a filtered view, a joined table, or a kanban board — and you get all of that without modifying your schema, which matters for the reasons in the local SQLite admin panel guide.
• You're on a server or over SSH. The CLI is the only realistic option, and the one-liners above cover inspection and maintenance.
• You need to visualize relationships. Use a tool that shows them — either DBeaver's ER diagrams for keys that exist in the schema, or BaseVolt for both formal and implicit relationships.

If you're not sure, start with the CLI to confirm the file is SQLite and see its tables, then move to a GUI once you know you'll be spending time in it.

Bottom Line

A .db file is almost always a SQLite database, and confirming that is the first step — check the SQLite format 3 magic header with file or the first 16 bytes, and if it's not there, figure out what you're actually holding before you blame the tool. The extensions .db, .sqlite, .sqlite3, and .db3 are all the same format; the name tells you nothing.

Once you know it's SQLite, pick your tool by what you're doing:

• The sqlite3 CLI for fast inspection, scripting, and server work. Learn .tables, .schema, and .mode box and you'll use it forever.
• DB Browser for SQLite for browsing a single file and making light edits. Free, simple, and SQLite-only.
• DBeaver if you already live in a multi-engine SQL client and don't mind the JDBC setup.
• A local-first admin panel like BaseVolt when you want to actually work with the data — grid, gallery, kanban, and dashboard views, relationship navigation, and a non-destructive UI layer that leaves your schema alone.

And when something won't open, it's almost always one of five things: a lock held by another process, an empty file, SQLCipher encryption, a non-SQLite format, or a copied database missing its -wal sidecar. Knowing which one you're looking at turns a frustrating dead end into a two-minute fix.

If you want to see the admin-panel approach before committing to anything, there's a live demo at demo.basevolt.app, and you can grab the app from the download page — free, no account required, and it runs entirely on your machine.

If you found this useful, I write about databases, local-first software, and the unglamorous parts of building dev tools. Find me on X.