SQL Formatter
{{ summaryHeadline }}
{{ metrics.statementCount }} statement(s) · {{ formatBytes(metrics.inputBytes) }} input · {{ formatBytes(metrics.outputBytes) }} output
{{ dialectLabel }} {{ profileLabel }} {{ indentLabel }} {{ warnings.length }} caveat(s)
Choose a review style, then adjust visible controls when the query needs a team-specific convention.
Pick the closest database syntax before formatting.
Paste one query or a multi-statement script; comments and string literals are preserved by the formatter engine.
{{ fileStatus }}
Uppercase is common for review; Preserve keeps source keyword casing where possible.
Use 2 or 4 for most database review workflows.
spaces
Leave Preserve unless your team standardizes data-type casing.
Preserve is safest for vendor-specific and user-defined functions.
Before makes scan paths clear in WHERE and HAVING clauses.
Use 1 for compact scripts or 2 for review documents.
line(s)
Lower values break long predicates sooner.
chars
Leave off unless the destination repository requires tabs.
{{ use_tabs ? 'On' : 'Off' }}
Off is easier to review; on can match compact legacy style.
{{ dense_operators ? 'On' : 'Off' }}
Off keeps the semicolon at the end of the statement line.
{{ newline_before_semicolon ? 'On' : 'Off' }} 
{{ formattedSql }}
# Statement Input Output Review note Copy
{{ row.index }} {{ row.type }} {{ row.inputLabel }} {{ row.outputLabel }} {{ row.note }}
Check Status Detail Copy
{{ row.check }} {{ row.status }} {{ row.detail }} 

          

        

      

    

  

                

                

                    

                        

                            Tags: Database, Devtools, Text
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  
  
SQL formatting turns dense query text into a layout that people can read, review, and compare without changing the query's intended meaning. Line breaks make clauses visible, indentation shows nested subqueries and joins, and consistent keyword casing helps reviewers separate SQL grammar from table names, column names, string literals, and comments.

  

    Compact SQL source flowing through dialect, case, and spacing choices into formatted review SQL.
  

  
Readable SQL matters most when a query has several joins, a long predicate, a common table expression, or a script with multiple statements. A formatter cannot prove that a query is correct, fast, or safe to run. It gives reviewers a cleaner shape so missing predicates, unbalanced parentheses, surprising statement boundaries, and vendor-specific syntax stand out sooner.

  
Dialect choice matters because SQL engines do not share every quoting rule, procedural block shape, or extension. A PostgreSQL query with casts and dollar signs, a MySQL query with backtick identifiers, a SQL Server script with bracketed identifiers, and an Oracle PL/SQL block can all be valid in their own environments while looking odd to a generic parser. Formatting is useful only when the chosen syntax is close to the database that will execute the query.






  
Technical Details:

  
SQL text is made of keywords, identifiers, literals, comments, operators, separators, and dialect-specific extensions. Formatting changes whitespace and selected casing around those tokens. It should not rewrite table names, change string values, remove comments, reorder predicates, or decide whether an index will be used.

  
Semicolons are treated as statement separators only when they appear outside quoted text and comments. That distinction matters for scripts that include strings containing punctuation, block comments, or line comments. A semicolon inside a quoted literal should remain part of the literal rather than splitting the script into two statements.

  
Comments and quoted sections also limit how much a formatter can safely change. Line comments beginning with two hyphens, block comments wrapped in slash-star markers, single-quoted strings, double-quoted identifiers, backtick identifiers, and bracketed SQL Server identifiers all carry meaning. The safest formatting pass protects those regions, then applies indentation, clause breaks, keyword casing, and statement spacing to the surrounding SQL.


  
Transformation Core

  
The formatting pass follows a token-preserving path. These are review aids, not execution guarantees.

  

    

      
      
        

          Stage
          What changes
          What should stay unchanged
        

      
      
        

          Dialect selection
          The parser uses a language setting close to the target engine.
          Database meaning still comes from the real engine, not the formatter.
        

        

          Protected text
          Comments, quoted strings, and quoted identifiers are treated as protected regions.
          Literal values, comment text, and quoted names should remain readable as entered.
        

        

          Clause breaks
          Major clauses such as SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, joins, and unions can move to separate lines.
          The order of expressions and predicates should not change.
        

        

          Case and spacing
          Recognized keywords, data types, functions, indentation, operator spacing, and semicolon placement follow the selected style.
          Unquoted identifiers should not be treated as proof of object existence or portability.
        

        

          Review audit
          Statement counts, input/output size, parser status, and caveats are summarized.
          A clean audit does not replace testing against the target database.
        

      
    

  


  
