SQL-formatter
Formatteer en mooi-print SQL-queries. Ondersteunt MySQL-, PostgreSQL-, SQL Server- en SQLite-dialecten.
Wat doet deze tool
SQL is een write-once, debug-forever taal: je kopieert een query uit een ORM-log of het chatbericht van een collega, en hij komt binnen als een one-liner van 400 tekens. Deze online SQL-formatter neemt die tekstmuur en zet hem netjes uit over meerdere regels met consistente inspringing, één clausule per regel, uitgelijnde JOIN-condities en lange SELECT-lijsten verticaal gestapeld. Hij is dialectbewust en begrijpt dus PostgreSQL-features zoals RETURNING, MySQL-backticks, T-SQL vierkante haken, BigQuery EXCEPT-kolomlijsten en SQLite-eigenaardigheden — de gerenderde query blijft geldig voor de engine waarvoor hij geschreven is. Alles gebeurt in je browser, dus de SQL die je plakt verlaat het tabblad nooit en raakt nooit een server. De originele query wordt nooit semantisch gewijzigd — alleen witruimte, regeleinden en hoofdlettergebruik veranderen — dus je kunt het resultaat met vertrouwen terugplakken in je codebase, migratiebestand, pull-request beschrijving, blogpost of chatreactie. Gebruik hem om logs van Postgres, MySQL, SQL Server, BigQuery of SQLite op te schonen, om queries klaar te maken voor code reviews, of gewoon om een query van 200 regels leesbaar te maken voordat je het uitvoeringsplan gaat tunen.
Hoe gebruik je de formatter
Kies een dialect dat past bij de database waarop je richt, plak je SQL in het tekstvak, kies de hoofdletterstijl en inspringing van je voorkeur, en klik op Formatteren. De uitvoer verschijnt eronder met een kopieerknop voor één klik.
- Plak je SQL — Bij twijfel verwerkt Standaard SQL de meeste ANSI-conforme queries. Schakel over naar een vendor-dialect wanneer je query identifiers gebruikt zoals
`backticks`,[brackets], of vendor-specifieke trefwoorden (RETURNING,QUALIFY, enz.). - Kies een dialect — HOOFDLETTERS is de feitelijke standaard voor SQL in code reviews. kleine letters leest meer als gewone tekst. Behouden houdt aan wat je al getypt hebt.
- Stel inspringing in — 2 spaties is de meest gebruikte standaard. 4 spaties is vriendelijker voor geneste CTE's. Tab matcht editors die zijn ingesteld op tab-only inspringing.
- Kopieer de uitvoer — Klik op SQL formatteren, bekijk de uitvoer, en gebruik de kopieerknop om hem op je klembord te zetten. Plak hem terug in je editor, migratiebestand of chatreactie.
Hoe het formatteren werkt
De formatter zet één hoofdclausule per regel: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT. Elke JOIN staat op zijn eigen regel met de bijbehorende ON-conditie één niveau ingesprongen. Items in een SELECT-lijst, VALUES-tupel of IN (…)-clausule worden over meerdere regels gesplitst wanneer ze de regelbreedte overschrijden. Subqueries en CTE's krijgen een extra inspringniveau ten opzichte van hun parent. Commentaar (-- en /* */) blijft letterlijk behouden. Het resultaat is dezelfde set statements waar je mee begon — alleen zo opgemaakt dat menselijke reviewers de structuur van de query in één oogopslag kunnen scannen.
Dialect-verschillen
Elk dialect behandelt identifier-quoting, string-concatenatie en een handvol vendor-trefwoorden anders. Kies het dialect dat past bij de engine waarvoor je schrijft.
| Dialect | Eigenaardigheden die de formatter respecteert |
|---|---|
| Standaard SQL | ANSI-conforme basis. Dubbele aanhalingstekens voor identifiers, enkele aanhalingstekens voor strings, || voor concatenatie. |
| PostgreSQL | Voegt RETURNING, ON CONFLICT, ::cast, dollar-quoted strings ($$) en array-literalen toe. |
| MySQL | Backtick-identifiers, STRAIGHT_JOIN, SQL_CALC_FOUND_ROWS, dubbele aanhalingstekens voor strings toegestaan. |
| BigQuery | Backtick voor project/dataset/tabel-referenties, EXCEPT in kolomlijsten, QUALIFY, UNNEST. |
| T-SQL (SQL Server) | Vierkante-haak-identifiers, TOP n, OUTPUT INSERTED.*, NOLOCK-hints. |
| SQLite | Grotendeels ANSI; kleine verschillen in WITHOUT ROWID, CONFLICT-afhandeling en het soepele typesysteem. |
Veelgestelde vragen
Wordt mijn query naar een server gestuurd?
Nee. Het formatteren gebeurt volledig binnen je browsertabblad, dus de SQL die je plakt — inclusief gevoelige tabelnamen, kolomnamen, gehardcodeerde id's of productiedata in WHERE-clausules — bereikt nooit onze servers of een derde partij. Je kunt de netwerkverbinding verbreken nadat de pagina is geladen en de formatter blijft werken.
Waarom ziet het resultaat er iets anders uit dan de formatter van mijn IDE?
Elke SQL-formatter heeft zijn eigen meningen over regeleinden, leading vs trailing komma's en hoe lange CASE-expressies worden gewikkeld. De standaardinstellingen hier volgen conventies die gangbaar zijn in professionele database-editors en code reviews. Heb je een exacte match met de stijlgids van je team nodig, draai het resultaat dan als laatste pass door de favoriete formatter van je team.
Voert hij mijn query uit?
Nee. Alleen het formatteren (witruimte en hoofdlettergebruik) gebeurt. De query wordt nooit uitgevoerd, gevalideerd tegen een databaseschema of ergens naartoe gestuurd.
Begrijpt hij stored procedures en PL/pgSQL-blokken?
Hij formatteert de buitenste SQL prima, maar behandelt de procedurale body als ondoorzichtige tekst — regeleinden binnen BEGIN … END blijven behouden maar worden niet opnieuw gewikkeld. Voor complexe stored procedures gebruik je beter een vendor-specifieke tool zoals de formatter van pgAdmin.
Wat als ik het dialect op Standaard SQL laat staan maar mijn query MySQL-backticks gebruikt?
De formatter levert meestal nog steeds een verstandig resultaat, maar vendor-specifieke trefwoorden kunnen verkeerd ingesprongen of verkeerd gehoofdletterd raken. Kies het bijpassende dialect voor de schoonste output.
Kan hij meerdere statements gescheiden door puntkomma's verwerken?
Ja. Meerdere statements gescheiden door ; worden onafhankelijk geformatteerd en samengevoegd met een lege regel ertussen. Handig om een heel migratiescript in te plakken.