Data

SQL Formatter

Paste a SQL statement and DevKitLab re-indents it for the dialect you pick, aligns clauses, normalizes keyword, function, and data type casing, and surfaces parse errors with line and column. It covers MySQL, PostgreSQL, SQLite, BigQuery, Snowflake, Redshift, Oracle PL/SQL, SQL Server, and a dozen more dialects. Toggle indent width, logical-operator newline, blank lines between statements, dense operators, semicolon placement, or copy a one-line minified version for ORMs, logs, and CLIs. Everything runs in your browser — no SQL leaves your device.

Loading the SQL engine
8%
The dialect tables are a one-time download and are cached for the rest of your visit.
SQL commands

Overview

This SQL tool reformats statements for the dialect you select, handling clause indentation, keyword case, logical-operator newline, blank lines between statements, operator spacing, and a single-line minified mode. It fits query debugging, SQL review, migration cleanup, and ORM parameter inspection.

  1. 01

    Multi-dialect formatting

    Twenty dialects are built in: MySQL, MariaDB, TiDB, SingleStore, PostgreSQL, Redshift, SQLite, DuckDB, BigQuery, Snowflake, Oracle PL/SQL, SQL Server (Transact-SQL), Spark, Trino, Hive, ClickHouse, Couchbase N1QL, IBM Db2, IBM Db2 for i, and generic standard SQL.

  2. 02

    Keyword, function, and data type case

    Keywords plus common function names and data types can be set to preserve, upper, or lower to match team conventions. Table and column names are left exactly as written, because some databases treat their casing as meaningful.

  3. 03

    Indent width and statement spacing

    Switch between two spaces, four spaces, or tabs, and choose how many blank lines separate statements. Migration scripts, seed scripts, and test fixtures can stay compact or visually separated.

  4. 04

    Logical operator newline

    Choose whether AND and OR appear at the start of the next line or stay at the end of the previous one, mirroring whichever style your team prefers.

  5. 05

    Operator spacing and semicolon placement

    Dense operators drop the spaces around arithmetic and comparison operators, and semicolons can sit on a line of their own so each statement ends on an obvious boundary. One space always stays between a minus and a negative value, because the pair would otherwise read as the start of a comment.

  6. 06

    Minified single line

    Copy minified collapses the statement onto one line for ORM calls, log fields, and command-line invocations. String literals and quoted identifiers are copied byte for byte, and a line comment is rewritten as a block comment so it cannot swallow the rest of the query.

  7. 07

    Error positioning

    When parsing fails, the status badge reports the line and column with a message, and clicking it jumps the cursor there so you can find a missing bracket, a stray token, or syntax the chosen dialect does not recognize.

  8. 08

    File upload and download

    Drop a .sql or .txt file onto the editor or pick one with Upload file, and download whatever the editor currently holds as .sql, so the workflow fits with migration tooling and version control.

  9. 09

    Settings that survive a reload

    The dialect, casing, indentation, and display options you pick are kept in this browser, along with the statement in the editor, so returning to the page does not mean setting everything up again.

  10. 10

    Local-only processing

    Parsing, formatting, minifying, file upload, and download all run in the browser tab. Your queries, schemas, table names, and sample values never reach a server.

How to use

A typical flow: pick the dialect, paste the SQL, adjust casing, indentation, and newline options, then copy the formatted or minified version.

  1. 01

    Pick the target dialect at the bottom, for example MySQL, PostgreSQL, SQLite, or BigQuery. Dialect only affects keyword recognition, not semantics.

  2. 02

    Paste your SELECT, JOIN, UPDATE, INSERT, migration, or ORM-generated SQL into the editor. You can also drop a local .sql file onto it or pick one with Upload file.

  3. 03

    Adjust keyword case, indent width, blank lines, dense operators, and semicolon placement so the output matches your team convention.

  4. 04

    If your team prefers leading AND / OR, switch the logical operator newline to break before; otherwise keep break after.

  5. 05

    Inspect the formatted output in the editor. If parsing fails, read the line and column in the status badge and fix the original SQL.

  6. 06

    Copy minified when you need a compact form, copy formatted when you need readability, or click download to save a .sql file.

  7. 07

    To iterate further, edit the SQL directly in the editor. The status badge follows along, and Format, or Shift+Alt+F, re-applies the current options.

Details

