search

Found

info Overview

Reformat cramped SQL into a clause-per-line layout with 4-space indentation, uppercase keywords, and color highlighting across 100+ reserved words.

📘 How to Use

  1. Paste the query you want to format into the SQL input field
  2. Read the result with each clause broken onto its own indented line
  3. Scan the uppercased, color-coded keywords to grasp the structure

SQL Formatter & Beautifier

Formatted SQL will appear here
Copied

grid_view Related

Article

SQL Formatter & Beautifier | Break Cramped Queries Into Readable Clauses

Paste a one-line SQL dump from an ORM log or a minified query, and this tool splits it onto separate lines per clause — SELECT, FROM, WHERE, JOIN — with 4-space indentation. Reserved words are normalized to uppercase, and 100+ keywords, string literals, numbers, and comments are color-coded.

💡 About this tool

You open a pull request and the SQL inside is one long line. You cannot tell where the join condition ends and the filter begins. This tool draws those clause boundaries mechanically so the query becomes scannable.

Formatting runs through a tokenizer rather than a naive regex. String literals ('...' and "...") and comments (-- line comments and /* */ block comments) are pulled out as distinct tokens, so their contents are never touched — only the keywords outside them get uppercased. Compound clauses like GROUP BY, ORDER BY, and LEFT OUTER JOIN are recognized as single units and placed on their own line. When a subquery opens with SELECT inside parentheses, indentation increases one level and drops back on the closing parenthesis, so nesting depth maps directly to how far a line is indented. CASE expressions indent their WHEN / THEN / ELSE branches and align on END.

The input and output panes sit side by side, so you can compare the original against the result. Copy the output straight into a SQL client or a code-review comment.

🧐 Frequently Asked Questions

Q. Which SQL dialects does it handle? A. Beyond standard SQL, the keyword set covers MySQL backtick identifiers, PostgreSQL RETURNING / ON CONFLICT, and window-function words like OVER / PARTITION BY — over 100 reserved words shared across major dialects. Dialect-specific functions are treated as identifiers, which does not affect the layout.

Q. Will a SELECT inside a string get uppercased? A. No. Single- and double-quoted string literals and comments are isolated as separate tokens during tokenization, and their contents are left exactly as written.

Q. Can I format several statements at once? A. Yes. Statements separated by a semicolon (;) are each formatted, with a blank line inserted between them.

Q. Can I change the indentation width? A. It is fixed at 4 spaces. Adjust it afterward with your editor's find-and-replace if you need 2-space style.

Q. Could the output ever come out wrong? A. SQL built through string concatenation or sprinkled with template placeholders (such as {{ }}) departs from the grammar the tokenizer expects, so line breaks may land in unexpected places.

📚 Fun Facts

The convention of writing SQL keywords in uppercase dates back to a time when SQL was designed to be case-insensitive, and uppercasing reserved words was a practical way to set them apart from identifiers on a monochrome terminal. ANSI SQL accepts lowercase keywords just fine, yet many style guides still recommend uppercase out of habit. Identifier case, on the other hand, is handled differently per database: PostgreSQL folds unquoted identifiers to lowercase, while MySQL's behavior depends on the filesystem. A formatter that uppercases only reserved words and preserves the original casing of identifiers avoids breaking those differences.