Browse a SQLite database online
Open .db / .sqlite / .db3 tables and schema in your browser — no install, no upload.
Drop your database anywhere on this page
Read entirely in your browser — your data is never uploaded.
You have a .db file — an app export, a browser profile, a dataset from a course or a colleague — and you need to see what is inside it. The traditional answer is installing a database client or the sqlite3 command line; the online answer, at most "SQLite viewer" sites, is uploading your database to their server. This page does neither. Drop the file on it and the tables render right here: one grid per table, the CREATE statement folded openable above the rows, values shown in place, and a CSV export per table. The engine is real SQLite compiled to WebAssembly, running in your tab — your data never leaves your machine.
Because a database is usually the most sensitive file in an archive — real users, real orders, real messages — the no-upload property is not a nicety here; it is the whole point. You can verify it the usual ways: DevTools shows no request carrying your file, and once the page is loaded you can go offline and keep browsing.
What you get, table by table
The viewer is a reader, honest about what it shows.
- A grid per table — every user table opens as its own tab, sticky headers, row numbers, and the table's own column names. System tables (
sqlite_*) stay out of the listing: that is engine bookkeeping, not your schema. - The schema, first-class — each table's CREATE TABLE statement sits folded above its rows, so "what columns does this have and how are they typed" answers itself before you scroll a single row.
- Honest values — SQL
NULLrenders as a distinct token (not an empty string you have to guess about), binary BLOB values show as a size placeholder like(2048 bytes)instead of raw bytes, and very long text trims at 512 characters for display. - CSV export per table — the status bar offers the active table as a
.csv, exactly the rows and columns shown. Switching tabs switches the export with you. - A stated row limit — the first 1,000 rows of each table render, and the viewer says so in plain words when a table is cut. Reading more of a huge table is what the CSV and a local client are for.
Why "no upload" matters more for databases
A zip of photos is sensitive; a database is worse. .db files from real systems hold usernames, email addresses, order histories, private messages, sometimes password-reset tokens — and the people in them never agreed to a third-party copy. An online viewer that uploads the database to process it creates exactly that copy, on infrastructure you do not control, under a retention policy you have not read.
This page has nothing to upload to: the SQLite engine is WebAssembly loaded once from this site, and it reads your file inside your own browser. That is a structural claim, not a policy promise — the Network tab proves it, and so does going offline after load and keeping full access to every table. The broader picture is on security and privacy.
The .db name game — and how the viewer stays honest
.db is one of the most overloaded extensions in computing. Windows alone will hand you Thumbs.db (an OLE compound file, not SQLite); applications from chat clients to games ship proprietary .db files; and SQLite itself uses the same three letters. A viewer that trusts the extension renders garbage or crashes; a honest one checks the bytes.
Every file here is checked against SQLite's real signature — the 16-byte SQLite format 3\0 header — before the engine is even downloaded. A non-SQLite .db gets a plain-language refusal naming the likely suspects (Thumbs.db included), and a real database opens whatever spelling it carries: .db, .sqlite, .sqlite3, or .db3 — all the same format inside. See open a .db online, open a .sqlite online, and open a .db3 online.
Where these files come from
SQLite is quietly the most deployed database engine on Earth: every Android phone and iPhone app that stores data offline, every major browser's history and cookies store, WhatsApp and Signal message archives, most embedded devices, and countless desktop applications. When you extract one of those apps' data or export a backup, a .db file is what lands in your downloads.
Developers meet the same files from the other side — a Rails development.sqlite3, a Python script's sqlite3.connect("app.db"), a fixture in a test suite. Being able to drop any of them on a page and see the schema and rows — without installing anything, without a copy of the data leaving the machine — is useful on both sides of that line.
Honest limits
A browser-based database reader has real boundaries, stated up front.
- It reads; it does not query. There is no SQL box — you browse tables and export CSV. The engine underneath is real SQLite, so interactive queries are a genuine future possibility, but nothing here promises them today.
- 1,000 rows per table. The grid renders the first thousand rows with a stated truncation notice; bigger tables are for the CSV export and a local client.
- BLOBs are placeholders. Binary values show as
(N bytes); images stored as blobs do not render, and hex-dumping a blob is not what a browser grid is for. - 128 MB ceiling. The whole database loads into the engine's WebAssembly heap, so past 128 MB the viewer refuses honestly rather than exhausting the tab.
- Encrypted databases refuse. SQLCipher and friends encrypt the whole file; the viewer says it cannot open them instead of failing cryptically.
Frequently asked questions
How do I open a .db file online?
Drop it on this page. The database opens in the browser — every user table as a grid with its CREATE statement, up to 1,000 rows per table, CSV export per table. No database client, no upload; the SQLite engine runs as WebAssembly in your tab.
Is my database uploaded anywhere?
No — and for a database that matters, because these files usually contain real people's data. The engine is WebAssembly running locally; no server ever receives the file. Confirm it with DevTools (the Network tab shows no upload) or by going offline after the page loads — browsing keeps working.
Can it open a Thumbs.db file?
No, and it says so instead of showing garbage. Thumbs.db is an OLE compound file (Windows Explorer's thumbnail cache), not SQLite — and .db is used by many formats. The viewer checks the 16-byte SQLite format 3 header of every file before opening it.
Does it support .sqlite, .sqlite3, and .db3 too?
Yes — all four spellings are the same SQLite format inside, and the viewer opens them identically: .db, .sqlite, and .db3 each have their own page as well.
Can I run SQL queries or edit the data?
Not in this viewer — it browses tables, shows the schema, and exports CSV; it does not execute queries or write changes. The engine under it is real SQLite compiled to WebAssembly, so interactive querying is a plausible future, but nothing promises it today.