Конвертируйте SQL CREATE TABLE в JSON
Tool guide
This page reads a definition rather than data: give it CREATE TABLE users (id INT, name VARCHAR(50), age INT) and it returns JSON holding the table name and a list of columns with their declared types. That is how a schema out of a dump reaches an API document, a test fixture or an analyst's ticket without anyone spinning up the database. Parsing happens in the page, so your SQL stays local. SELECT and INSERT statements are not handled. See also: view the generated schema as a table, validate the schema structure, move the schema over to YAML.
No. The page reads a column declaration — it answers what fields exist, not what is stored in them, and it does not interpret INSERT statements. If you actually have exported data, convert it from CSV instead: the CSV to JSON page turns a header row into keys and each data row into an object.
Column declarations look nearly identical across MySQL, PostgreSQL and SQLite, so a plain CREATE TABLE listing names and types parses the same way in all three. The divergence starts after that: ENGINE and CHARSET clauses, SERIAL columns, schema prefixes, backticks around identifiers. Trim those tails before pasting and keep the parenthesised column list.
The parser is deliberately small and aims at the name and type pair. Constraints written as separate lines after the column list may not appear in the output, and modifiers such as NOT NULL DEFAULT 0 can be glued onto the type as text. Read the result before you trust it, and restore constraints by hand if a migration generator consumes it.
Feed one statement at a time. The parsing expects a single declaration, and several CREATE TABLE blocks in the box produce a partial or confused result. Split the dump, run each statement, then assemble the objects into one array in your editor — that pass also shows you which tables the parser could not handle.
Check three things: the text contains the CREATE TABLE keywords, the parenthesis around the column list is closed, and no multi-line comments are left inside. Snippets copied from a database client often drag backticks and line breaks along with them. Strip the extras down to something close to the placeholder line and try again.
The whole parse runs in a script inside the open page; the SQL Input content is not sent to it-market.pro or anywhere else. That matters for schemas, since table and column names often reveal how a product is built. If your company policy forbids pasting schema into web pages at all, follow the policy anyway.
Before: CREATE TABLE users (id INT, name VARCHAR(50), age INT);
After: { "table": "users", "columns": [ {"name": "id", "type": "INT"}, {"name": "name", "type": "VARCHAR(50)"}, {"name": "age", "type": "INT"} ] } Before: CREATE TABLE orders (id INT, total DECIMAL(10,2), created_at DATETIME);
After: { "table": "orders", "columns": [ {"name": "id", "type": "INT"}, {"name": "total", "type": "DECIMAL(10,2)"}, {"name": "created_at", "type": "DATETIME"} ] } Your rating and feedback help decide what to improve next.