- Does it run on the server?
- No. Everything happens in your browser. The SQL you paste never travels over the wire, isn't logged, and isn't stored. Useful when you're formatting a query with real data, internal table names, or credentials in a comment.
- Which dialects are supported?
- Standard SQL, PostgreSQL, MySQL, SQLite, and SQL Server. The formatter recognizes each dialect's identifier-quoting style — double quotes for standard/Postgres, backticks for MySQL, square brackets for SQL Server — and passes them through verbatim. Keywords are the common superset, so dialect-specific keywords like ILIKE (Postgres) or AUTO_INCREMENT (MySQL) format correctly.
- Will it change values inside string literals?
- No. Anything inside single quotes is passed through unchanged — case, whitespace, the lot. If you write WHERE name = 'select FROM where', the literal stays exactly as written even though those look like keywords. Same for comments: -- and /* */ blocks are preserved verbatim on their own line.
- How does the keyword-case option work?
- UPPER turns every recognized keyword into uppercase (SELECT, FROM, INNER JOIN). lower does the opposite. Title capitalizes the first letter of each word (Select, From, Inner Join). Identifiers — your table names, column names, aliases — are never re-cased. We only touch words we know are keywords.
- What's the difference between spaces and tabs?
- Spaces: every indent level is N spaces (you pick N, default 2). Tabs: every indent level is one tab character. Tabs are smaller in the output but render at whatever width your editor is set to — handy if you're pasting into a code review tool that respects tab settings. The width selector is disabled when you pick tabs.
- Does it validate the SQL?
- No — it's a formatter, not a parser. If you paste broken SQL (missing parenthesis, dangling comma, typo in a keyword), it still formats — it just won't run when you paste it back into your database. We don't try to be a linter; that's a different job.
- How does it handle subqueries?
- Subqueries — anything inside parentheses that isn't a function call — get their own indented block. The opening paren stays on the outer line, the closing paren goes on its own line aligned with the outer level, and the inner clauses indent. Function-call parens like count(*) or coalesce(a, b) stay compact on the same line — no break inside the args.
- Why does my formatted query look different from another formatter's output?
- Every formatter makes opinionated choices: leading commas vs trailing commas, where to break AND/OR, how deep to indent JOIN ON, when to break VALUES tuples. This one uses trailing commas, breaks each clause and each JOIN/ON/AND/OR onto its own line, and keeps VALUES rows on one line each. Some teams prefer a different shape — there's no SQL formatting standard.
- Can I format an entire .sql file with many queries?
- Yes — paste the whole thing. Semicolons break statements onto separate lines and the formatter resets indent at each one. The file stays in one block; if you want them separated, pasting one at a time is currently the cleanest path.
- Does it handle MySQL backticks and SQL Server brackets?
- Yes. Backtick-quoted identifiers like `my-col` and bracketed identifiers like [my col] are recognized and passed through unchanged — the formatter won't try to re-quote them or break them apart. Same for standard double-quoted identifiers "My Column".
