SQL Playground — Edit & Query SQLite in Your Browser

Yes. Drop a .csv, .tsv, .json, .ndjson or .jsonl file onto the drop zone — or use ⇪ import above the schema panel — and it's turned into a real SQLite table. The importer sniffs the delimiter (comma, semicolon, tab or pipe), treats the first row as a header unless you say otherwise, and infers each column's type from its values. A preview shows the resulting columns and types before you commit, and you can rename the table first. Import more than one file and they land as separate tables in the same database, so you can JOIN two spreadsheets in a single query.

Each column is scanned and typed INTEGER if every value is a whole number, REAL if they're all numeric, and TEXT otherwise. Values with leading zeros (postcodes, product codes, phone numbers) and numbers longer than 15 digits stay TEXT on purpose, so nothing is silently mangled. Empty cells become NULL. If you'd rather keep everything as text, untick detect column types in the import dialog — or import as-is and fix it afterwards with ALTER TABLE or a CAST.

Yes — paste the address into the fetch from a URL box, or link straight to it with ?url=, e.g. /sql-playground/?url=https://example.com/data.csv. The fetch happens from your browser, so the file still never passes through any server of mine — but for the same reason the host has to send permissive CORS headers. Raw files on GitHub, most public data portals and object storage with public read usually work; a page that blocks cross-origin requests will fail, and you'll get an error saying so. Download the file and drop it in instead.

Yes. Start typing and a popup suggests your actual tables, views and columns alongside SQL keywords and SQLite functions. Type a table name or alias followed by a dot — c. after FROM customers c — and you get just that table's columns. ↑/↓ moves, Enter or Tab inserts, Esc dismisses, and Ctrl/⌘+Space forces the popup open. Brackets and quotes close themselves, and new lines keep the indentation of the line above. There's no syntax colouring — that's deliberate; the editor stays a plain, fast, copy-pasteable textarea.

Six. ⬇ csv and ⬇ json give you the raw result set; ⬇ md writes a column-aligned Markdown table you can paste straight into GitHub, Notion or Obsidian; ⬇ excel writes a UTF-8 CSV with a byte-order mark and a sep=; hint so Excel opens it with correct columns and accented characters instead of mojibake; ⬇ inserts generates INSERT statements for a table name you choose; and ⬇ db downloads the whole database as a real .sqlite file.

Yes. Click a table in the Schema panel to expand it, then click ✎ edit data. That opens a spreadsheet-style grid: click any cell to change its value, press Enter or click away to save it instantly, click the ∅ button next to a cell to set it to NULL, click 🗑 on a row to delete it, or click ＋ row to insert a new blank row. Every edit runs a real parameterized UPDATE/DELETE/INSERT behind the scenes — you're editing the actual database, just without typing SQL.

Yes. Click ＋ table above the schema panel to open the new-table wizard. Name the table, then add columns one row at a time — each with a name, type (TEXT/INTEGER/REAL/BLOB/NUMERIC), and optional PK (primary key), NN (not null) and default-value flags. Click ✓ create table and it runs the generated CREATE TABLE statement for you.

Yes. Expand a table in the schema panel and use ➕ column to add one, or hover any individual column to reveal ✏️ (rename) and 🗑 (drop) icons next to it. These run ALTER TABLE … ADD/RENAME/DROP COLUMN under the hood — the same statements you'd type by hand, triggered by a click instead.

Yes — expand a table and use ✏️ rename or 🗑 drop in the action row at the top of its column list. Dropping asks for confirmation first, since it permanently deletes the table and all of its data from the in-memory database.

The data grid relies on SQLite's implicit rowid to know which row to update or delete. Tables created with WITHOUT ROWID don't have one, so ✎ edit data shows a warning instead of opening the grid for those tables. You can still read and modify them with plain SQL in the editor — it's only the point-and-click grid that needs a rowid.

No — there's no undo/redo. Every edit, whether typed as SQL or made through the grid, writes directly to the in-memory database. DROP TABLE, DELETE, and a bad cell edit are all immediate and permanent for that session. If you're experimenting, export the .sqlite file (⬇ db) before a risky change so you have a copy to fall back to, and remember that reloading the page also resets everything to how it started (see below).

Yes. Whether you changed data through the grid, the schema tools, or raw INSERT/UPDATE/DELETE/CREATE TABLE/ALTER TABLE SQL, click ⬇ db in the run bar at any time to download the current state as a real .sqlite file. The original file on your disk, if you loaded one, is never touched or overwritten automatically.

No. The database lives entirely in your browser tab's memory. Refreshing, closing the tab, or navigating away discards it completely — there's no autosave to disk or to the cloud. Export with ⬇ db before you leave if you want to keep your changes; your (unrelated) query history is the one thing that is saved locally, see below.

