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 veinte dialectos, entre ellos MySQL, PostgreSQL, SQLite, BigQuery, Snowflake, Redshift, Oracle PL/SQL y SQL Server; 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.
- Veinte 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, el espaciado 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 veinte dialectos: MySQL, MariaDB, TiDB, SingleStore, PostgreSQL, Redshift, SQLite, DuckDB, BigQuery, Snowflake, Oracle PL/SQL, SQL Server (Transact-SQL), Spark, Trino, Hive, ClickHouse, Couchbase N1QL, IBM Db2, IBM Db2 for i y el SQL estándar genérico.
- 02
Mayúsculas de palabras clave, funciones y tipos
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. Los nombres de tablas y columnas se dejan tal cual, porque algunas bases de datos tratan su caja como información significativa.
- 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
Espaciado de operadores y punto y coma
Con los operadores compactos desaparecen los espacios alrededor de los operadores aritméticos y de comparación, y el punto y coma puede ocupar su propia línea para que el final de cada sentencia se vea de inmediato. Entre un menos y un valor negativo siempre queda un espacio, porque si no el par se leería como el principio de un comentario.
- 06
Modo compacto
Al copiar comprimido, la sentencia queda en una sola línea, lista para llamadas de ORM, campos de registro o la línea de comandos. Los literales de cadena y los identificadores entre comillas se copian carácter a carácter, y un comentario de línea pasa a comentario de bloque para que no se trague el resto de la consulta.
- 07
Localización de errores
Cuando el análisis falla, la barra de estado muestra la línea y la columna con la descripción del error, y al pulsarla el cursor salta hasta ahí, para localizar un paréntesis olvidado, un token de más o una sintaxis que el dialecto actual no reconoce.
- 08
Subida y descarga de archivos
Arrastra un archivo .sql o .txt sobre el editor, o elígelo con «Subir archivo», y descarga como archivo .sql lo que el editor tenga en ese momento, cómodo para trabajar con herramientas de migración o flujos de control de versiones.
- 09
Ajustes que sobreviven a una recarga
El dialecto, la caja, la sangría y las opciones de visualización que elijas se guardan en este navegador junto con la sentencia del editor, así que volver a la página no obliga a configurarlo todo otra vez.
- 10
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 arrastrar un .sql local sobre el editor o elegirlo con «Subir archivo».
- 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: la barra de estado se actualiza sola, y «Formatear», o Shift+Alt+F, vuelve a aplicar 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.
- Veinte dialectos, cada uno formateado con su propio conjunto de palabras clave, de MySQL y PostgreSQL a BigQuery, Snowflake, Trino e IBM Db2.
- 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, que deja intactos los literales de cadena y los comentarios.
- 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 arrastrar o 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 como archivo .sql lo que haya en el editor, formateado o comprimido, cómodo para subirlo al repositorio o entregarlo a una herramienta de base de datos.
- El dialecto y las opciones de formateo que elijas se recuerdan en este navegador entre visitas.
- 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 el JSON que aparece en los 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 en lugar de quitar los saltos de línea a mano, que es justo donde se suelen perder los espacios de dentro de los literales.
- 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.
- El contenido del editor se guarda en este navegador para restaurarlo al recargar. En un equipo compartido o público, pulsa «Limpiar» al terminar.
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?
Veinte en total: MySQL, MariaDB, TiDB, SingleStore, PostgreSQL, Redshift, SQLite, DuckDB, BigQuery, Snowflake, Oracle PL/SQL, SQL Server (Transact-SQL), Spark, Trino, Hive, ClickHouse, Couchbase N1QL, IBM Db2, IBM Db2 for i y el SQL estándar genérico.
¿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 «Palabras clave» a mayúsculas o minúsculas y el editor se reformatea al instante, de modo que puedes ir y volver sin perder el texto original.
¿Modifica mis literales de cadena?
No. Tanto el formateo como la compresión solo tocan los espacios entre tokens y la caja de palabras clave, funciones y tipos de datos. Las cadenas entre comillas, los identificadores entrecomillados y los marcadores de parámetros se copian sin cambios, incluidos los espacios que lleven dentro. Los comentarios también se conservan; la única reescritura es que la versión comprimida convierte un comentario de línea en uno de bloque para que no se trague el resto de la consulta.
¿Qué hace el modo compacto?
Deja la sentencia en una sola línea y quita los espacios entre tokens, lo que va bien para las llamadas de ORM, los campos de registro, la línea de comandos o las interfaces que solo admiten consultas de una línea. El texto entrecomillado nunca se toca, y un comentario de línea pasa a comentario de bloque para que el resto de la consulta quede fuera de él. Si un literal contiene un salto de línea de verdad, ese salto se conserva y el resultado ocupa más de una línea.
¿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 dan problema. La subida de archivos se corta en 5 MB, porque leer y formatear más que eso bloquea la pestaña durante mucho rato; incluso por debajo del límite, unos cuantos MB de INSERT masivos se notan lentos. Divide antes las migraciones grandes en scripts más pequeños.
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.