Open a SQLite database. Any size. Query it.
safe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQ
OmniViewer opens a .sqlite, .sqlite3 or .db
file — SQLite, the database inside every
phone, browser and a billion apps — right in your browser. Drop the file and you
can browse every table, run SQL against it, see the
schema as an entity-relationship diagram, and read the file
header byte by byte. There is no upload and no server, and the file is
opened read-only: nothing you do can change it.
Most in-browser SQLite tools load the whole file into memory first, which stops them
somewhere between a few hundred megabytes and 2 GB. OmniViewer doesn’t
load it at all. The official SQLite engine, compiled to WebAssembly, runs in a Web
Worker with a custom virtual file system: whenever SQLite needs a
page, the VFS reads just those bytes from the file on your disk. Opening the database
reads page 1 and the schema; looking up a row by its rowid reads one path down
the b-tree — three or four pages out of five million. So a 20 GB database
opens in about a second, and only the queries that genuinely need every row (an
unindexed filter, a count(*)) read the whole file — at disk speed,
with a live progress readout and a Cancel button.
The Query tab is SQLite itself, not an imitation: joins, CTEs, window functions,
json_extract and ->>, full-text search (FTS5), R*Tree,
math functions and EXPLAIN QUERY PLAN all work. Results arrive a page at
a time, so SELECT * on a billion-row table returns its first thousand rows
instantly. The query runs in its own worker, so a long scan never freezes the
table browser.
For how the format works on the inside — pages, b-trees, records and varints — and exactly how the page-reading VFS is built, see how to open a 20 GB SQLite database in the browser. Need a huge database to try it on? The SQLite test-database generator writes one of any size — or with 10,000 tables, or 2,000 columns.
OmniViewer opens every file format, powered by the same viewing engine as fastjsonviewer.com and hugecsv.com.
No. OmniViewer is a static page with no server-side processing: your .sqlite or .db file is read directly by your browser, and the SQLite engine runs locally in a Web Worker. The file never leaves your computer, and it is opened read-only, so nothing you run can change it.
It has been tested with a 20 GB database of 180 million rows. The file is never loaded into memory: SQLite reads it through a virtual file system that fetches only the pages each query touches, so opening the database and browsing its tables take about a second whatever the size. The only practical limit is the time a query takes when it genuinely has to read every row, which runs at the speed of your disk.
Yes. The Query tab runs the official SQLite engine compiled to WebAssembly against your file, so any read-only SQL works: SELECT with joins, CTEs, window functions, the JSON functions, full-text search, PRAGMAs and EXPLAIN QUERY PLAN. Results are paged a thousand rows at a time, and a long query can be cancelled.
Not yet — it is read-only on purpose. The file is opened with SQLite’s read-only and immutable flags and PRAGMA query_only, so INSERT, UPDATE, DELETE, schema changes and even TEMP tables are refused. That is what makes it safe to open a 20 GB production database in a browser tab: no query you type can change a byte of it. Anything you would put in a temporary table can be written as a WITH (common table expression) instead.
Any SQLite 3 database, whatever its extension: .sqlite, .sqlite3, .db, .db3, .s3db, .sl3 — and the SQLite files inside other apps, such as browser history, Android app databases, GeoPackage (.gpkg), MBTiles, Anki (.anki2) and iOS backups. The file is recognised by its first 16 bytes, "SQLite format 3". Encrypted databases (SQLCipher) cannot be opened, and a WAL-mode database opens without the uncommitted changes that may still sit in its separate -wal file.
It explains a column’s type like you are twelve. SQLite’s types are famously surprising — VARCHAR(255) never limits anything, BOOLEAN is just 0 and 1, DATETIME is text or a number, and DECIMAL(10,2) is a floating-point value — so each column header has an ELI12 button, once per type per table, with a plain-words explanation, the gotcha to watch for, and a link to a deeper article with examples and limits.
The first 100 bytes of every SQLite database: the "SQLite format 3" magic, the page size, whether it uses a rollback journal or a write-ahead log, the text encoding, the number of pages and free pages, the schema cookie, the user_version and application_id your app set, and the version of SQLite that last wrote the file. The Metadata tab decodes every field and shows its raw bytes.