Formateador y embellecedor de SQL: 11 dialectos, minificación y resaltado
Convierte SQL desordenado en consultas legibles y con sangría coherente para PostgreSQL, MySQL, T-SQL, BigQuery y más. Funciona en tu navegador.
Funciona por completo en tu navegador. Tu SQL nunca se envía a un servidor, así que los nombres del esquema y los datos de las consultas siguen siendo privados. Ver todas las herramientas gratis.
¿Encontraste un problema o algo que podría mejorar? Leemos todos los mensajes y lo arreglamos rápido.
Este formateador de SQL gratis convierte una consulta pegada desde un log, un ORM o una migración de una sola línea en SQL legible: una cláusula por línea, sangría coherente y palabras clave en las mayúsculas o minúsculas que elijas. Elige el dialecto de tu base de datos para que la sintaxis, como las conversiones :: y los cuerpos de función $$ de PostgreSQL, los acentos graves de MySQL, los [corchetes] y las @variables de T-SQL o las cláusulas QUALIFY de BigQuery y Snowflake, se entienda en lugar de destrozarse.
Formatear solo cambia los espacios en blanco y las mayúsculas de las palabras clave, los tipos de datos y los nombres de funciones. Los literales de cadena, los identificadores entre comillas y los comentarios se dejan exactamente como estaban. El formateador necesita analizar tu SQL para maquetarlo, así que el SQL con plantillas (bloques {{ }} de dbt o Jinja) y algunas sentencias específicas de un proveedor pueden fallar; cuando ocurre, te indica la línea y la columna donde se detuvo. Minificar hace lo contrario: una sola línea, sin comentarios, conservando las pistas del optimizador como /*+ INDEX(...) */.
Cómo usarla
- Pega una o varias sentencias SQL en el cuadro. Se carga una consulta de ejemplo para que veas primero el resultado.
- Elige el dialecto que usa tu base de datos. Es lo que más importa para las comillas, los parámetros y la sintaxis propia de cada proveedor.
- Ajusta las mayúsculas de las palabras clave, la sangría y el número de líneas en blanco entre sentencias. La salida se actualiza al cambiarlos.
- Cambia a Minificar si necesitas la consulta en una sola línea, por ejemplo dentro de una configuración JSON o de un comando de shell.
- Copia el resultado o descárgalo como archivo .sql.
Preguntas frecuentes
¿Formatear cambia lo que hace mi consulta SQL?
No. El formateador solo cambia los espacios en blanco y las mayúsculas de las palabras clave, los tipos de datos y las funciones, que las bases de datos SQL tratan sin distinguir mayúsculas y minúsculas. Los valores de cadena, los identificadores entre comillas ("Column", `col`, [col]) y los comentarios se copian sin cambios, así que la consulta devuelve los mismos resultados. Los nombres de tablas y columnas no cambian de mayúsculas, con una excepción: un nombre sin comillas que también es palabra clave en el dialecto elegido (por ejemplo, un alias llamado month) sigue las mayúsculas de las palabras clave. Los nombres sin comillas no distinguen mayúsculas en la mayoría de las bases de datos, así que rara vez importa, pero los nombres de tabla de MySQL pueden distinguirlas en Linux; elige Conservar para dejar tu texto exactamente como lo escribiste.
¿Qué dialecto SQL debo elegir?
El que use tu base de datos. El SQL estándar sirve para sentencias SELECT, INSERT y UPDATE sencillas, pero no conoce las conversiones :: ni los parámetros $1 de PostgreSQL, los identificadores con acento grave ni los comentarios # de MySQL, los corchetes, las @variables ni TOP de T-SQL, los bloques PL/SQL de Oracle ni la cláusula QUALIFY de BigQuery y Snowflake. Si el formateo falla con un error de análisis, elegir el dialecto correcto es lo primero que hay que probar.
¿Por qué el formateador dice "Parse error"?
Ha llegado a un token que no esperaba en el dialecto elegido. Las causas habituales son un dialecto equivocado, un paréntesis o una comilla sin cerrar, marcadores de plantilla como {{ ref("orders") }} de dbt o código procedural que el analizador no cubre. La línea de estado muestra la línea y la columna, y el recuadro de debajo señala el carácter, lo que normalmente basta para encontrar el problema.
¿Las palabras clave de SQL deben ir en mayúsculas?
Es una convención, no una regla. Las palabras clave en mayúsculas (SELECT, FROM, WHERE) hacen que la estructura destaque frente a los nombres de tablas y columnas, y son el estilo más habitual en la documentación y las guías de estilo. Muchos equipos que usan dbt o editores modernos con resaltado de sintaxis prefieren las minúsculas. Elige una y aplícala en todas partes; esta herramienta convierte en ambos sentidos o conserva lo que escribiste.
¿Es seguro minificar SQL?
Sí, para la consulta en sí: minificar compacta los espacios en blanco y elimina los comentarios -- y /* */, y nunca toca el interior de las cadenas. Las pistas del optimizador (/*+ ... */) y los comentarios de versión de MySQL (/*! ... */) se conservan porque cambian el comportamiento. El precio es la legibilidad, así que minifica solo para transportar la consulta (una configuración JSON, una variable de entorno, una línea de log) y guarda la versión formateada en tu repositorio.
¿Se envía mi SQL a un servidor?
No. La biblioteca de formateo se descarga en tu navegador y se ejecuta allí. Los nombres de tablas y columnas y cualquier dato de tus cláusulas WHERE nunca salen de tu equipo.
Diferencias entre dialectos que rompen los formateadores
• Comillas de identificadores: el SQL estándar y PostgreSQL usan "comillas dobles", MySQL y MariaDB usan `acentos graves` y SQL Server usa [corchetes]. Un formateador configurado con el dialecto equivocado puede leer un nombre entre comillas como una cadena o un operador.
• Parámetros: PostgreSQL usa $1, $2; MySQL y SQLite usan ?; SQL Server usa @name; Oracle usa :name. Se conservan exactamente como están escritos.
• Conversiones y operadores: PostgreSQL tiene value::type, los operadores JSON -> y ->>, e ILIKE. BigQuery y Snowflake tienen QUALIFY para filtrar funciones de ventana. Spark y Hive tienen LATERAL VIEW.
• Cadenas y cuerpos: los cuerpos de función de PostgreSQL suelen ir entre $$ ... $$ (dollar quoting) y las cadenas con escapes usan E'...'. Todo lo que hay dentro se trata como una sola cadena y no se toca.
• Comentarios: -- y /* */ funcionan en todas partes; # inicia un comentario solo en MySQL y MariaDB. En T-SQL, #name es una tabla temporal.
Un estilo de SQL legible en cinco reglas
Las guías de estilo de SQL publicadas difieren en detalles como las comas al principio o al final, pero la mayoría coinciden en unas pocas reglas de maquetación, y este formateador las aplica por defecto:
• Una cláusula principal por línea: SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT.
• Una columna seleccionada por línea, para que los diffs muestren exactamente qué columna ha cambiado.
• Las condiciones tras AND u OR en su propia línea dentro de WHERE y ON.
• Las subconsultas y los cuerpos de CTE, con un nivel más de sangría que su padre.
• Una línea en blanco entre las sentencias de un script, para que cada sentencia se lea como una unidad.
Lo que un formateador no puede hacer es poner buenos nombres. Usa alias de tabla que signifiquen algo (orders o está bien, t1 no) y da a las columnas calculadas un nombre explícito con AS.
Herramientas gratis relacionadas
- Formateador JSON — Formatea, minifica y valida JSON, con los errores de análisis localizados por línea y columna. En tu navegador, sin subir nada.
- JSON a TypeScript — Pega una muestra JSON y obtén interfaces de TypeScript, un esquema Zod, JSON Schema o tipos para Go, Python, Java, C#, Kotlin, Swift y Rust.
- Validador de YAML — Valida YAML con la línea y la columna exactas de cada error, y detecta los fallos que los analizadores aceptan sin avisar: booleanos yes/no, tabulaciones, claves duplicadas.
- Probador de regex — Prueba una expresión regular con un texto de ejemplo, con resaltado de coincidencias en vivo, grupos de captura y vista previa de reemplazo. Gratis, en tu navegador.
- Comparador de textos — Compara dos versiones de un texto, código o archivo JSON y ve exactamente qué líneas, palabras y caracteres cambiaron.