SQLite Online Sandbox: Query a .db File in Your Browser

Run queries and view a schema ERD against a local SQLite file, zero upload.

This runs a real SQLite engine compiled to WebAssembly, not a lookalike query language, so the SQL dialect, functions, and error messages are SQLite's own. It loads a .sqlite file you drop in, or starts a blank database from a pasted CREATE TABLE statement, and every query executes against an in-memory copy inside a dedicated worker so a slow join never locks up the tab.

How to open and query a SQLite file online

1. Drop a .sqlite, .sqlite3 or .db file onto the load area, or click it to choose one; to start from nothing, click Or start with an empty database instead.
2. Type SQL into the query box (CREATE TABLE and INSERT work fine in an empty database), press Format SQL if you want it tidied, then click Run query.
3. Read the rows in the result table, which also reports the row count and how many milliseconds the query took.
4. Switch from Query to ERD to see every table with its columns and the foreign keys linking them.
5. Click Export .sqlite to download the database with all your changes, so you can reopen it here or in any other SQLite client.

Why closing the tab loses your database

The loaded database lives entirely in memory, deserialized from the bytes you provided into a plain :memory: SQLite instance. There is deliberately no persistence layer writing it back to disk between sessions.

Real cross-reload persistence in the browser needs the Origin Private File System, and OPFS needs SharedArrayBuffer, which in turn needs the whole site to opt into cross-origin isolation response headers. That's a site-wide change with side effects far beyond this one tool, so it isn't enabled here. The way to keep your work is the Export button, which writes the current database back out as a downloadable .sqlite file you can reload next time.

What loading a file actually does

Dropping in a .sqlite file hands its raw bytes to sqlite3_deserialize inside the worker, which builds a live in-memory database from them without ever touching a real filesystem path. Pasting a CREATE TABLE or INSERT statement into the omnibox instead starts from a genuinely blank in-memory database, since there's no existing file for a snippet like that to attach to.

Either way, the same worker owns the one loaded database for the rest of your session, and the main thread only ever exchanges small request/response messages with it — a query going in, a result set and a refreshed schema coming back.

Seeing the schema, not just the rows

Every successful load or query refreshes an entity-relationship diagram built by crawling sqlite_master for tables and views, then pulling PRAGMA table_info for each table's columns and PRAGMA foreign_key_list for its declared foreign keys. That's read directly from what SQLite itself reports about the loaded schema, not inferred by scanning your query text.

A query result comes back as a plain result table with column names and row values; binary BLOB columns render as a byte count rather than attempting to decode arbitrary binary data into text.

What this sandbox is not

• Not a multi-user database: there's exactly one loaded database per tab, with no concurrent connections or transaction isolation to reason about
• Not persistent storage: refreshing the page without exporting first discards every change since the file was loaded
• Not a substitute for testing against your actual production database engine if you're on Postgres, MySQL, or SQL Server — SQLite's dialect, type affinity rules, and function set differ from all three in ways that matter for real query compatibility
• Not a place to load anything containing real user data you wouldn't want held in an unencrypted in-memory buffer for the length of your browser session

SQLite file types and size limits

• The file chooser offers .sqlite, .sqlite3 and .db files. The engine reads the bytes, not the name, so a file that isn't really a SQLite database fails to load with SQLite's own error message.
• This tool has no size cap and no free-tier limit; as the load area puts it, the only ceiling is your device's RAM.
• The whole database is read into memory and then copied into the engine's WebAssembly heap, so opening a large file needs noticeably more free memory than the file's size on disk.
• Only one database is open per tab. Loading a second file closes the first one, discarding any changes you haven't exported.
• Exports are named after the file you loaded with -export.sqlite appended, or database-export.sqlite for a database you started empty.

Starter queries to explore an unknown database

• SELECT type, name FROM sqlite_master ORDER BY type, name; lists every table, view, index and trigger in the file.
• SELECT sql FROM sqlite_master WHERE name = 'orders'; prints the exact CREATE statement that defined the orders table.
• PRAGMA table_info(orders); shows each column's name, declared type, NOT NULL flag, default value and primary-key position.
• PRAGMA foreign_key_list(orders); lists the foreign keys on orders and which table and column each one references.
• SELECT COUNT(*) FROM orders; tells you how big a table is before you pull rows from it.
• SELECT * FROM orders LIMIT 20; previews sample rows. Keep the LIMIT on big tables, because the result table renders every row a query returns.

Questions people ask about SQL Sandbox

Why did my query results disappear when I reloaded the page?

The database only ever exists in the worker's memory for that page load; there is no disk or browser-storage persistence layer behind it. Export the database as a .sqlite file with the Export button before reloading or closing the tab if you want to keep the current state, then load that file back in next time.

Can I use this to test a MySQL or PostgreSQL query?

Not reliably. The engine underneath is genuine SQLite, and its SQL dialect, type coercion rules, and built-in functions differ from MySQL's and Postgres's in places that matter — window function syntax, date arithmetic, and strict typing being common trip points. Treat results here as SQLite-specific rather than a stand-in for another engine.

Does my uploaded database file get sent anywhere?

No. The bytes you drop in are deserialized directly into an in-memory SQLite instance inside a Web Worker running in your own browser tab. The only network request the tool makes at all is fetching its own SQLite WASM binary, which carries none of your data.

Why is there no autosave or cloud sync option?

Persisting a database across page reloads in a browser requires the Origin Private File System, which itself requires the whole site to run under cross-origin isolation. That's a larger site-wide tradeoff outside this tool's scope, so the export-to-file workflow is the supported way to save your work instead.

Which database files can I open — .db, .sqlite, or .sqlite3?

All three. The file chooser filters for those extensions, and dragging a file onto the load area skips the filter entirely because SQLite judges the contents, not the name. A file in another format, or a corrupt one, simply fails to load and shows the engine's error text.

Is there a file size limit for SQLite databases?

The tool sets no cap and there is no paid tier for bigger files. The practical ceiling is how much memory your browser will give one tab, because the entire database is held in RAM, so a multi-gigabyte file can fail on a machine with little free memory.

How do I save or share my database and queries?

Click Export .sqlite to download the full database, including every table and row you created or changed, then send that file or load it back here later. Query text is neither saved nor encoded in a link, so keep queries you care about in a .sql file or note.

Related tools on BrakeTools

• Mock Data & Fake Database Generator — Generate up to 250,000 rows of realistic test data locally, export as SQL, JSON, CSV, or Excel.
• JSON Formatter & Type Generator — Format, minify, and generate types from JSON payloads up to 100MB+, no freeze.

Content reviewed 2026-09-27.