Formateador de SQL | Separa Consultas Apretadas en Cláusulas Legibles

Pega un volcado SQL de una sola línea de un registro de ORM o una consulta minificada, y esta herramienta lo divide en líneas separadas por cláusula — SELECT, FROM, WHERE, JOIN — con sangría de 4 espacios. Las palabras reservadas se normalizan a mayúsculas y más de 100 palabras clave, literales de texto, números y comentarios se resaltan con color.

💡 Sobre esta herramienta

Abres una solicitud de cambios y el SQL es una única línea larga. No distingues dónde termina la condición de unión y dónde empieza el filtro. Esta herramienta traza esos límites de cláusula de forma mecánica para que la consulta se pueda leer de un vistazo.

El formateo se apoya en un analizador léxico, no en una expresión regular ingenua. Los literales de texto ('...' y "...") y los comentarios (-- de línea y /* */ de bloque) se extraen como tokens distintos, así que su contenido nunca se modifica: solo las palabras clave fuera de ellos pasan a mayúsculas. Las cláusulas compuestas como GROUP BY, ORDER BY y LEFT OUTER JOIN se reconocen como una sola unidad y se colocan en su propia línea. Cuando una subconsulta abre con SELECT entre paréntesis, la sangría aumenta un nivel y vuelve atrás en el paréntesis de cierre, de modo que la profundidad de anidamiento se ve directamente en la sangría. Las expresiones CASE indentan sus ramas WHEN / THEN / ELSE y se alinean en END.

Los paneles de entrada y salida quedan lado a lado, así que puedes comparar el original con el resultado. Copia la salida directamente a un cliente SQL o a un comentario de revisión de código.

🧐 Preguntas Frecuentes

P. ¿Qué dialectos de SQL admite? R. Además del SQL estándar, el conjunto de palabras clave cubre identificadores con comillas invertidas de MySQL, RETURNING / ON CONFLICT de PostgreSQL y términos de funciones de ventana como OVER / PARTITION BY: más de 100 palabras reservadas comunes a los dialectos principales. Las funciones propias de cada dialecto se tratan como identificadores, lo que no afecta a la disposición.

P. ¿Un SELECT dentro de una cadena pasará a mayúsculas? R. No. Los literales de texto entre comillas simples o dobles y los comentarios se aíslan como tokens separados durante el análisis, y su contenido se deja tal cual.

P. ¿Puedo formatear varias sentencias a la vez? R. Sí. Las sentencias separadas por punto y coma (;) se formatean cada una, con una línea en blanco entre ellas.

P. ¿Puedo cambiar el ancho de la sangría? R. Está fijado en 4 espacios. Ajústalo después con la función de buscar y reemplazar de tu editor si prefieres un estilo de 2 espacios.

P. ¿El resultado podría salir mal alguna vez? R. El SQL construido por concatenación de cadenas o salpicado con marcadores de plantilla (como {{ }}) se aparta de la gramática que espera el analizador, por lo que los saltos de línea pueden caer en lugares inesperados.

📚 Datos Curiosos

La costumbre de escribir las palabras clave de SQL en mayúsculas se remonta a una época en que SQL se diseñó para no distinguir mayúsculas de minúsculas, y poner en mayúscula las palabras reservadas era una forma práctica de separarlas de los identificadores en un terminal monocromo. El SQL ANSI acepta sin problema las palabras clave en minúscula, pero muchas guías de estilo siguen recomendando mayúsculas por costumbre. El uso de mayúsculas en los identificadores, en cambio, se maneja de forma distinta en cada base de datos: PostgreSQL convierte a minúsculas los identificadores sin comillas. Un formateador que pone en mayúscula solo las palabras reservadas y conserva la grafía original de los identificadores evita romper esas diferencias.