Skip to main content

SQLite viewer online

Browse tables, view schema, run SQL queries, and export data from a SQLite database.

Free & unlimited

Uses sql.js loaded from a CDN. Your file stays in your browser.

All processing happens in your browser. No data is sent to any server.

A .db file from an app backup, a Django project or a phone export is a real relational database, and the usual ways to look inside it are installing a desktop database browser or handing the file to a site that wants it on their server first. This page runs SQLite itself — the sql.js WebAssembly build of the actual SQLite engine — inside the tab, so your file is opened in page memory and queried there. You get the table list from sqlite_master, the original CREATE TABLE statements, PRAGMA table_info for the selected table, a paged row browser, a free-text filter across all columns, and a SQL box where anything SQLite understands runs for real.

Key facts about SQLite viewer online

Key facts about SQLite viewer online
Enginesql.js — SQLite compiled to WebAssembly. The real engine, so real SQL, not a parser imitating one
Where the engine comes fromThe sql-wasm.js loader and its .wasm file are fetched from the sql.js.org CDN on first use. Your database file is not part of that request
Accepted extensions.sqlite, .db, .sqlite3, .db3
Table listSELECT name FROM sqlite_master WHERE type=table, sorted by name
Schema viewThe stored CREATE TABLE text for every table, exactly as SQLite holds it
Column infoPRAGMA table_info: cid, name, declared type, NOT NULL flag, default value and primary-key position
Row countA real SELECT COUNT(*) per selected table, not an estimate from the page count
Paging50 rows per page via LIMIT and OFFSET, so paging is done by SQLite rather than in JavaScript
FilterTyped text becomes CAST(col AS TEXT) LIKE %text% ORed across every column of the table, with quotes escaped
SQL boxAny statement the engine accepts, including joins, CTEs, PRAGMA and writes — writes hit the in-memory copy only
ExportCSV of a whole table, or CSV of the current query result set
Write safetyThe file on disk is never modified. Changes live in the WebAssembly copy and vanish when you close the database

What happens to your file

Your database is read with FileReader into an ArrayBuffer and handed to a SQLite instance running as WebAssembly inside this tab; every query executes against that in-memory copy. The file is never uploaded, and no query text is sent anywhere. One honest caveat: the sql.js engine itself is loaded from the sql.js.org CDN the first time you use the page, so that host sees a request for a JavaScript and a WebAssembly file and your IP address — it never sees your database, your table names or your SQL. CSV exports are assembled in the tab and downloaded locally. Closing the database or the tab frees everything.

About this tool

  1. 1

    Wait for the engine, then drop the file

    The drop zone stays disabled with a loading note until sql.js has finished downloading. Then drag in a .sqlite, .db, .sqlite3 or .db3 file, or pick it from the file dialog.

  2. 2

    Pick a table from the sidebar

    Every table found in sqlite_master is listed. Selecting one runs SELECT * FROM table LIMIT 50 and shows PRAGMA table_info plus a real COUNT(*) alongside.

  3. 3

    Page or filter the rows

    Use the page arrows to move through the table 50 rows at a time. Typing in the filter box builds a LIKE across every column, which is the fastest way to find the row containing a known email or id.

  4. 4

    Switch to schema when the structure is the question

    The schema view prints the stored CREATE TABLE statements. That is where you see the foreign keys, the CHECK constraints and the exact declared types the row grid hides.

  5. 5

    Write SQL for anything else

    Edit the query box and run it. Joins, GROUP BY, window functions, CTEs and PRAGMA statements all work because the engine is genuine SQLite, not an emulation.

  6. 6

    Export the answer

    Export the selected table as CSV, or export just the current result set. Both download straight from the tab.