These features cover the most common SQL formatting needs: inconsistent style, dialect keyword differences, parse-error positioning, the need for both compact and readable forms, and safe handling of production SQL.

  • Twenty dialects, each formatted against its own keyword set, from MySQL and PostgreSQL to BigQuery, Snowflake, Trino, and IBM Db2.
  • Keyword, function, and data type case can be adjusted while table and column names stay as written.
  • Indent width supports two spaces, four spaces, or tabs, with controls for blank lines, dense operators, and semicolon placement.
  • Logical operators like AND and OR can break before or after to match team style.
  • Copy formatted output for review, or copy a single-line minified version that leaves string literals and comments intact.
  • Blank lines between statements keep migrations and seed scripts tidy.
  • Drop a .sql file onto the editor or upload it to reformat instantly; parse errors show the line and column to fix.
  • Download whatever the editor holds as .sql, formatted or minified, for version control or database tooling.
  • The dialect and formatting options you pick are remembered in this browser between visits.
  • All processing stays in the browser — queries, schemas, table names, and sample values are never uploaded.

Use cases

This page fits any moment you need SQL to be more readable, more consistent, easier to review, or ready to paste into another system.

  1. Query debugging

    Drop in a single-line SQL printed by an ORM or pulled from a log and expand it so you can walk through JOINs, subqueries, and WHERE clauses.

  2. SQL review

    Clean up SQL snippets in pull requests so keyword case, indent width, and line breaks match the team style and reviewers can focus on logic.

  3. Migration and seed scripts

    Reformat DDL and DML inside Flyway, Liquibase, Knex, Prisma, or SQLAlchemy Alembic migrations and keep blank lines between statements where helpful.

  4. BI and reporting queries

    Tidy report SQL from Metabase, Superset, Looker, or Redash so the layered SELECT, GROUP BY, and ORDER BY clauses read at a glance.

  5. Stored procedures and scripts

    Reshape statement bodies inside PL/SQL, T-SQL, or PostgreSQL function definitions before committing to a repo or pasting into documentation.

  6. Interview prep and teaching

    Prepare SQL exercises, answers, and slides in a consistent style so example queries look polished in articles, course notes, and READMEs.

  7. AI copilot output cleanup

    Reformat long SQL generated by AI assistants to lock in stable indentation, casing, and keyword placement before testing in a real query editor.

  8. Extracting SQL from logs

    Single-line SQL pulled from application or slow-query logs becomes readable here, so you can decide whether to tune indexes or rewrite joins.

See also

If your workflow involves a JSON column returned by SQL or a JSON body copied out of a log, you can hand it to JSON Formatter for structure, error positioning, and JSON Path copying. When exporting query results into rows and columns, switch to CSV Tools for CSV / TSV preview, editing, and conversion. If the SQL itself is wrapped in log prefixes or repeated boilerplate, run Text Replace first to strip the outer text, then come back here to reformat.

A few reminders about SQL formatting

Formatting only changes readability, not semantics. The points below are the ones most often misunderstood across dialects and teams.

  1. Formatting preserves semantics

    The tool only adjusts whitespace, line breaks, indentation, and keyword case. Table names, identifiers, operators, and arguments stay the same, and the query should behave identically before and after.

  2. Dialect only changes keyword recognition

    Choosing PostgreSQL over MySQL affects which words count as keywords and how quoting and identifiers are handled. It does not translate MySQL syntax into PostgreSQL syntax.

  3. Keyword case is convention, not a requirement

    Most databases ignore keyword case, but teams usually agree on a style. Uppercase keywords help distinguish them from identifiers in dense code.

  4. Be careful with identifier case

    Some databases treat quoted identifiers as case-sensitive (PostgreSQL is a notable example). Confirm target database behavior before manually changing table or column name casing.

  5. Not a SQL parser or linter

    This tool formats based on lexical tokens; it does not check whether tables exist, types match, or queries are efficient. Use a database, ORM, or dedicated SQL linter for that.

  6. No execution, no connection

    The page only reformats text. It never connects to a database or sends a query, so even DROP or DELETE statements are treated as plain text.

Best practices