Dialect and Syntax Notes

  
Vendor syntax changes how a formatter should read identifiers and procedural text. The examples below are reference points for choosing the closest dialect before review.

  

    

      
      
        

          Syntax area
          Common pattern
          Formatting risk
        

      
      
        

          Keywords and identifiers
          Keywords such as SELECT and UPDATE have fixed SQL meaning, while identifiers name tables, columns, aliases, and other objects.
          Changing keyword case is usually cosmetic, but quoted identifier case may be meaningful.
        

        

          PostgreSQL quoting
          Double-quoted identifiers are always identifiers, and unquoted names fold according to PostgreSQL rules.
          A formatter should not remove quotes just because the text becomes easier to read.
        

        

          MySQL quoting
          Backticks quote identifiers, while ANSI_QUOTES mode can make double quotes act as identifier quotes.
          A generic SQL pass can misread vendor-specific quoting or server mode assumptions.
        

        

          SQL Server identifiers
          Delimited identifiers can use brackets, which are common in Transact-SQL scripts.
          Bracketed names should be kept intact even when line breaks change around them.
        

        

          PL/SQL blocks
          DECLARE, BEGIN, EXCEPTION, and END divide procedural blocks.
          Procedural SQL may need an engine-aware editor or database parser after formatting.
        

      
    

  


  
Review Boundaries

  
Formatting can make problems more visible, but it does not execute SQL, inspect schemas, or analyze query plans.

  

    

      
      
        

          Signal
          What it can tell you
          What to verify elsewhere
        

      
      
        

          Formatted SQL
          Whitespace, casing, indentation, and line breaks after the selected style is applied.
          Execution behavior, permissions, query plan, transaction safety, and result correctness.
        

        

          Statement Ledger
          Statement type, source length, output length, line counts, and review notes for each detected statement.
          Whether each statement belongs in the same deploy script or transaction.
        

        

          Formatter Audit
          Parser or fallback status, local processing status, dialect, profile, indentation settings, footprint, and caveats.
          Whether the database accepts the final SQL exactly as shown.
        

        

          Caveats
          Possible parser fallback, procedural SQL, very large source text, unbalanced parentheses, or missing trailing semicolons.
          The original author, migration runner, database console, or continuous integration check.
        

      
    

  






  
Everyday Use & Decision Guide:

  
For most reviews, choose Review readability, select the closest SQL dialect, paste the query into SQL source, and leave Keyword case on uppercase with a 2-space Indent width. That setup favors scanning WHERE, HAVING, JOIN, GROUP BY, and ORDER BY clauses without making the output unusually wide.

  
Use Wide indentation when the destination team expects 4-space indents or when nested common table expressions need more breathing room. Use Lowercase keywords only when that matches the repository convention. Once you change an advanced setting such as data type case, function case, logical operator line break, expression width, tabs, dense operators, or semicolon placement, the profile moves to Custom so the chosen style is visible.

  
    
    
  • Pick PostgreSQL, MySQL, SQL Server T-SQL, Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, Spark SQL, Trino / Presto, DB2, or another close option before comparing output.
    • 
    
  • Use Browse SQL or drag one SQL or text file onto the editor when a review starts from a local script file.
    • 
    
  • Check the summary headline before copying. SQL Formatted Locally is the clean path, Formatted with Caveats means review the warning list, and Best-Effort SQL Preview means the fallback formatter was used.
    • 
    
  • Open Statement Ledger when a script has several semicolon-delimited statements or when a statement note says parentheses need review.
    • 
    
  • Open Formatter Audit when a teammate needs to know which dialect, profile, indentation, input footprint, and caveats were used.
    • 
  

  
The result is for review, not execution approval. A formatted SELECT can still point at the wrong table, omit a tenant predicate, or behave differently under a vendor-specific parser. Treat caveats about stored procedures, triggers, procedural blocks, large input, parser fallback, or missing semicolons as prompts to test in the database environment that will run the SQL.

  
After the formatted output looks right, copy Formatted SQL for the review comment or download the SQL for handoff. Keep the ledger or audit export with the review when statement counts, caveats, or formatting settings need to be reproducible.






  
Step-by-Step Guide:

  
Use the controls in order so the formatted output, ledger, and audit all describe the same formatting run.

  
    
    
  1. Choose a Formatting profile. Start with Review readability unless the team convention calls for Wide indentation, Lowercase keywords, or Custom.
    2. 
    
  2. Select the closest SQL dialect. The dialect badge in the summary should match the engine family you expect to review.
    3. 
    
  3. Paste the query into SQL source, click Sample, or use Browse SQL for one SQL or text file. The source is formatted automatically after input changes.
    4. 
    
  4. Set Keyword case and Indent width. If needed, open Advanced for data type case, function case, logical operator line break, lines between statements, expression width, tabs, dense operators, and semicolon placement.
    5. 
    
  5. Read the summary, warning alert, and Formatted SQL tab. If a parser fallback warning appears, compare the preview with the source before copying it.
    6. 
    
  6. Use Statement Ledger to confirm statement count, statement type, input/output size, and review note. A note such as Parentheses need review. or No trailing semicolon detected. should be fixed or acknowledged before handoff.
    7. 
    
  7. Use Formatter Audit or JSON when the formatting settings and caveats need to travel with the review. Then copy or download the output that matches the handoff format.
    8. 
  

  
