अक्सर पूछे जाने वाले प्रश्न

No. When you press Format, your SQL is sent to our server, formatted in memory and returned in the same response. It is not written to a database, a file or a log, and it is not shared with analytics or advertising partners. Even so, treat any online tool with care: do not paste credentials, customer data or anything you are not allowed to share. The privacy page describes everything the site does record.

It is free and there is no account, sign-up or login. You open the formatter, paste your SQL and format it. The site shows ads, which are described on the privacy page.

Yes. Essential cookies remember your language, theme and cookie choice. A session identifier cookie is created only after you choose "Accept all" or "Essential only"; it has no fixed expiry date, stays the same across the pages you open, and is used only to group visits in our visit counter. Google Analytics cookies are set only if you choose "Accept all" in the cookie banner, and ads from Google AdSense are requested as non-personalized until you do. You can change your choice at any time with the "Cookie preferences" link in the footer. The details are on the privacy page.

Yes. Press Ctrl+Enter, or ⌘+Enter on a Mac, while the editor has focus. The Copy button puts the result on your clipboard and Clear empties the editor. The status bar under the editor shows the number of lines and characters and the current line and column.

Up to 20,000 lines per request. Larger input is rejected with a message instead of being cut off. For bigger scripts, split them into files of a few thousand lines, which is also easier to review.

Yes. The input is split on semicolons and each statement is formatted in order, so a migration script or a batch of queries comes back with every statement laid out the same way.

The formatter is designed to change only whitespace, line breaks and the case of keywords. String literals, quoted identifiers and comments are left as they are, and so are qualified names such as t.month. One thing to watch: a bare, unquoted word that matches a SQL keyword is re-cased, including a column name or alias such as month, which becomes MONTH with uppercase keywords. Most databases treat unquoted names case-insensitively, but if yours does not, qualify or quote those names. As with any tool that rewrites code, review the result before you run it in production.

Yes. Both -- line comments and /* */ block comments are preserved in the output, and their text is not re-cased.

There are five. Indent spaces (default 4) sets the depth of each nesting level, and tabs in the input are replaced by that many spaces, except inside string literals and quoted identifiers. Maximum columns (default 120, 0 turns it off) breaks lines that are still too long. Commas puts commas after an item (the default) or before the next one. Keywords writes keywords in uppercase (the default) or lowercase. Parentheses on new line (off by default) moves the opening parenthesis of an indented block, such as a subquery, onto its own line.

It is the most widely used convention in SQL style guides and documentation. Uppercase keywords separate the structure of a query (SELECT, FROM, WHERE) from the names of your tables and columns, which helps when you scan a long statement. Lowercase works just as well if your team prefers it; what matters is being consistent. The SQL style guide covers this and other conventions.

Maximum columns runs as a final pass after the layout is done. Any line longer than the limit is broken at the last space before it, and the continuation gets two extra spaces of indent. It does not rearrange clauses. It never breaks inside a string literal, a quoted identifier or a comment, and when the break follows a comma, the comma stays at the end of the line. If a break lands somewhere awkward, raise the limit or set it to 0 to disable wrapping.

There is no dialect switch. The layout rules work on the SQL that dialects share: SELECT, joins, subqueries, CASE, DML and DDL. PostgreSQL gets extra handling for :: casts, $1 parameters, JSON and array operators and dollar-quoted bodies. MySQL backtick names and SQL Server bracketed names such as [dbo].[orders] are kept intact and never re-cased. There is no specific handling for the GO batch separator or for BEGIN … END blocks outside PostgreSQL dollar quotes, so review those scripts with more care. See SQL dialect differences and the PostgreSQL formatting guide.

PostgreSQL functions and DO blocks with a $$ body get a PL/pgSQL layout: DECLARE, BEGIN, IF, ELSIF, LOOP, EXCEPTION and END are laid out as blocks. T-SQL and PL/SQL procedure bodies are formatted as a sequence of plain statements, without a special block layout.

Use the contact page. Include a small piece of SQL that shows the problem, the options you used and the result you expected. Remove any confidential names or values before you send it.