The longer the SQL and the deeper the CTEs and subqueries, the more a stable format helps. These habits cut review noise and misunderstandings.

  • Agree on a dialect, keyword case, and indent style for the team so format does not become a recurring review topic.
  • Use stable indentation to expose complex SELECT nesting; keep fewer blank lines for simple migration scripts.
  • Stored procedures, long CTEs, and deeply nested subqueries usually read better at four spaces.
  • When debugging an ORM, expand the SQL first, then decide whether you need a new index, a different JOIN order, or a rewritten subquery.
  • Use minified output when embedding SQL in code, logs, or CLIs instead of stripping newlines by hand, which is where whitespace inside string literals usually gets lost.
  • Keep blank lines between statements in migrations so each DDL or DML stands apart during review.
  • Sanitize production SQL before pasting. The tool stays local, but the output you copy can land in tickets, chats, docs, or screenshots.

Limitations

This tool handles SQL layout, indentation, and keyword style. It does not replace query parsers, SQL linters, migration runners, or execution engines.

  • It does not check whether tables, columns, types, or permissions exist; the database, DBA tooling, or ORM still owns that.
  • It does not rewrite queries. Reordering JOINs, merging subqueries, adding indexes, or translating dialect syntax is work for database experts or refactor tools.
  • It is not a SQL linter. Style rules, naming conventions, and anti-pattern detection belong to tools like sqlfluff, SonarQube, or pgFormatter.
  • It does not connect to any database. Even DROP or DELETE statements are formatted as plain text.
  • It does not auto-translate dialect differences between MySQL and PostgreSQL, such as function names, quoting, or LIMIT / OFFSET syntax — dialect only changes how keywords are recognized during formatting.
  • Processing stays local, but local security still depends on your device, browser extensions, screen sharing, and copy destinations.
  • The editor content is kept in this browser so a reload restores it. On a shared or public machine, use Clear when you are done.

FAQ

Common questions about dialects, casing, indentation, minification, error positioning, and privacy.

Does my SQL get uploaded to a server?

No. Parsing, formatting, minifying, file upload, copy, and download all run inside the browser tab. DevKitLab never sends your queries or schemas to a server.

Which dialects are supported?

Twenty in total: MySQL, MariaDB, TiDB, SingleStore, PostgreSQL, Redshift, SQLite, DuckDB, BigQuery, Snowflake, Oracle PL/SQL, SQL Server (Transact-SQL), Spark, Trino, Hive, ClickHouse, Couchbase N1QL, IBM Db2, IBM Db2 for i, and generic standard SQL.

What if I pick the wrong dialect?

Dialect mainly affects which tokens are treated as keywords and how quoting works. Usually it stays readable, but some dialect-specific syntax (BigQuery backticks, PostgreSQL dollar-quoted strings) may format poorly under the wrong choice — match the dialect to the real database.

Why are my keywords not uppercased automatically?

The default case strategy is preserve. Switch Keywords to upper or lower in the option row and the editor re-formats right away, so you can flip back and forth without losing the original text.

Will it modify my string literals?

No. Both formatted and minified output only touch the whitespace between tokens and the case of keywords, functions, and data types. Quoted strings, quoted identifiers, and parameter placeholders are copied through unchanged, including any spacing inside them. Comments are kept as well; the only rewrite is that minified output turns a line comment into a block comment so it cannot swallow the rest of the query.

What does minified mode do?

It collapses the statement onto one line and drops the whitespace between tokens, which suits ORM calls, log fields, command lines, and tools that only take a single-line query. Quoted text is never touched, and a line comment becomes a block comment so the rest of the query stays outside it. A literal that genuinely contains a newline keeps it, so such a query still spans more than one line.

Does a parse failure mean my SQL is broken?

It usually means the formatter saw a token it does not recognize — wrong dialect, an unclosed bracket, or an unusual extension. It is not the same as a database execution error; try a different dialect or fix the syntax.

Can it handle PL/SQL or T-SQL stored procedures?

Common PL/SQL and T-SQL statement bodies work, but sql-formatter does not fully support stored procedure semantics. Complex procedures are better handled by the database vendor IDE or specialized tools.

Can I execute the SQL or connect to a database here?

No. The page only formats SQL text. It never connects to a database and never sends or runs queries.

Can it handle very large SQL files?

Scripts in the hundreds of KB to a few MB are fine. File upload stops at 5 MB, because reading and formatting more than that locks the tab for a long time, and even under the cap a few MB of bulk INSERTs will feel slow. Split large migrations into smaller scripts first.

Related tools

Continue the data workflow inside DevKitLab: clean up JSON returned by SQL, inspect tabular exports, or jump to a related text tool.