If the formatted result disappears, the source is blank. If a local file fails to load, paste the SQL text directly and run the same review path.






  
Interpreting Results:

  
Trust the final Formatted SQL as a readability output, then use Statement Ledger and Formatter Audit to decide whether the run needs extra review. The output is most dependable when the summary says SQL Formatted Locally, the caveat count is zero, the dialect is correct, and the statement count matches the source script.

  
Do not treat a clean formatter audit as proof that the query is valid for production. Formatting does not confirm table names, column names, permissions, transactions, plan quality, or data impact. Test the final SQL in the intended database before running it against real data.

  
    
    
  • Formatted with Caveats means the formatter produced output, but at least one warning deserves a manual check.
    • 
    
  • Best-Effort SQL Preview means the main parser failed and a conservative clause formatter produced a preview.
    • 
    
  • Parentheses need review. means the source statement has an unmatched or early closing parenthesis outside protected text.
    • 
    
  • No trailing semicolon detected. means the statement can still be readable, but script runners or migration tools may require a terminator.
    • 
  






  
Worked Examples:

  
Reviewing a reporting query

  
A reviewer pastes a PostgreSQL-style query that selects customers, joins a paid-orders common table expression, filters the last 90 days, groups by customer, and orders by lifetime value. With Review readability, PostgreSQL, uppercase keywords, and 2-space indentation, Formatted SQL separates WITH, SELECT, FROM, JOIN, WHERE, GROUP BY, and ORDER BY. Statement Ledger reports a WITH SELECT statement with input and output line counts, and the note should read Ready for SQL review.

  
Preparing a multi-statement migration note

  
A migration draft contains a CREATE TABLE statement, an INSERT statement, and a final UPDATE separated by semicolons. After formatting with 4-space indentation and two lines between statements, the summary statement count should be 3. Statement Ledger helps confirm that each statement was detected separately before the reviewer copies the formatted SQL into a pull request comment.

  
Checking a procedural block warning

  
A SQL Server script includes DECLARE @cutoff and BEGIN TRY. The formatter can still make the script easier to read, but the warning list may say that procedural SQL needs database-specific validation. In that case, use Formatter Audit to record the dialect and caveat, then test the formatted script in SQL Server tools before execution.

  
Recovering from a fallback preview

  
A pasted statement has an unfinished nested expression such as where (status = 'paid'. The summary can switch to Best-Effort SQL Preview, and Statement Ledger may show Parentheses need review. Fix the missing parenthesis in SQL source, then confirm the summary returns to the parser path before copying the final output.






  
FAQ:

  

    Does formatting change what my SQL does?
    
It should only change whitespace, selected keyword/data-type/function casing, indentation, operator spacing, and statement separation. Still compare the final output with the source when a caveat appears, especially for procedural SQL or unusual dialect syntax.

  

  

    Which dialect should I choose?
    
Choose the engine closest to the database that will run the query. PostgreSQL, MySQL, SQL Server T-SQL, Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, Spark SQL, Trino / Presto, DB2, and Standard SQL are available choices.

  

  

    What does parser fallback mean?
    
It means the main browser parser could not format the source, so a conservative clause formatter produced a review preview. Use the preview for readability only, then validate the final SQL in the destination database.

  

  

    Why does the ledger say a semicolon is missing?
    
The statement does not end with a semicolon after trimming whitespace. Some database consoles tolerate that, while migration scripts and batch runners may expect explicit terminators between statements.

  

  

    Where does a browsed SQL file go?
    
Browse and drag/drop read one local SQL or text file into the editor. After the page finishes loading, formatting, ledger generation, audit details, copy actions, and downloads are handled in the browser.

  






  
Glossary:

  

    
Dialect

    
The SQL variant used by a database engine, such as PostgreSQL, MySQL, SQL Server T-SQL, or Oracle PL/SQL.

    
Identifier

    
A name for a table, column, alias, schema object, or similar database object.

    
Keyword

    
A SQL word with grammar meaning, such as SELECT, UPDATE, WHERE, JOIN, or ORDER BY.

    
Statement

    
A complete SQL command or command-like block, often separated from the next one by a semicolon.

    
Parser fallback

    
A conservative formatting preview used when the primary parser cannot format the source text.

    
Procedural SQL

    
SQL mixed with procedural constructs such as variables, blocks, stored procedures, functions, or triggers.

  






  
References: