OpsecForge Hub/SQL Formatter
Local Processing • No Tool-Input Upload

PostgreSQL & MySQL Formatter
Beautify Queries Without Data Exposure

Lay out or compact SQL queries entirely in your browser: one column per line, joins and clauses on their own lines, adjustable indentation and keyword casing. It is a text formatter, not a SQL parser.

Dialect:

This tool preserves quoted strings, comments, PostgreSQL dollar-quoted bodies, and common dialect operators, but it does not parse, validate, or execute SQL. It lays out SELECT, INSERT, UPDATE and DELETE statements; other statements (for example CREATE TABLE) are mostly left on one line. Review vendor-specific syntax before running the result.

Why Local SQL Formatting Reduces Data Exposure

Production SQL can contain internal schema names, identifiers, customer data, and business logic. A server-backed formatter may receive that query under its own retention and logging practices, so review those practices before sharing sensitive SQL.

The PII Leakage Risk

Queries like SELECT * FROM users WHERE email = '...' can contain personal data. Sending them to a third-party formatter creates an additional data-transfer and handling path.

Reconnaissance Risk

Table names, joins, and filters can reveal application structure. Treat production queries as sensitive operational context even when they contain no row data.

The Local Solution

OpsecForge formats the SQL in the loaded browser page and does not send the query to a formatting backend. This reduces one data-transfer path but does not by itself establish GDPR, SOC 2, HIPAA, or other compliance.

A worked example

Paste the single line below into the input box with Standard dialect and default options. Multi-word keywords such as LEFT JOIN, GROUP BY, ORDER BY and UNION ALL stay together on one line, and a SELECT list with more than one column puts each column on its own line.

Input
select u.id, count(o.id) as n from users u left join orders o on o.user_id = u.id group by u.id order by n desc
Output
SELECT
  u.id,
  count(o.id) AS n
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id
ORDER BY n DESC

What the dialect setting changes

The three settings share one layout engine. The dialect changes only two things: which extra words are treated as keywords (for example ILIKE, JSONB and RETURNING in PostgreSQL; ENGINE, UNSIGNED and CHARSET in MySQL) and whether PostgreSQL dollar-quoted strings such as $$ ... $$ are kept as one token. Backtick-quoted identifiers and operators like ->> and :: are recognised in every mode. No dialect-specific syntax is checked: the formatter will lay out invalid SQL without complaint.

Concretely, insert into users (id) values (1) returning id puts RETURNING id on its own line in PostgreSQL mode. In Standard and MySQL modes returning is not a keyword, so it is left as typed on the VALUES line.

Share this: