Data & Formats

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.

  • Multiple dialects covered, including MySQL, PostgreSQL, SQLite, BigQuery, Snowflake, Redshift, Oracle, SQL Server, Spark, and Trino
  • Keyword, function, and data type case can be set to preserve, upper, or lower
  • 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, matching team style guides
  • One-click copy for the formatted output or a minified single line for ORMs, logs, and shell commands
  • Upload .sql files and download formatted output for migrations or data export workflows
  • Parse errors include line and column so you can locate missing brackets or unsupported syntax
  • Local-only processing — queries, table names, schemas, and sample values never leave the browser
tools/SQL Formatter
Waiting for input
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, dense operators, and a single-line minified mode. It fits query debugging, SQL review, migration cleanup, and ORM parameter inspection.

  1. 01

    Multi-dialect formatting

    Built-in dialects include MySQL, PostgreSQL, SQLite, MariaDB, TiDB, BigQuery, Snowflake, Redshift, Oracle PL/SQL, SQL Server (Transact-SQL), Spark, Trino, Hive, ClickHouse, DuckDB, Couchbase N1QL, and IBM Db2.

  2. 02

    Keyword case

    Keywords plus common function names and data types can be set to preserve, upper, or lower to match team conventions.

  3. 03

    Indent and statement spacing

    Switch between two spaces, four spaces, or tabs and control blank lines between 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

    Minified single line

    Copy minified collapses multi-line SQL into a single line, ideal for ORM calls, log fields, command-line invocations, and tools that only accept single-line queries.

  6. 06

    Error positioning

    When sql-formatter fails to parse, the status badge reports the line and column with a message so you can find missing brackets, stray tokens, or syntax the chosen dialect does not recognize.

  7. 07

    Blank lines between queries

    Control how many blank lines separate multiple statements to keep migrations, seed scripts, and test fixtures compact or visually segmented.

  8. 08

    File upload and download

    Read local .sql or .txt files and download the formatted result as .sql so the workflow fits with migration tooling and version control.

  9. 09

    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 upload a local .sql 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 and the tool will keep reformatting with 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.

  • Powered by sql-formatter with sixteen-plus dialects, each respecting its own keyword set.
  • 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 for code, logs, and CLIs.
  • Blank lines between statements keep migrations and seed scripts tidy.
  • Upload .sql files and reformat instantly; parse errors show the line and column to fix.
  • Download the formatted output as .sql for version control or database tooling.
  • 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 payload from 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, but review the result when string literals depend on repeated whitespace.
  • 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.

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?

MySQL, PostgreSQL, SQLite, MariaDB, TiDB, BigQuery, Snowflake, Redshift, Oracle PL/SQL, SQL Server (Transact-SQL), Spark, Trino, Hive, ClickHouse, DuckDB, Couchbase N1QL, IBM Db2, and a generic SQL — sixteen-plus options.

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 keyword case to upper or lower in the options panel, then format again to see the change.

Will it modify my string literals?

Formatted output only adjusts whitespace, line breaks, and keyword case; it does not intentionally rewrite quoted strings, comments, or parameter placeholders. Minified output compresses whitespace further, so review it first when string literals depend on repeated spaces.

What does minified mode do?

Copy minified collapses multi-line SQL into a single line and drops extra whitespace. It is useful for common ORM calls, log fields, command lines, and tools that only take a single-line query; use formatted output or review the result first when string literals depend on repeated spaces.

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 work fine. Very large migration files (tens of MB or huge bulk INSERTs) can slow the browser; split them first or process in batches.

Related tools

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