Formateador de SQL

Convierte SQL largo y desordenado en consultas limpias y con sangría para MySQL, PostgreSQL, SQL Server, SQLite, BigQuery y más.

Funciona 100% en tu navegador. Nada de lo que pegas se sube ni se guarda.
Consulta SQL
SQL formateado
Listo.

Cómo usar el formateador de SQL

  1. Pega una o varias sentencias SQL en el cuadro de entrada.
  2. Selecciona el dialecto que corresponde a tu base de datos: SQL estándar, MySQL, PostgreSQL, SQL Server (T-SQL), SQLite, MariaDB, BigQuery, Snowflake u Oracle PL/SQL.
  3. Elige cómo escribir las palabras clave: en MAYÚSCULAS, en minúsculas o conservarlas tal como están escritas.
  4. Ajusta el tamaño de la sangría.
  5. Haz clic en Formatear SQL y copia el resultado.

Tus consultas se formatean en el navegador y nunca se suben ni se guardan, así que puedes pegar sin problema consultas de producción que revelen nombres de tablas o lógica de negocio.

¿Por qué formatear SQL?

A SQL no le importan los espacios en blanco: la base de datos ejecuta una consulta en una sola línea exactamente igual que una bien sangrada. Las personas, en cambio, las leen de forma muy distinta. Las consultas copiadas de los logs del ORM, de herramientas de monitorización o de informes de consultas lentas suelen llegar como una única línea larga, y así cuesta ver qué condiciones pertenecen a qué join o subconsulta.

Un formateador coloca cada cláusula principal (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) en su propia línea y aplica una sangría coherente a las partes anidadas. Compara:

select u.id,u.email,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,u.email having count(o.id)>5 order by orders desc;
SELECT
  u.id,
  u.email,
  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,
  u.email
HAVING
  COUNT(o.id) > 5
ORDER BY
  orders DESC;

La versión formateada es más fácil de revisar en una pull request y de depurar, y genera diffs más limpios cuando alguien añade más adelante una columna o una condición.

Por qué importa el dialecto

Cada base de datos amplía el SQL estándar con su propia sintaxis. Elegir el dialecto correcto ayuda al formateador a reconocer bien las palabras clave, los operadores y el entrecomillado de identificadores:

DialectoEntrecomillado de identificadoresEjemplos de sintaxis específica
MySQL / MariaDB`backticks`LIMIT 10, ON DUPLICATE KEY UPDATE
PostgreSQL"double quotes"conversiones con ::, RETURNING, ILIKE
SQL Server (T-SQL)[brackets]SELECT TOP 10, @variables
BigQuery`backticks`STRUCT, UNNEST, EXCEPT en SELECT *
Oracle PL/SQL"double quotes"FETCH FIRST 10 ROWS ONLY, bloques BEGIN … END;

Si una consulta se formatea de forma extraña, por ejemplo si un operador queda partido o una palabra clave se trata como nombre de columna, cambiar al dialecto correcto suele solucionarlo.

Errores comunes de SQL que el formateo te ayuda a detectar

Un formateador no ejecuta ni valida por completo tu consulta, pero una estructura clara deja muchos fallos a la vista:

  • Una coma que falta en la lista del SELECT. SELECT id name FROM users es SQL válido, pero devuelve id con el alias name. Con una columna por línea, la coma que falta salta a la vista.
  • Un filtro sobre una tabla de un outer join en el WHERE. LEFT JOIN orders o … WHERE o.status = 'paid' convierte sin avisar el outer join en un inner join. Pasa la condición a la cláusula ON si quieres conservar las filas sin coincidencia.
  • AND y OR mezclados sin paréntesis. AND tiene más prioridad que OR, así que a OR b AND c significa a OR (b AND c). Añade paréntesis para dejar clara la intención.
  • Paréntesis o comillas sin cerrar. Cuando la sangría del resultado se desvía de repente, busca un paréntesis o una cadena literal sin cerrar justo antes de ese punto.

Consejos y buenas prácticas

  • Escribir las palabras clave en mayúsculas es una convención muy extendida porque separa la sintaxis de SQL de los nombres de tus tablas y columnas; las minúsculas son igual de válidas. Elige una opción por proyecto.
  • Usa siempre alias para las tablas en consultas con varias tablas y cualifica los nombres de columna (u.id en lugar de id).
  • Nunca construyas SQL concatenando datos introducidos por el usuario. Usa consultas parametrizadas o sentencias preparadas para evitar la inyección SQL.
  • ¿Guardas fechas y horas como enteros? Usa el conversor de timestamp Unix para comprobar qué significa un valor, y el generador de UUID para claves primarias de prueba.
Consejo: ¿Quieres formatear el resultado de una consulta guardado como JSON? Pégalo en el formateador de JSON.

Preguntas frecuentes

¿El formateo cambia lo que hace mi consulta?

No. El formateador solo cambia los espacios en blanco, los saltos de línea y, si lo eliges, las mayúsculas o minúsculas de las palabras clave. Los identificadores, las cadenas literales y la lógica de la consulta no cambian.

¿El formateador de SQL comprueba si mi consulta es válida?

No del todo. Divide la consulta en tokens para organizarla, así que una entrada muy defectuosa puede dar un resultado extraño, pero no comprueba que las tablas o columnas existan ni que la sentencia se pueda ejecutar. Para eso, usa tu base de datos o un EXPLAIN.

¿Puedo formatear varias sentencias a la vez?

Sí. Separa las sentencias con punto y coma y se formatearán una tras otra.

¿Las palabras clave de SQL deben ir en mayúsculas?

Las palabras clave de SQL no distinguen entre mayúsculas y minúsculas en ninguna de las principales bases de datos, así que es puramente una cuestión de estilo. Las mayúsculas son lo tradicional y lo habitual en la documentación; muchos equipos actuales prefieren las minúsculas. Lo que importa es la coherencia.

Actualizado

Copiado al portapapeles