We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Format and beautify messy SQL code to improve readability.
SQL minification preserves quoted text, executable comments, hints, and significant line breaks. MySQL/MariaDB uses default backslash escaping; check statements that use a nondefault SQL_MODE.
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
A formatter reorganizes a query so its clauses and nested expressions are easier to scan. This page can reflow line breaks and indentation and adjust recognized SQL keyword casing. Its job is presentation: the output remains SQL text with a different layout and recognized keyword casing.
Choose Standard SQL, MySQL, PostgreSQL, MariaDB, or SQLite to give the formatter a closer syntax context. Dialects differ in quoting and extensions: MySQL commonly uses backticks for quoted identifiers, while PostgreSQL uses double quotes and folds unquoted names to lowercase. The chosen dialect affects how tokens are recognized and where the formatter can sensibly break lines. The official PostgreSQL lexical rules and MySQL identifier rules describe examples of those differences.
Set indentation to 2, 4, or 8 spaces, or choose tabs. Keyword case can be Upper, Lower, or Preserve; this preference applies to recognized keywords rather than every character in the query. Names, quoted text, and string values are not a request to globally change case. With the defaults, a compact select id,name from users where active=1 becomes a multi-line statement with uppercase keywords and two-space nested indentation.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Select the dialect used by the application or database that will receive the SQL. If the statement uses vendor-specific functions, casts, quoted names, or procedural syntax, this choice matters.
Use a complete query when possible. The result updates as input and options change; an empty input produces no formatted statement. You can load the built-in example to see the layout controls.
Choose 2, 4, or 8 spaces or tabs, then select keyword casing. Keep one consistent combination when preparing code for a shared review.
Check joins, predicates, literals, comments, and quoted identifiers against the original. Copy the output or download it as formatted.sql only after the comparison.
For example, formatting SELECT id,name FROM users WHERE active=1 ORDER BY name; separates the SELECT list, FROM, WHERE, and ORDER BY clauses onto clearer lines. That visual separation helps a reviewer spot a condition or join; it does not establish that the condition is correct or that the database accepts the statement.
Use cases
See how the tool fits into real work and everyday tasks.
Reformat a long query before sharing it so teammates can follow selected fields, joins, and filters without changing the team’s underlying review checklist.
Break a dense log statement into clauses, then compare the readable text with the originating code before editing or rerunning it.
Use before-and-after text to show how SELECT, JOIN, WHERE, and sorting clauses relate. Learners should still test syntax in the database dialect they are studying.
Notes
Review scope, result limitations, and important precautions before use.
A readable query can still be invalid or dangerous. Verify the formatted text against the original and test it in the target database before relying on it.
Related
Discover related tools, collections, and available API capabilities.