Format, minify and read SQL queries from MySQL, PostgreSQL, SQL Server, Oracle and other dialects, with per-statement splitting, a summary of what the query touches and review alerts.
SQL queries written in a hurry turn into a giant, unreadable single line that is hard to review and version. This workbench does three things with that text. First, it formats: the query is rewritten with line breaks, consistent indentation and clause alignment (SELECT, FROM, JOIN, WHERE, GROUP BY), with keyword case and identifier case configured independently and commas either trailing or leading. Second, it minifies: line breaks, indentation and comments are removed so the statement fits in a log line, a code string or a configuration file. Third, it reads: a script is split into numbered, copyable statements, and each one gets its tables, columns, joins and clauses extracted plus review alerts such as SELECT *, DELETE or UPDATE without WHERE and JOIN without a condition. Eight dialects are supported (standard SQL, MySQL, MariaDB, PostgreSQL, SQLite, BigQuery, T-SQL and PL/SQL), and literals, comments, backticks, brackets and PostgreSQL dollar-quoted blocks are preserved exactly as they were. Everything runs locally, so it is safe to work with real table and column names.
In format mode, every main clause (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) starts a line, the column list and the conditions are broken out and everything gets consistent indentation. You set keyword case and identifier case separately, indentation to 2, 4 or 8 spaces, and whether commas sit at the end of a line or at the start of the next one, a common style in teams that review SQL diffs.
In minify mode, line breaks, indentation and comments go away and the statement becomes a single line. Two deliberately conservative decisions: whitespace around operators is kept, because gluing one minus sign onto another would turn the expression into a line comment, and optimizer comments (the ones starting with /*+ or /*!) are preserved, because they instruct the database and are not decoration.
When you paste a dump or a migration with several statements, the tool splits the script only on the semicolons that really end a statement. A semicolon inside a literal, inside a comment or inside a BEGIN and END block is not a separator. Each statement appears numbered, formatted and with its own copy button.
The summary reads the structure of each statement and answers what you actually ask when you inherit a long query: which tables it touches and under which aliases, which columns the outer SELECT projects, which join types are used and whether each one has a condition, which clauses are present (WHERE, GROUP BY, HAVING, ORDER BY, LIMIT), which CTEs are declared, how many subqueries there are and which parameters the query expects.
The alerts are a static reading of the text: SELECT *, DELETE or UPDATE without WHERE, JOIN with no ON or USING, INSERT without a column list, comma-separated tables in FROM, statements that remove data or structure, and quotes or comments left open. Each one points at the statement and the evidence found.
What they are not: a performance diagnosis. Whether a query is fast or slow depends on the execution plan, the indexes, the statistics and the real size of each table, none of which is in the written text and none of which this tool can know. A SELECT * can be perfectly appropriate, and a query with no alerts at all can be slow. For real cost, run EXPLAIN (or EXPLAIN ANALYZE) on your database.
Formatting before opening a pull request, saving a migration or pasting into documentation standardizes the team's style and keeps the diff readable. Minifying helps when the query has to fit in a log line, a code string or a configuration field. The summary and the alerts mostly help when reading an inherited query, the sixty-line one nobody remembers the reason for.
About the limits: the tool only touches whitespace, breaks and case, never the logic, and it neither validates nor runs anything. If a statement cannot be parsed in the chosen dialect, it comes back exactly as it was and is flagged in the review tab, instead of being lost or rewritten on a guess. Splitting procedural blocks (BEGIN, CASE, LOOP) is heuristic: in deeply nested PL/SQL packages the numbering may not match, but no character of your text is ever discarded.
Paste the code into your HTML and the tool shows up on your page, without J-Kit's navigation and ads. It still runs in the browser of whoever visits your site.
<iframe
src="https://jkit.tools/embed/en-US/sql-formatter"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="SQL Formatter"
></iframe>These references help contextualize formulas, standards, APIs and limitations used on this page. They do not replace professional validation when a result has legal, financial, medical or operational impact.
The formatter supports standard SQL, MySQL, MariaDB, PostgreSQL, SQLite, BigQuery, SQL Server (T-SQL) and Oracle (PL/SQL). The chosen dialect also decides how the text is read: MySQL backticks, SQL Server brackets, PostgreSQL double quotes as identifiers and dollar-quoted blocks (PostgreSQL's $$) are recognized and preserved.
WITH
ativos AS (
SELECT
id,
name
FROM
users
WHERE
status = 'active'
)
SELECT
a.id,
a.name,
count(o.id) AS orders,
sum(o.total) AS revenue
FROM
ativos a
LEFT JOIN orders o ON o.user_id = a.id
WHERE
o.created_at > '2024-01-01'
GROUP BY
a.id,
a.name
HAVING
count(o.id) > 3
ORDER BY
revenue DESC
LIMIT
10;WITH
ativos AS (
SELECT
id,
name
FROM
users
WHERE
status = 'active'
)
SELECT
a.id,
a.name,
count(o.id) AS orders,
sum(o.total) AS revenue
FROM
ativos a
LEFT JOIN orders o ON o.user_id = a.id
WHERE
o.created_at > '2024-01-01'
GROUP BY
a.id,
a.name
HAVING
count(o.id) > 3
ORDER BY
revenue DESC
LIMIT
10;Everything happens in your browser. No query and no file is sent to any server.