Light
Data Converters JSON ↔ CSV Converter JSON ↔ YAML Converter XML ↔ JSON Converter JSON to TypeScript JSON Diff CSV to SQL Generator Image to Base64
Text & Encoding JSON Formatter & Validator Base64 Encoder & Decoder URL Encoder & Decoder Markdown ↔ HTML Case Converter Diff Checker SQL Formatter ✓
Dev Utilities Timestamp Converter UUID Generator Hash Generator Password Generator JWT Decoder Regex Tester Cron Expression Generator Number Base Converter LLM Token Counter
Design Color Converter

SQL Formatter – Beautify, Indent and Minify SQL Queries | TrenTyx

trentyx@local:~/text-encoding/sql-formatter $ run sql-formatter_

Paste an unreadable one-line query and get it back indented by clause, with joins, subqueries and CASE expressions laid out so you can follow the logic. Keyword case is normalised, string literals and comments are preserved exactly, and dialect quoting for MySQL backticks, T-SQL brackets and PostgreSQL dollar quotes is understood. Everything runs in your browser — no query ever leaves the page.

Paste SQL below. Formatting runs as you type and never rewrites string literals.
0
statements
0
output lines
0
keywords
0
longest line
query.sql empty
formatted.sql waiting 

        

          keyword
          'string'
          123
          -- comment
          :param
        

        

          
          
        

      

    

  


  


  
  

    
Why Formatting SQL by Hand Wastes Review Time

    
Generated SQL arrives as one enormous line. ORM logs, BI exports and query builders all emit the shortest possible string, because machines do not need indentation. Humans reviewing that string do: a five-table join with two subqueries and a CASE expression is nearly impossible to reason about until the clauses are stacked vertically. Reformatting by hand takes minutes each time and introduces the risk of accidentally editing the query while you tidy it.

    
This formatter treats SQL as tokens rather than text. It reads string literals, quoted identifiers, comments, numbers and bind parameters first, then lays out only the structural pieces. That distinction matters: a SELECT appearing inside 'a string with select in it' is never touched, and neither is a column called "order". The output is the same query, re-indented — not a rewritten one.


    
What Gets Its Own Line

    
Major clauses start at the left margin: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, INSERT INTO, VALUES, UPDATE, SET, DELETE FROM, RETURNING and the set operators UNION, INTERSECT and EXCEPT. Every join variant — LEFT OUTER JOIN, INNER JOIN, CROSS JOIN — gets its own line with the matching ON condition indented beneath it, so join order is readable at a glance. Subqueries in parentheses become indented blocks, and CASE expressions put each WHEN and the ELSE on separate lines.


    
Dialect Differences That Actually Affect Parsing

    
Choosing a dialect changes how identifiers and comments are read, not just cosmetics. MySQL quotes identifiers with backticks and accepts # as a line comment; SQL Server uses square brackets; PostgreSQL supports dollar-quoted strings such as $$body$$ that can contain anything, including quotes and semicolons. Pick the wrong dialect and a formatter can mistake part of a string for code. Standard SQL mode accepts double-quoted identifiers only, which is the safest choice for portable queries.


    
Minify Mode and When to Use It

    
Minify collapses the query onto one line per statement and strips comments, which is what you want when embedding SQL in a config file, a URL, a shell command or a single-line log entry. It is not an optimisation — the query plan is identical, only the whitespace changes. Keep the formatted version in version control and minify only at the point of embedding, otherwise the next reviewer inherits the same unreadable string you started with.


    
Common Use Cases

    
    
      
  • Reviewing ORM output. Paste the query from a Rails, Django, Hibernate or Prisma log to see what was actually sent to the database.
    • 
      
  • Cleaning up inherited reports. Legacy BI queries often carry a decade of ad-hoc edits with inconsistent indentation.
    • 
      
  • Preparing SQL for a pull request. Consistent casing and indentation make diffs meaningful instead of noise.
    • 
      
  • Debugging a failing statement. Unbalanced parentheses and unterminated strings are reported instead of silently mangled.
    • 
      
  • Embedding queries in code. Minify for a single-line string, or format for a heredoc block.
    • 
    


    
Frequently Asked Questions

    

      Does the formatter validate my SQL?
      
Only structurally. It reports unterminated string literals, unterminated block comments and unbalanced parentheses, because those break tokenising. It does not check table names, column names, types or syntax against a database, so a query can format cleanly and still fail to execute.

    

    

      Will it change my query's behaviour?
      
No. Only whitespace, line breaks and the case of recognised keywords change. String literals, quoted identifiers, comments, numbers and bind parameters such as ?, $1, :name and @name are copied through byte for byte.

    

    

      Is formatting stable if I run it twice?
      
Yes. Formatting already-formatted output produces exactly the same text, which is what makes it safe to run in a pre-commit hook or paste back over the original with the Replace Input button.

    

    

      Should I use leading or trailing commas?
      
Trailing commas are the common default. Leading commas put the separator at the start of each line, which makes adding or removing a column a one-line diff and makes a missing comma easy to spot. It is a team convention rather than a correctness question — both parse identically.

    

    

      Is my query sent to a server?
      
No. Tokenising and formatting happen entirely in JavaScript in your browser, so production queries, table names and any literal values in them never leave your machine. The page also works offline once loaded.

    


    
Related Tools