Specs & compatibility
File formats.sqlite, .db, .sqlite3, .db3 — any SQLite 3 database file
SQLite versionWhatever the current sql.js build ships, a standard SQLite 3 build
Page size50 rows (LIMIT 50, OFFSET n × 50)
Result sortingClick a result column to sort the fetched page; numeric-looking values sort numerically
ExportCSV, all values quoted with doubled inner quotes, NULL written as an empty field
Network neededOnce, to fetch the sql.js engine from sql.js.org; never for your data
Browser supportAny browser with WebAssembly — Chrome, Edge, Firefox, Safari, desktop and mobile
Encrypted databasesNot supported. SQLCipher and other encrypted variants will not open
Cost / accountFree, unlimited, no signup
  • The query box is pre-filled with the LIMIT 50 statement for the selected table — edit it in place instead of retyping the table name.
  • The filter is a LIKE across every column cast to text, so it finds a number inside an integer column as readily as a substring in a name.
  • Run PRAGMA foreign_key_list(tablename) in the SQL box to see relationships the CREATE TABLE text makes hard to read.
  • Sorting a result page sorts only the 50 rows that were fetched; put ORDER BY in the SQL when you need the whole table ordered.
  • UPDATE and DELETE run against the in-memory copy, so the page is a safe scratchpad for testing a destructive statement before you run it for real.
  • sqlite_master itself is queryable: SELECT type, name, sql FROM sqlite_master lists indexes, views and triggers as well as tables.
  • Exporting the query result rather than the table is the shortcut for handing someone a filtered CSV extract.
  • Real SQLite via sql.js WebAssembly
  • Table list from sqlite_master
  • CREATE TABLE schema view
  • PRAGMA table_info column details
  • Exact row counts
  • 50-row paging with LIMIT and OFFSET
  • Cross-column LIKE filter
  • Free-form SQL query box
  • CSV export of a table or a result set
  • Looking inside an app backup or an exported .db file without installing a database tool.
  • Checking what a Django, Rails or Expo project actually wrote to its development database.
  • Reading a SQLite file on a locked-down work machine where you cannot install software.
  • Rehearsing a migration query against a copy before running it against the real database.
  • Pulling one filtered table out of a database as CSV for a spreadsheet or a report.
  • Teaching or learning SQL against a real database file with no setup step.
  • Confirming a schema change shipped by reading the stored CREATE TABLE text.
No. The file is read locally and opened by a SQLite engine compiled to WebAssembly that runs inside this browser tab, so every query executes on your own machine. There is no upload endpoint and no server-side copy. The one network request the page makes is for the sql.js engine itself, which is fetched from the sql.js.org CDN — that request contains no part of your database, no table names and no SQL, only a request for a script and a WebAssembly file.
You can run INSERT, UPDATE, DELETE and DDL, and the results are visible immediately, but the changes apply to the in-memory copy only. The original file on your disk is never touched, and there is no save-back step, so anything you change is discarded when you close the database or the tab. That makes the page a good place to rehearse a risky statement, and the wrong place to do real data entry.
The whole file is read into memory before SQLite sees it, so the practical ceiling is browser memory rather than a published number. Tens of megabytes open comfortably on a normal laptop; multi-gigabyte files will not. Because paging uses LIMIT and OFFSET inside SQLite rather than loading rows into JavaScript, browsing a large table stays responsive once the file has opened — it is the initial load that costs.
No. sql.js ships a standard SQLite build with no encryption extension, so an encrypted database fails to open with a file-is-not-a-database style error. The same applies to WAL sidecar files: if your database was copied mid-write and its -wal and -shm files were left behind, open a properly checkpointed copy instead, or the most recent committed data may be missing.
Everything the bundled SQLite build supports: joins, subqueries, common table expressions, window functions, GROUP BY, JSON functions, views, triggers, PRAGMA statements and full-text search where the build includes it. Only one statement is displayed at a time — the grid shows the first result set the engine returns — so run multi-statement scripts one statement at a time if you need to read every output.
It is not a full-text index. The text you type is escaped and turned into CAST(column AS TEXT) LIKE %text% for every column of the selected table, joined with OR, and appended to the paged SELECT. That means it matches partial values anywhere in any column, including inside numbers and dates, which is what you want when hunting a known id; it also means it scans the table, so on a very large table a targeted WHERE clause in the SQL box is faster.

Related tools

View all

Part of File viewers that open the file in your browser

Related categories1

Updated

We use anonymous analytics to improve ToolChamp. No personal data is stored or sold. Privacy Policy