SQL Studio — Format, Analyze & Convert

Paste SQL to format, minify or analyze it for your dialect. Strings and comments are never altered, UPDATE/DELETE without WHERE and DROP are flagged, and value lists or CSV rows become IN clauses and INSERT statements — all on your device.

On-device・No upload

Your files and input are processed only inside your browser on this device and are never uploaded to our servers.

Input SQL
0 chars0 lines
OutputThe result appears here as you type.
The result appears here as you type.

How to use

  1. Pick a mode — Format, Minify, Analyze or Converters — and paste SQL into the input pane (you can also open or drop a .sql file).

  2. Choose the dialect (Standard SQL, MySQL, PostgreSQL, SQL Server, Oracle, …). Quoting and comment syntax differ, so the result changes.

  3. When formatting, set keyword case, indent width and comma position (end or start of line). When minifying, choose whether to drop comments or keep them as /* */.

  4. Analysis lists the statement count, the kind of each statement, the tables it appears to reference (estimated) and warnings about dangerous statements.

  5. Converters turn a newline-separated list into an IN clause, or a CSV / TSV with a header row into INSERT statements. Copy or download the result.

What it does

Formatting for 12 dialects

Standard SQL, MySQL, MariaDB, PostgreSQL, SQL Server (T-SQL), Oracle (PL/SQL), SQLite, BigQuery, Redshift, Snowflake, DuckDB and Trino. Choose keyword case, 2/4-space or tab indentation, comma position and line width.

One-line output that stays valid

String literals, quoted identifiers, PostgreSQL dollar quoting and Oracle q'[...]' are never touched. When comments are kept, -- and # comments are rewritten as /* */ so nothing after them gets commented out. Optimizer hints (/*+ */) and MySQL conditional comments (/*! */) are always preserved.

Analysis with danger warnings

Lists statement count and kinds (SELECT, INSERT, CREATE TABLE, …), referenced tables and comment count. UPDATE/DELETE without WHERE, DROP and TRUNCATE are flagged with the statement number and line.

Errors with a position

Unclosed strings, quotes and comments, and places the parser cannot read, are reported with line and column and a marked excerpt. “Go to error” selects the spot in the editor and your SQL is never cleared.

Dialect-aware IN lists and INSERTs

Value lists are detected as numbers or strings (IDs such as 007 stay strings). Single quotes are doubled, backslashes are escaped for MySQL / MariaDB / BigQuery, and SQL Server gets an N prefix for non-ASCII text. INSERT identifiers are quoted with ` ` / [ ] / " " to match the dialect.

Unicode-safe

Japanese and other non-ASCII identifiers, comments and strings pass through unchanged. Shift_JIS .sql and .csv files can be opened too.

Use cases

  • Make a one-line query from a log or ORM output readable for review
  • Squeeze SQL into one line to embed it in a config file or code
  • Check a script for UPDATE/DELETE without WHERE or stray DROP statements before running it
  • Turn a column of IDs from Excel or CSV into a WHERE ... IN (...) clause
  • Convert CSV data into INSERT statements for test fixtures

Supported formats

Input

SQL (pasted text).sql.txt.csv.tsvUTF-8 / UTF-16 (BOM) / Shift_JIS

Output

Formatted SQLOne-line SQLAnalysis (on screen)IN clauseINSERT statements.sql download

Capability matrix

FeatureSupportNotes
Formatting for 12 dialects (case, indent, comma position)Supported—
One-line minify that protects strings, quoted identifiers and commentsSupported-- comments are converted to /* */ when kept
Statement count, kinds and warnings (UPDATE/DELETE without WHERE, DROP, TRUNCATE)Supported—
Referenced table extractionPartialEstimated from tokens; dynamic SQL and complex syntax can be missed or misread
List → IN clause, CSV/TSV → INSERTSupported—
Splitting statements inside stored programsPartialApproximated by matching BEGIN … END. Warnings (UPDATE/DELETE without WHERE, DROP) are scanned inside BEGIN … END, IF branches, $$ bodies, EXPLAIN and WITH, but table names are not extracted from $$ bodies
Running SQL / connecting to a databaseNot supportedYour input never leaves the browser
Full syntax validationNot supportedUnreadable spots are reported, but whether a database accepts the SQL is not checked
Automatic translation between dialects (e.g. MySQL to PostgreSQL)Not supportedThe dialect only switches formatting and quoting rules
Offline useSupportedWorks without a connection once loaded

Limits & notes

  • Input is limited to 2 million characters. Above 200,000 characters auto-run pauses and you press “Run”.
  • CSV → INSERT accepts up to 200,000 rows and 500 columns; list → IN accepts up to 500,000 values.
  • Oracle allows only 1,000 items in an IN list, so longer lists get a warning. Multi-row INSERT is capped at 1,000 rows per statement for SQL Server, and Oracle batches use the INSERT ALL form.
  • Table names and statement kinds are estimates. Stored procedures, dynamic SQL and dialect-specific syntax may be read incorrectly.
  • Formatting is done by sql-formatter (MIT), so some newer dialect-specific syntax is unsupported; it is then reported as a syntax error with its position.
  • Line breaks inside string literals are preserved even in one-line output.

Privacy & safety

The SQL, lists and CSV you enter, and any files you open, are processed only inside your browser. Nothing is uploaded or stored, so queries with production table names or customer data are safe to format. Closing the page clears everything.

FAQ

What happens to -- comments when I minify SQL to one line?
“Remove” drops them. “Keep” rewrites them as /* comment */. Leaving a -- comment on a single line would comment out everything after it, so they are never kept as-is.
Can formatting change the contents of my strings?
No. Single-quoted strings, identifiers in double quotes, backticks or [ ], and comment text are left exactly as written. Tests check that format → minify → format gives the same result.
How are UPDATE or DELETE without WHERE detected?
The tool looks for a top-level WHERE in the statement; a WHERE inside a subquery does not count. DROP and TRUNCATE are flagged the same way. It does not fully parse SQL, so misses and false alarms are possible — use it as an aid, not a final safety check.
Are values like 007 turned into numbers in the IN list?
In auto mode they stay quoted strings, which protects leading zeros in IDs and postal codes. Choose “Numbers” as the value type if you want everything unquoted.
Is my data sent to a server?
No. Formatting, analysis and conversion all run in your browser (in a Web Worker); nothing is sent to LIBRA Works or any third party.
Why does SQL Server output add N before Japanese strings?
In T-SQL a literal without the N prefix can lose non-ASCII characters (they turn into ?) depending on the column collation. For the SQL Server dialect only, strings containing non-ASCII text get N'...'.

Last updated: