Saltar al contenido

Formateador SQL

Parte tu consulta por cláusulas (SELECT, FROM, WHERE …) y la sangra. Dialectos: SQL estándar, MySQL, PostgreSQL, SQLite, T-SQL y BigQuery. No valida sintaxis.

0 caracteres · 0 líneas
Mayúsculas/minúsculas de palabras clave

Salida0 caracteres · 0 líneas

Lo que introduces se procesa solo en este navegador y nunca se envía a un servidor. Cómo funciona

Una consulta SQL en una línea se formatea con saltos y sangría para SELECT y FROM

Cómo usarlo

Empieza por «Dialecto»: elige la base de datos en la que vas a ejecutar la consulta. Las opciones son «SQL estándar», «MySQL», «PostgreSQL», «SQLite», «T-SQL (SQL Server)» y «BigQuery». Después pega la consulta en «Entrada» y decide estas tres cosas:

  • Mayúsculas/minúsculas de palabras clave: «Mayúsculas (SELECT)», «Minúsculas (select)» o «Tal como se escribió».
  • Sangría: «2 espacios», «4 espacios» o «Tabulador».
  • Líneas en blanco entre consultas: cuántas líneas vacías se dejan entre consultas separadas por punto y coma (;). Admite de 0 a 5 y de entrada vale 1.

Así queda esta línea con SQL estándar, mayúsculas y 2 espacios:

