Formateador de SQL
Pega tu SQL y DevKitLab lo vuelve a sangrar según el dialecto elegido, alinea las cláusulas, normaliza las mayúsculas de palabras clave, funciones y tipos de datos, y señala en la barra de estado inferior la línea y la columna de los errores de análisis. Admite más de una decena de dialectos: MySQL, PostgreSQL, SQLite, BigQuery, Snowflake, Redshift, Oracle PL/SQL, SQL Server y más; puedes cambiar el ancho de sangría, la posición del salto de línea de los operadores booleanos, las líneas en blanco entre sentencias, la compacidad de los operadores y la posición del punto y coma, o comprimirlo todo a una sola línea, copiar, subir un archivo, descargar o cargar un ejemplo. Todo se procesa en local en el navegador; tus consultas no se suben a ningún servidor.
- Más de una decena de dialectos a elegir, entre ellos MySQL, PostgreSQL, SQLite, BigQuery, Snowflake, Redshift, Oracle, SQL Server, Spark y Trino
- Mayúsculas de palabras clave, nombres de función y tipos de datos conmutables: mantener el original, todo en mayúsculas o todo en minúsculas
- Sangría de 2 espacios, 4 espacios o tabulador, con líneas en blanco entre sentencias, compacidad de operadores y posición del punto y coma ajustables
- Los operadores booleanos como AND y OR pueden saltar de línea antes o después, para adaptarse a la guía del equipo
- Copia con un clic la versión formateada o la versión compacta de una sola línea, ideal para depurar consultas, registros o parámetros de ORM
- Sube y lee archivos .sql y descarga el resultado formateado, cómodo para ordenar scripts de migración y exportaciones de datos
- Cuando el análisis falla, muestra la línea y la columna con la descripción del error, para localizar problemas de sintaxis en varias sentencias y consultas largas
- Procesamiento totalmente local: las consultas, los nombres de tablas y de bases de datos y los parámetros reales no se envían a un servidor
Resumen
Esta herramienta de SQL reformatea las sentencias según el dialecto elegido y gestiona la sangría de cláusulas, las mayúsculas de las palabras clave, el salto de línea de los operadores booleanos, las líneas en blanco entre sentencias, la compacidad de los operadores y un modo compacto de una sola línea, más adecuada para depurar consultas, revisar SQL, ordenar migraciones y comprobar parámetros de ORM.
- 01
Formateo multidialecto
Incorpora dialectos como MySQL, PostgreSQL, SQLite, MariaDB, TiDB, BigQuery, Snowflake, Redshift, Oracle PL/SQL, SQL Server (Transact-SQL), Spark, Trino, Hive, ClickHouse, DuckDB, Couchbase N1QL y Db2, y formatea según las palabras clave de la sintaxis de cada uno.
- 02
Mayúsculas de palabras clave
Las palabras clave y los nombres de función y tipos de datos habituales pueden mantener el original, ponerse todo en mayúsculas o todo en minúsculas, para ajustarse al estilo del equipo o a las normas de revisión de SQL.
- 03
Sangría y espaciado entre sentencias
Alterna entre 2 espacios, 4 espacios y tabulador, y controla el número de líneas en blanco entre varias sentencias. Al ordenar scripts de migración, de inicialización o fixtures de prueba, puedes elegir entre lo compacto y lo espaciado.
- 04
Posición del salto de AND / OR
Los operadores lógicos pueden saltar de línea antes (cada línea empieza por AND / OR) o después (se quedan al final de la línea anterior), para alinearse con la guía de estilo de SQL del equipo.
- 05
Modo compacto
Al hacer clic en «Copiar comprimido» se aplasta el SQL de varias líneas en una sola, ideal para pegar en llamadas de ORM, campos de registro, la línea de comandos o herramientas que solo admiten consultas de una línea.
- 06
Localización de errores
Cuando sql-formatter falla al analizar, muestra la línea y la columna concretas con la descripción del error, para ayudarte a localizar un paréntesis olvidado, una palabra clave que falta o una sintaxis que el dialecto actual no reconoce.
- 07
Líneas en blanco entre sentencias
Puedes controlar el número de líneas en blanco entre varias sentencias, para que los scripts de migración, de inicialización o los fixtures de prueba queden más compactos o más espaciados.
- 08
Subida y descarga de archivos
Permite seleccionar y leer archivos .sql / .txt locales, y también descargar el resultado formateado como archivo .sql, cómodo para trabajar con herramientas de migración o flujos de control de versiones.
- 09
Procesamiento totalmente local
El análisis, el formateo, la compresión, la lectura de subidas y la descarga ocurren en local en el navegador. Las consultas, los nombres de base de datos, de tablas y de campos y los datos de ejemplo no se envían a un servidor.
Cómo usarla
El flujo habitual es: elige el dialecto, pega el SQL, ajusta a tu gusto las opciones de mayúsculas, sangría y salto de línea, y luego copia la versión formateada o la comprimida.
- 01
Elige abajo el dialecto de destino, por ejemplo MySQL, PostgreSQL, SQLite o BigQuery. El dialecto solo afecta al reconocimiento de palabras clave, no reescribe la semántica.
- 02
Pega en el editor SELECT, JOIN, UPDATE, INSERT, scripts de migración o SQL generado por un ORM; también puedes hacer clic en «Subir archivo» para leer un .sql local.
- 03
Ajusta las mayúsculas de las palabras clave, el ancho de sangría, las líneas en blanco entre sentencias, la compacidad de los operadores y la posición del punto y coma para que la salida se acerque a la convención del equipo.
- 04
Si el equipo acostumbra a empezar cada línea con AND / OR, pon el salto de los operadores booleanos en «Salto antes»; si no, déjalo en «Salto después».
- 05
Revisa el resultado formateado en el editor. Si el análisis falla, mira la línea y la columna y la descripción del error en la barra de estado inferior, y vuelve al SQL original para corregir la sintaxis.
- 06
Cuando necesites un resultado compacto, haz clic en «Copiar comprimido»; cuando necesites uno legible, haz clic en «Copiar formateado», o en «Descargar» para guardarlo como archivo .sql.
- 07
Si quieres afinar más, edita el SQL directamente en el editor y la herramienta seguirá reformateándolo según las opciones actuales.
Detalles
Estas funciones cubren los problemas más habituales al trabajar con SQL a diario: estilo inconsistente, diferencias de palabras clave entre dialectos, necesidad de una forma compacta o legible, necesidad de localizar errores de análisis y necesidad de tratar SQL de producción de forma segura.
- Incorpora sql-formatter, cubre más de 15 dialectos principales y reconoce las palabras clave de cada uno.
- Las mayúsculas de palabras clave, nombres de función y tipos de datos son ajustables, mientras que los nombres de tablas y columnas mantienen el texto original.
- La sangría admite 2 espacios, 4 espacios o tabulador, y controla las líneas en blanco entre sentencias, la compacidad de los operadores y la posición del punto y coma.
- Los operadores booleanos como AND / OR pueden saltar de línea antes o después, para adaptarse a la convención del equipo.
- Puedes copiar con un clic la versión formateada para leer, o la versión comprimida para código, registros y CLI.
- Las líneas en blanco entre sentencias son ajustables, para que los scripts de migración e inicialización se vean más ordenados.
- Al subir un archivo .sql se formatea automáticamente con las opciones actuales; la sintaxis no válida marca la posición del error en la barra de estado.
- Puedes descargar el resultado formateado como archivo .sql, cómodo para subirlo al repositorio o entregarlo a una herramienta de base de datos.
- Todo el procesamiento ocurre en local en el navegador y no sube las consultas, los nombres de tablas, de bases de datos ni los datos de muestra.
Casos de uso
Esta página sirve para todos los casos en los que necesitas dejar el SQL más legible, más uniforme, más fácil de revisar o más apto para pegar en otros sistemas.
-
Depuración de consultas
Pega el SQL de una sola línea que imprime un ORM o las sentencias concatenadas de un registro de depuración y, tras formatearlo, revisa cláusula a cláusula los JOIN, las subconsultas y las condiciones WHERE.
-
Revisión de SQL
Ordena los fragmentos de SQL de un pull request y unifica las mayúsculas de las palabras clave, el ancho de sangría y el estilo de salto de línea del equipo, para centrar la revisión en la lógica.
-
Ordenar scripts de migración e inicialización
Reordena el DDL y el DML de los scripts de migración de Flyway, Liquibase, Knex, Prisma o SQLAlchemy Alembic, conservando las líneas en blanco entre sentencias según haga falta.
-
Consultas de BI e informes
Limpia el SQL de informes de Metabase, Superset, Looker o Redash y asegúrate de que la jerarquía de SELECT, GROUP BY y ORDER BY se vea de un vistazo.
-
Archivar procedimientos almacenados y scripts
Ordena el cuerpo de las sentencias de las definiciones de funciones de PL/SQL, T-SQL o PostgreSQL, para subirlas al repositorio de código o al sistema de documentación.
-
Ejercicios de entrevista y ejemplos docentes
Al preparar ejercicios, respuestas y apuntes de SQL, ordena las consultas de ejemplo con un estilo uniforme para mostrarlas en material de clase, blogs o README.
-
Ordenar la salida de un copiloto de IA
Reformatea el SQL largo que genera un asistente de IA para asegurar una sangría, unas mayúsculas y una posición de palabras clave estables antes de pegarlo en el editor de consultas y validarlo.
-
Extraer SQL de registros
El SQL que copias de los registros de la aplicación o de las consultas lentas suele venir en una sola línea; primero expándelo aquí a una versión legible y luego decide si conviene optimizarlo más.
Ver también
Si trabajas con campos JSON devueltos por el SQL o con payloads de registros, puedes pasarlos por Formateador de JSON para ordenar la estructura, localizar campos y copiar el JSON Path. Cuando necesites exportar los resultados de la consulta a una estructura de filas y columnas, usa Herramientas CSV para previsualizar, editar y convertir tablas CSV / TSV. Si el SQL viene envuelto en prefijos de registro, salida de consola o plantillas repetidas, primero quita el texto exterior con Reemplazo de texto y luego vuelve aquí para seguir formateando.
Algunas advertencias sobre el formateo de SQL
El formateo solo cambia la legibilidad, no la semántica de la consulta. Estos puntos son los que más se malinterpretan entre dialectos y entre equipos.
-
El formateo no reescribe la semántica
La herramienta solo ajusta espacios, saltos de línea, sangría y mayúsculas de palabras clave, y no cambia los nombres de tablas, de campos, los operadores ni los parámetros. El mismo SQL debe dar el mismo resultado antes y después de formatearlo.
-
El dialecto solo afecta al reconocimiento de palabras clave
Elegir PostgreSQL o MySQL afecta sobre todo a qué palabras se consideran clave y a cómo se tratan las comillas y los nombres de función. No traduce la sintaxis de MySQL a la de PostgreSQL.
-
Las mayúsculas de palabras clave son estilo, no requisito
La mayoría de las bases de datos no distinguen mayúsculas y minúsculas en las palabras clave de SQL, pero los equipos suelen acordar un estilo uniforme. Poner las palabras clave en mayúsculas ayuda a distinguirlas de los identificadores en código denso.
-
Cuidado con las mayúsculas de los identificadores
Algunas bases de datos distinguen mayúsculas y minúsculas en los identificadores entre comillas (como PostgreSQL). Si cambias a mano las mayúsculas de un nombre de tabla o columna, confirma el comportamiento de la base de datos de destino y, si hace falta, mantén el original.
-
No sustituye a un analizador de SQL ni a un lint
La herramienta formatea a nivel léxico y no hace validación semántica. Si existen tablas inexistentes, si los tipos de campo coinciden o si se provocan consultas lentas debe comprobarlo la base de datos, el ORM o una herramienta de lint de SQL específica.
-
No ejecuta SQL
Aquí solo se maqueta el texto, no se conecta a ninguna base de datos ni se envían consultas. Aunque pegues un DROP o un DELETE, la herramienta solo formatea el texto.
Buenas prácticas
Cuanto más largo es el SQL y más subconsultas y CTE tiene, más falta hacen unos hábitos de formateo estables. Estas prácticas reducen el ruido y los malentendidos en la revisión.
- Unifica dentro del equipo un dialecto, unas mayúsculas de palabras clave y un estilo de sangría, para no discutir el formato en cada revisión.
- En los SELECT complejos, expande primero la jerarquía con una sangría estable; en los scripts de migración sencillos puedes dejar menos líneas en blanco entre sentencias.
- Los procedimientos almacenados, los CTE largos y las subconsultas de varios niveles van bien con sangría de 4 espacios, que deja ver el anidamiento.
- Al depurar un ORM, expande primero el SQL a varias líneas con la herramienta y luego decide si conviene añadir un índice, cambiar el orden de los JOIN o reescribir una subconsulta.
- Cuando necesites incrustarlo en código, registros o CLI, usa la versión comprimida para reducir los saltos de línea; si los literales de cadena del SQL dependen de espacios consecutivos, revisa antes el resultado comprimido.
- En los scripts de migración puedes conservar líneas en blanco entre sentencias para dar un respiro visual a cada DDL / DML y facilitar la revisión por bloques.
- Anonimiza el SQL de producción antes de tratarlo. La herramienta no sube datos, pero lo que copias fuera puede acabar en tickets, chats, documentos o capturas.
Limitaciones
Esta herramienta se encarga de la maquetación, la sangría y el estilo de palabras clave del SQL, y no sustituye a un analizador de consultas, un lint de SQL, una herramienta de migración ni un motor de ejecución.
- No valida si los nombres de tablas, de campos, los tipos o los permisos existen de verdad; eso sigue necesitando la propia base de datos, las herramientas de un DBA o la capacidad de validación de un ORM.
- No reescribe la semántica de la consulta. Reordenar los JOIN, fusionar subconsultas, añadir o quitar campos, crear índices o cambiar la sintaxis de dialecto debe hacerlo un experto en bases de datos o una herramienta de refactorización.
- No es un lint de SQL. Para reglas complejas, convenciones de nombres y detección de antipatrones usa herramientas específicas como sqlfluff, SonarQube o pgFormatter.
- No se conecta a ninguna base de datos ni ejecuta SQL. Aunque pegues un DROP o un DELETE, solo formatea el texto.
- No traduce automáticamente las diferencias de dialecto entre MySQL y PostgreSQL, como los nombres de función, las comillas o la sintaxis de limit/offset. La elección de dialecto solo afecta al reconocimiento de palabras clave durante el formateo.
- Todo se procesa en local, pero la seguridad local sigue dependiendo de tu dispositivo, tus extensiones de navegador, lo que compartes en pantalla y el destino de lo que copias.
Preguntas frecuentes
Aquí se recogen preguntas frecuentes sobre dialectos, mayúsculas, sangría, compresión, localización de errores y privacidad.
¿Se sube mi SQL a un servidor?
No. El análisis, el formateo, la compresión, la lectura de archivos subidos, la copia y la descarga ocurren dentro de la pestaña del navegador. DevKitLab no envía tus consultas ni tu estructura de tablas a un servidor.
¿Qué dialectos de SQL admite?
Admite MySQL, PostgreSQL, SQLite, MariaDB, TiDB, BigQuery, Snowflake, Redshift, Oracle PL/SQL, SQL Server (Transact-SQL), Spark, Trino, Hive, ClickHouse, DuckDB, Couchbase N1QL, IBM Db2 y SQL genérico, más de una decena en total.
¿Qué pasa si elijo mal el dialecto?
El dialecto afecta sobre todo a qué palabras se reconocen como clave y al estilo de cadenas y comillas. En general no vuelve el SQL ilegible, pero algunas sintaxis propias de un dialecto (como los acentos graves de BigQuery o las cadenas dollar-quoted de Postgres) pueden formatearse peor con el dialecto equivocado, así que conviene elegir el de tu base de datos real.
¿Por qué no se ponen mis palabras clave en mayúsculas automáticamente?
La política de mayúsculas por defecto es mantener el original, así que la herramienta no las reescribe. Cambia la política de palabras clave a mayúsculas o minúsculas y vuelve a hacer clic en «Formatear» para ver el efecto.
¿Modifica mis literales de cadena?
El modo de formateo solo ajusta espacios, saltos de línea y mayúsculas de palabras clave, y no reescribe las cadenas entre comillas, los comentarios ni los marcadores de parámetros. El modo compacto comprime aún más los espacios, así que revisa el resultado si tratas cadenas que dependen de espacios consecutivos.
¿Qué hace el modo compacto?
Al «Copiar comprimido» se aplasta el SQL de varias líneas en una sola y se eliminan los espacios sobrantes. Va bien para las llamadas de ORM habituales, los campos de registro, la línea de comandos o las interfaces que solo admiten consultas de una línea; si los literales de cadena de la consulta dependen de espacios consecutivos, usa la versión formateada o confirma antes el resultado comprimido.
¿Un error de análisis significa que mi SQL está mal?
Normalmente significa que el analizador de la herramienta encontró un token que no reconoce, por ejemplo un dialecto que no coincide, paréntesis sin cerrar o alguna sintaxis de extensión poco habitual. No equivale a un error de ejecución de la base de datos; puedes cambiar de dialecto, corregir la sintaxis y volver a intentarlo.
¿Puede tratar procedimientos almacenados de PL/SQL o T-SQL?
Puede tratar la mayoría de los cuerpos de sentencias habituales de PL/SQL y T-SQL, pero sql-formatter no admite la semántica completa de los procedimientos almacenados. Para procedimientos complejos conviene usar el IDE propio de la base de datos o una herramienta específica.
¿Puedo ejecutar SQL o conectarme a una base de datos aquí?
No. Esta herramienta solo maqueta el texto del SQL; no se conecta a ninguna base de datos ni envía o ejecuta consultas.
¿Puede tratar archivos SQL muy grandes?
Los scripts de unos cientos de KB a unos pocos MB no suelen dar problema; los archivos de migración muy grandes (decenas de MB o con muchos INSERT) pueden ralentizar el navegador, así que conviene dividirlos en sentencias sueltas o procesarlos por lotes.
Herramientas relacionadas
Puedes seguir con los flujos de consulta y datos en el conjunto de herramientas de datos: ordenar el JSON devuelto, ver datos en tabla o cambiar rápido entre varias herramientas.