Yes — nothing is uploaded. This page runs SQLite compiled to WebAssembly directly inside your browser tab. When you drop a .sqlite file, it's read by JavaScript via the File API and handed to the in-memory SQLite instance. No network request carries your data anywhere — not the file, not your edits, not your queries.

The only external request is the initial one-time download of the sql.js WASM binary from a public CDN (cdnjs). After that, everything — queries, grid edits, schema changes — runs entirely offline.

Full SQLite SQL — standard SQL plus SQLite-specific extensions: window functions, CTEs (including WITH RECURSIVE), JSON functions, FTS5, RTREE, and all the usual aggregates. PRAGMA and ATTACH DATABASE work too. What doesn't work: PostgreSQL-only or MySQL-only extensions (JSONB, ILIKE, MySQL's LIMIT x, y — use LIMIT y OFFSET x instead).

Yes. The editor runs its whole contents as a script, so you can separate several statements with semicolons and click ▶ Run once — useful for a batch of CREATE TABLE + INSERT statements, for instance. Only the result set from the last SELECT in the batch is displayed in the results grid; earlier statements still execute, they just don't get their own table below.

PRIMARY KEY, NOT NULL, UNIQUE, CHECK and DEFAULT are all enforced normally. Foreign-key references are recognized in CREATE TABLE, but SQLite ships with foreign-key enforcement off by default — run PRAGMA foreign_keys = ON; first if you want violations to actually be rejected.

Yes, both are built into the sql.js WebAssembly build this page uses. Create an FTS5 virtual table for full-text search, and use SQLite's JSON1 functions (json_extract, json_each, ->>, etc.) to query JSON stored in a TEXT column directly in SQL.

The practical limit is your browser's available memory — SQLite loads the whole database into RAM. Databases up to a few hundred MB are fine on a modern laptop; multi-gigabyte files will struggle or fail to load. For those, a desktop client like DB Browser for SQLite is a better fit.

Yes — drag it onto the dropzone, or click the dropzone to pick a file with .sqlite, .db, or .sqlite3. It's read locally with the File API and loaded straight into the in-browser database; nothing is transmitted anywhere. You can also start from a completely empty database, or load one of the three built-in samples instead.

Chinook — a media-store schema (artists, albums, tracks, invoices) used in almost every SQL tutorial. Good for joins and aggregates.

Northwind — the classic Microsoft demo database (customers, orders, products, employees).

Employees — a tiny HR-style database good for quickly testing syntax.

All three load fully in-memory and can be queried, edited in the grid, or altered freely — they're a safe place to try the editing tools before pointing them at your own file. Changes don't persist unless you export the .sqlite.

Four, all from the run bar after a query: CSV and JSON for the current result set, SQL to download the result set as ready-to-run INSERT statements (you're prompted for a target table name), and ⬇ db to download the entire current database as a real .sqlite file, including anything changed via the grid or schema tools.

The SQL editor runs whatever you type, on your own local data — there's no server for anything to be "injected" into. The data grid itself binds every cell value as a query parameter (UPDATE … SET col=? WHERE rowid=?) rather than splicing it into a SQL string, so a value like O'Brien or '; DROP TABLE x; -- typed into a cell is stored as literal text, not executed as SQL.

Yes — the last 50 queries you run are kept in your browser's localStorage (under a key specific to this page) and listed in the Query History panel with their timestamp, success/failure, and timing. Click any entry to load it back into the editor. This history is local to your browser only; clear it any time with the clear button.

No — each browser tab holds its own private, in-memory database, so there's no real-time syncing between people or even between your own tabs. To collaborate, export the .sqlite file and share it, or use a real server-hosted database (Postgres, MySQL, a hosted SQLite service) designed for concurrent access.

No, and it isn't trying to be. It's built for prototyping a schema, learning SQL, poking at a .sqlite file someone sent you, or doing a quick one-off edit — all without installing anything. For a production workload you want a proper server-hosted database with backups, concurrent access, and durability guarantees this in-browser, single-tab tool doesn't provide.

No. Everything — the SQLite engine, the editor, the data grid — runs inside this browser tab via WebAssembly. No account, no browser extension, no desktop app.

Yes, the layout is responsive and the data grid, schema tools, and editor all work on a touchscreen. That said, writing longer SQL queries is naturally more comfortable with a physical keyboard — for quick edits to a table's data through the grid, mobile works fine.

⌘ / Ctrl + Enter — run the current query.
⌘ / Ctrl + Shift + Enter — run only the selected text.
Tab in the editor inserts two spaces instead of moving focus.
In the data grid: Enter in a cell saves it and blurs; clicking away also saves.

Yes, completely free. No account, no subscription, no ads. It is one of the free browser-based tools at jasperbernaers.com.