select u.id, count(o.id) as orders from users u left join orders o on o.user_id = u.id where u.created_at >= '2026-01-01' group by u.id having count(o.id) > 3 order by orders desc
SELECT
  u.id,
  count(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at >= '2026-01-01'
GROUP BY
  u.id
HAVING
  count(o.id) > 3
ORDER BY
  orders DESC

En «Salida», las palabras clave van en negrita, las cadenas y los números en color y los comentarios en cursiva. Ese resaltado se guía solo por la forma de cada palabra: una columna que se llame igual que una palabra reservada, como default o index, se ve en negrita como si fuera una palabra clave a menos que la pongas entre comillas. Si el resultado supera los 200.000 caracteres, aparece «El resultado es grande y se muestra sin colores» y se muestra solo el texto. Las cifras «Líneas» y «Tamaño» de debajo corresponden al resultado ya formateado.

Si pegas varias consultas a la vez, cada una se formatea por separado tomando el punto y coma como frontera. Si la última no lleva punto y coma, el resultado tampoco se lo añade.

Hasta dónde llega el cambio de mayúsculas y minúsculas

«Mayúsculas/minúsculas de palabras clave» solo afecta a las palabras reservadas, como select, from, as o join. Los nombres de funciones, los tipos de datos, los nombres de tablas y columnas y el texto de las cadenas se quedan como los escribiste.

  • Con «Mayúsculas (SELECT)», select count(*), cast(x as int) from t sale con SELECT, AS y FROM en mayúsculas, mientras que count(*) e int siguen en minúsculas.
  • Con «Minúsculas (select)», en SELECT Now() FROM t pasan a minúsculas select y from, y Now() no cambia.
  • Lo que va entre comillas en where name = 'select from' no se altera con ningún ajuste.

Si la guía de estilo de tu equipo pide también COUNT o INT en mayúsculas, esa parte tendrás que corregirla tú.

Qué pasa si eliges el dialecto equivocado

Cada base de datos escribe a su manera las comillas y los marcadores de posición. Con un dialecto que no corresponde, una consulta que se ejecuta sin problema puede no interpretarse y acabar en error. Esto es lo que ocurre al pasar la misma entrada por los seis dialectos:

Entrada Dialectos que dan error Dialectos que la formatean
select [a] from [t] SQL estándar, MySQL (línea 1, columna 8) PostgreSQL, SQLite, T-SQL, BigQuery
select `a` from `t` PostgreSQL, T-SQL (línea 1, columna 8) SQL estándar, MySQL, SQLite, BigQuery
select a::int from t SQL estándar, MySQL, SQLite, BigQuery (línea 1, columna 9) PostgreSQL, T-SQL
select * from t where a = $1 SQL estándar, SQLite, T-SQL, BigQuery (línea 1, columna 27) MySQL, PostgreSQL

Y aunque no haya error, el resultado puede variar en detalles. Con «T-SQL (SQL Server)», select top 5 a from t sale con TOP en mayúsculas; en los otros cinco dialectos top no se reconoce como palabra clave y se queda en minúsculas. Al revés, limit 5 solo se queda en minúsculas en T-SQL. En vez de ir cambiando de dialecto hasta que desaparezca el error, lo seguro es elegir la base de datos que usas de verdad.

Que no dé error no significa que el SQL esté bien

Esta herramienta ni ejecuta la consulta ni revisa su sintaxis de principio a fin. Se limita a separar las palabras, localizar dónde empieza cada cláusula y alinear las líneas, de modo que la mayoría de las consultas incorrectas pasan sin más.

  • selct * form users (con erratas) sale sin error y en una sola línea, igual que entró. Que no se haya partido en cláusulas es la única pista.
  • select * from users where (falta la condición) se formatea y termina en WHERE.

Lo que sí se detecta como error son, sobre todo, los paréntesis o las comillas sin pareja y los símbolos que no existen en el dialecto elegido. En esos casos aparece un mensaje como «No se pudo interpretar este SQL. Revisa cerca de la línea 1, columna 24.», con esa línea y una marca ^.

Entrada (SQL estándar) Posición indicada Causa
select * from (select 1 línea 1, columna 24 (el final de la entrada) paréntesis sin cerrar
select * from users) línea 1, columna 20 cierre sin paréntesis de apertura
select 'abc línea 1, columna 8 comilla sin cerrar

Un paréntesis sin cerrar apunta al final de la entrada, así que no busques en el punto marcado: busca antes el paréntesis de apertura que se ha quedado sin pareja.

El motor de formato se descarga al escribir por primera vez

Del formato se encarga sql-formatter, una biblioteca de código abierto. Como pesa bastante, no se carga al abrir la página, sino en el momento en que introduces la primera consulta; mientras llega, en el cuadro de salida se lee «Formateando…». Lo único que se descarga es el código del motor, y la consulta no viaja en esa petición. Si después de abrir la página te quedas sin conexión a internet y escribes por primera vez, verás «No se pudo cargar el motor de formato. Comprueba tu conexión a internet y recarga la página.».

No hay un modo para minificar en una sola línea. La biblioteca solo ofrece el formato en varias líneas, y quitar los espacios sin ayuda de la biblioteca podría tocar también los que hay dentro de cadenas y comentarios, así que se ha dejado fuera. Si quieres menos líneas, lo máximo que puedes hacer es poner «Líneas en blanco entre consultas» a 0.

Fuentes

Preguntas frecuentes

Quiero que una parte de la consulta se quede tal como la he alineado a mano. ¿Se puede?

Sí: enciérrala entre los comentarios /* sql-formatter-disable */ y /* sql-formatter-enable */. Lo que haya entre los dos no se interpreta y pasa al resultado carácter a carácter; solo se formatea la consulta de antes y la de después. Los dos comentarios también se quedan en el resultado.

¿Formatea scripts con procedimientos almacenados o con DELIMITER?

No como es debido. La documentación de sql-formatter, el motor de formato, avisa de que no admite procedimientos almacenados ni las instrucciones que cambian el delimitador de consultas por algo distinto del punto y coma. En la práctica, si pegas con el dialecto MySQL un procedimiento que empieza por DELIMITER //, sale un resultado sin ningún error, pero // se separa en / / y los saltos de línea del cuerpo quedan descolocados. Con scripts así, saca las sentencias SELECT o UPDATE del procedimiento y formatéalas por separado.

He copiado la consulta del código y lleva marcas de plantilla como {{ name }}. ¿Qué ocurre?

Da error en los seis dialectos. Con select * from t where a = {{ var }} y SQL estándar, el error apunta a la línea 1, columna 27, justo donde está la llave de apertura. Sustituye la parte de plantilla por un valor provisional (por ejemplo, el número 1 o 'x'), formatea y vuelve a ponerla después. Los marcadores de posición como el signo de interrogación (?), $1 o :name se aceptan o dan error según el dialecto.

Software de código abierto utilizado: sql-formatter (MIT), nearley (MIT)

Última actualización: