SQLite to JSON Converter
Open a .db file without a database client. Every table with rows is listed, the one you choose becomes typed JSON, and the file never leaves your machine.
To convert SQLite to JSON, drop your .db, .sqlite or .sqlite3 file above. The database is opened in your browser, every table with rows is listed, and the one you choose becomes an array of objects keyed by column name with a single type per column. Choose a pretty array, a minified one, or JSON Lines.
Want to join two tables first? Open the app
The .db file on your desktop
SQLite is the most deployed database in the world and its files turn up everywhere: an application's local store, a mobile app backup, a browser profile, an exported dataset, the artefact attached to a bug report.
Reading one means the sqlite3 command line, or a GUI client, or a Python session. All are easy to obtain and none is available on a locked-down machine, and none of them is a reasonable ask for someone who just wants to see what is in the file.
Here the database is opened in the page and every table with rows is listed within a second of the drop.
Several tables, offered rather than guessed at
A database file holds many tables the way a workbook holds many sheets, so it reuses the same control. The first table with rows converts on arrival and every table that has rows is listed underneath with its name, so switching is one click.
Empty tables are left out of the list rather than offered as choices that produce nothing. Schema-migration bookkeeping tables are usually the first thing in a database by creation order, so an alphabetical or creation-order pick would hand you those every time.
Views are not included. A view is a query rather than stored data, and running it would mean interpreting SQL this reader does not execute. If you need a view's output, materialise it into a table first with a CREATE TABLE AS in your own client.
Types, and SQLite's unusual relationship with them
SQLite is dynamically typed in a way no other database is. A column declared INTEGER can hold a string, the declared type is an affinity rather than a constraint, and a single column can genuinely contain values of different storage classes.
So the column type here is decided from the values rather than from the declaration. A column is numeric only when every value in it round trips exactly, boolean only when every value is a lowercase true or false, and text otherwise.
That is stricter than SQLite itself and it is what makes the JSON usable: a key that is a number on one object and a string on the next is rejected by any schema check, and in SQLite that situation is not a bug in the converter, it is genuinely what the table contains.
Worked example
A customers table:
[
{
"customer_id": 1001,
"name": "Omar Dijkstra",
"email": "omar.dijkstra40@example.com",
"city": "Miami",
"signup_date": "2025-01-18",
"loyalty_points": 4446
}
]
customer_id and loyalty_points are numbers because every value in those columns is an exact integer. signup_date is a string, because SQLite has no date type at all: dates are stored as text, as numbers, or as Julian days, and this emits exactly what is stored rather than guessing which convention the application used.
Nothing is uploaded, and that is the point
The hosted converters for these formats all want the file. That is a fine trade for a photograph and a poor one for a database extract, which is what these files almost always are: customer tables, transaction detail, event streams with identifiers in them.
Everything here runs inside the page. The file is read by JavaScript in your tab, the output is built there, and the download comes out of memory. Nothing is sent, stored or logged, and once the page has loaded the tool works with the network off.
The practical ceiling is your tab's memory rather than an upload quota. Past a hundred megabytes or so the full editor streams and is the better route.
Frequently Asked Questions
Do I need sqlite3 or a database client?
No. The database file is opened inside your browser tab. That is the point of the page: reading a .db on a machine where you cannot install a client, or handing the job to somebody who does not use one.
My database has twelve tables. Which one do I get?
The first with rows converts immediately and every table that has rows is listed underneath, so switching is one click. Empty tables are left out rather than offered as choices that produce nothing.
Are views included?
No. A view is a query rather than stored data, and running it would mean executing SQL this reader does not evaluate. Materialise it into a table with a CREATE TABLE AS in your own client if you need its output.
Why is a column declared INTEGER coming out as strings?
Because at least one value in it is not an integer. SQLite's declared types are affinities rather than constraints, so a column can genuinely hold mixed storage classes. The type here is decided from the values, which is stricter than SQLite and is what makes the JSON safe to consume.
Why are my dates strings?
Because SQLite has no date type. Dates are stored as text, as numbers, or as Julian day values, and which one an application chose is not recorded anywhere. The stored value is emitted exactly rather than being reinterpreted on a guess.
Is the database uploaded?
No. It is opened and read inside your browser tab and nothing is sent, stored or logged. A .db file is frequently an application's entire local state, which makes this the deciding factor for most people using the page.
Open the database file
Every table offered, one type per column, nothing uploaded.
Back to the converter