Formateador de SQL

Convierte un SQL ilegible de una sola línea en una consulta bien indentada — 18 dialectos, todo en tu navegador.

Cómo usar

  1. Pega tu SQL en el campo de entrada: una consulta, un procedimiento almacenado o un archivo de migración completo. "Cargar un ejemplo desordenado" llena el campo con una consulta deliberadamente fea.
  2. Elige el dialecto que habla tu base de datos — PostgreSQL, MySQL, SQL Server y otros quince aceptan sintaxis que el SQL estándar rechaza — y después elige el uso de mayúsculas en las palabras clave y la indentación que prefieras.
  3. Haz clic en "Formatear SQL" y luego copia el resultado o descarga el archivo .sql — la consulta nunca se sube.

Sobre esta herramienta

El SQL rara vez llega legible: una línea interminable salida de un ORM, todas las palabras clave en minúsculas en un log de consultas lentas, la indentación destruida por un cliente de chat. Reformatearlo a mano antes siquiera de poder leerlo te cuesta diez minutos — y la lectura es donde están los errores: una condición de join que en silencio se volvió un filtro, un OR que abarca más de lo que su autor creía, una subconsulta de tres niveles. Pégalo aquí y vuelve con una cláusula por línea, el anidamiento alineado y las palabras clave en el formato que prefieras.

El trabajo lo hace un parser de verdad, no un montón de expresiones regulares. La consulta se tokeniza, se entiende como un árbol de cláusulas y se vuelve a imprimir, y por eso los comentarios se quedan en la línea donde se escribieron, los literales de texto sobreviven intactos incluso cuando contienen palabras como SELECT o FROM, y una función de ventana conserva su bloque OVER (PARTITION BY … ORDER BY …) correctamente anidado. Se ofrecen dieciocho dialectos — Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark, Trino, Hive, Db2, Db2 for i, TiDB, SingleStore y N1QL — y la elección no es decorativa: las comillas de dólar de PostgreSQL ($$body$$) y los corchetes de T-SQL ([dbo].[table]) son errores de análisis bajo Standard SQL y se formatean perfectamente con el dialecto correcto. Los marcadores de posición como ?, :name, $1 y @name se reconocen en todos los dialectos y se pasan tal cual, así que el SQL copiado directamente de un log de consultas no se estropea.

Dos límites honestos. El formateador solo verifica que el texto sea SQL gramaticalmente válido para el dialecto elegido: no sabe nada de tus tablas, así que formateará una consulta que hace referencia a una columna que no existe, y nunca ejecuta nada. Cuando el texto no se puede analizar, indica dónde se rindió el parser, con línea y columna, en vez de devolver un revoltijo a medio formatear. La privacidad es la razón para formatear aquí y no en un sitio cualquiera: las consultas de producción llevan nombres de tablas, lógica de negocio y a veces datos personales. La biblioteca (sql-formatter, licencia MIT, servida desde vai.la y descargada solo en tu primer formateo) se ejecuta dentro de tu navegador.

Preguntas frecuentes

¿Sale mi SQL de mi navegador?

No. La consulta se analiza y se vuelve a imprimir mediante JavaScript en tu propio dispositivo — no se sube, no se registra ni se guarda nada. Eso importa, porque las consultas reales exponen tu esquema, tus reglas de negocio y a veces datos personales metidos en los literales. Después del primer formateo puedes desconectarte de internet y sigue funcionando.

¿Qué dialecto debo elegir?

El que habla tu base de datos. Standard SQL cubre la mayoría de las consultas corrientes, pero la sintaxis específica de cada base necesita el dialecto correspondiente: los [corchetes] necesitan SQL Server (T-SQL), las $$comillas de dólar$$ necesitan PostgreSQL. Un error de análisis sobre SQL válido suele resolverse cambiando de dialecto.

¿Formatear puede cambiar lo que hace mi consulta?

No. Solo cambian los espacios en blanco, los saltos de línea y el uso de mayúsculas en las palabras clave. Los identificadores, los literales de texto, los números y los comentarios vuelven exactamente como los escribiste, así que la consulta formateada es equivalente a la original.

¿Por qué dice que no se pudo analizar mi SQL?

Porque el parser encontró algo que no encajaba en la gramática, en la línea y la columna que se muestran. Tres causas habituales: un error de tipeo, como una coma, una comilla o un paréntesis que faltan; un fragmento que no es una sentencia completa; o sintaxis específica de una base de datos con el dialecto equivocado seleccionado.

¿Maneja los marcadores de posición de un ORM o de una sentencia preparada?

Sí. Los marcadores posicionales (?), numerados ($1) y con nombre (:name, @name) se reconocen en todos los dialectos y se imprimen de vuelta sin cambios, así que puedes pegar directamente desde un log de consultas o desde la salida de depuración de un framework.

¿Puedo formatear un archivo de migración completo?

Sí. Las sentencias separadas por punto y coma se formatean una tras otra, con una línea en blanco entre ellas. La entrada tiene un tope de 300.000 caracteres para que la página nunca se congele; más allá de eso, divide el archivo.

Herramientas relacionadas

¿Enlaces largos? Acórtalos gratis

Vai.la convierte cualquier URL en un enlace corto con estadísticas de clics, código QR y tu propio biolink.

Vai.la no se hace responsable del uso de las herramientas ni de las decisiones tomadas a partir de sus resultados.