SQL Formatter — How to Format and Beautify SQL Queries Online

SQL queries start clean but inevitably become unreadable. A simple SELECT grows into a 50-line join with subqueries, CASE expressions, and window functions — all crammed into a single line by an ORM, copied from a log file, or pasted from a Stack Overflow answer with no formatting. Reading and debugging unformatted SQL is like reading a paragraph with no punctuation — technically possible but painfully slow.

This guide covers what SQL formatting does, how to apply it consistently, how to format SQL programmatically, and the conventions that make queries readable.

What Is SQL Formatting?

SQL formatting takes a compact or messy query and adds consistent indentation, line breaks, and keyword casing to make it human-readable. Each major clause (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY) starts on its own line. Subqueries are indented. Keywords are uppercased. Column lists are aligned. The result is a query you can read, debug, and review in seconds.

You would use SQL formatting when debugging queries from application logs (usually minified), reviewing database migrations, writing documentation with SQL examples, standardizing team codestyle, and preparing queries for code review.

How to Format SQL with FlipMyCase

1. Open the FlipMyCase SQL Formatter.
2. Paste your unformatted SQL query.
3. The tool instantly formats it with proper indentation, keyword casing, and line breaks.
4. Copy the formatted query for use in your editor, documentation, or code.

The formatter handles SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, ALTER TABLE, CTEs, and complex nested queries. For comparing two versions of a query, use the Text Diff tool.

Code Examples for SQL Formatting

JavaScript (with sql-formatter library)

// Using the sql-formatter npm package
const { format } = require('sql-formatter');

const ugly = "SELECT u.id,u.name,u.email,o.total FROM users u INNER JOIN orders o ON u.id=o.user_id WHERE o.created_at>'2024-01-01' AND u.active=true ORDER BY o.total DESC LIMIT 10";

const formatted = format(ugly, {
  language: 'postgresql',
  keywordCase: 'upper',
  indentStyle: 'standard',
  tabWidth: 2,
});

console.log(formatted);
// SELECT
//   u.id,
//   u.name,
//   u.email,
//   o.total
// FROM
//   users u
//   INNER JOIN orders o ON u.id = o.user_id
// WHERE
//   o.created_at > '2024-01-01'
//   AND u.active = true
// ORDER BY
//   o.total DESC
// LIMIT
//   10

Python (with sqlparse)

import sqlparse

ugly = """SELECT u.id,u.name,u.email,o.total FROM users u
INNER JOIN orders o ON u.id=o.user_id WHERE o.created_at>'2024-01-01'
AND u.active=true ORDER BY o.total DESC LIMIT 10"""

formatted = sqlparse.format(
    ugly,
    reindent=True,
    keyword_case='upper',
    indent_width=2,
    strip_comments=False,
)
print(formatted)
# SELECT u.id,
#        u.name,
#        u.email,
#        o.total
# FROM users u
# INNER JOIN orders o ON u.id=o.user_id
# WHERE o.created_at>'2024-01-01'
#   AND u.active=true
# ORDER BY o.total DESC
# LIMIT 10

# Parse and analyze SQL
parsed = sqlparse.parse("SELECT id FROM users WHERE active = true")[0]
for token in parsed.tokens:
    if not token.is_whitespace:
        print(f'{token.ttype}: {token}')

Go (manual formatting approach)

package main

import (
    "fmt"
    "regexp"
    "strings"
)

func formatSQL(sql string) string {
    keywords := []string{
        "SELECT", "FROM", "WHERE", "AND", "OR",
        "INNER JOIN", "LEFT JOIN", "RIGHT JOIN",
        "ORDER BY", "GROUP BY", "HAVING", "LIMIT",
        "INSERT INTO", "VALUES", "UPDATE", "SET",
        "DELETE FROM", "CREATE TABLE", "ALTER TABLE",
    }

    result := strings.TrimSpace(sql)

    // Uppercase keywords
    for _, kw := range keywords {
        re := regexp.MustCompile(`(?i)\b` + strings.ReplaceAll(kw, " ", `\s+`) + `\b`)
        result = re.ReplaceAllString(result, kw)
    }

    // Add line breaks before major clauses
    for _, kw := range keywords {
        result = strings.ReplaceAll(result, " "+kw+" ", "\n"+kw+" ")
    }

    return result
}

func main() {
    sql := "select id, name from users where active = true order by name limit 10"
    fmt.Println(formatSQL(sql))
}

Real-World Use Cases

Debugging ORM-generated queries. ORMs like Django, SQLAlchemy, ActiveRecord, and Prisma generate SQL that is technically correct but completely unreadable. When a query performs poorly or returns unexpected results, extract the generated SQL, paste it into the SQL Formatter, and read it as a human-written query. This makes identifying missing JOINs, incorrect WHERE clauses, and N+1 patterns much easier.

Code review standardization. SQL in migration files and stored procedures should follow consistent formatting. A formatter ensures that every query in the codebase looks the same, regardless of who wrote it. This eliminates bikeshedding about style in code reviews and makes diffs cleaner.

Documentation and teaching. SQL examples in documentation, blog posts, and tutorials must be readable. Format all examples before publishing. Poorly formatted SQL in documentation makes your project look unprofessional.

Log analysis. Application logs often contain single-line SQL queries. When investigating slow queries or errors, format the logged SQL to understand its structure. This is especially important for complex queries with multiple joins and subqueries.

Common Mistakes and Gotchas

The biggest issue is inconsistent formatting across a team. If some developers format their SQL and others do not, diffs contain formatting noise mixed with actual changes. Adopt a formatter as part of your CI pipeline (sqlfluff for linting, sql-formatter for formatting) and run it on every commit.

Formatting does not fix bad SQL. A beautifully indented query with a missing index still runs slowly. A perfectly formatted JOIN with the wrong ON condition still returns wrong results. Use formatting as a readability tool, then review the query logic separately.

Keyword casing preferences vary. Some teams use uppercase keywords (SELECT, FROM) while others prefer lowercase. The important thing is consistency. The FlipMyCase formatter uses uppercase by default, which is the most common convention and makes keywords visually distinct from table and column names.

Comment handling varies between formatters. Some strip comments, others preserve them but may misplace them. Always check that inline comments (-- comment) and block comments (/* comment */) survive formatting correctly, especially in stored procedures.

Conclusion

SQL formatting transforms unreadable queries into structured, maintainable code. Whether you are debugging ORM output, reviewing migrations, or writing documentation, properly formatted SQL saves debugging time and reduces errors.

The FlipMyCase SQL Formatter handles everything from simple SELECTs to complex CTEs with subqueries and window functions. For programmatic formatting, use the sql-formatter npm package in JavaScript or sqlparse in Python. Compare formatted query versions with the Text Diff tool and clean up copied SQL with the Text Cleaner.