La indentación es la característica visual clave que diferencia un JSON legible de uno ilegible.
Loading JSON Formatter…
Procesamiento rápido en el navegador
Los archivos nunca salen de tu dispositivo
Gratis sin límites de uso
Coloca JSON Formatter en cualquier página —entrada de blog, documentación de producto, intranet, portal escolar— con una sola línea de HTML. Tus visitantes obtienen la herramienta completa, procesada íntegramente en su navegador. Sin backend, sin subidas, sin registro.
Código de inserción
<iframe
src="https://www.fixtools.io/json/json-formatter?embed=1&lang=es"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="JSON Formatter by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Atribución amable: aparece un pequeño enlace "Powered by FixTools" en el pie del embed.
La elección del nivel de indentación tiene impacto en varios aspectos del trabajo técnico. Dos espacios es la convención más extendida en el mundo JavaScript y Node.js, recogida en las guías de estilo de Airbnb, Google y la propia Standard JS. Cuatro espacios es habitual en Python siguiendo PEP 8, y muchos equipos heredan esa convención para los archivos JSON cuando trabajan principalmente en ese ecosistema. Las tabulaciones tienen partidarios y detractores históricos en la industria, ofrecen flexibilidad porque cada desarrollador puede configurar el ancho de tabulación en su editor, pero pueden generar inconsistencias visuales en sistemas que renderizan con anchos distintos como GitHub o GitLab durante las revisiones de pull request.
Las convenciones del repositorio deben prevalecer sobre las preferencias individuales. Cuando un repositorio establece una convención de indentación en su guía interna o en un archivo .editorconfig, todos los miembros del equipo deben respetarla al editar archivos JSON. Esta disciplina evita diffs ruidosos en las revisiones de código y facilita la lectura cruzada entre miembros del equipo. FixTools permite elegir la indentación al formatear, lo que evita tener que reformatear de nuevo el contenido en el editor local. Para repositorios que mezclan archivos en distintas indentaciones por motivos históricos, considera migrar gradualmente a una única convención durante revisiones planificadas que no compitan con tareas urgentes del producto.
El impacto de la indentación en las herramientas de diff es notable. Un diff entre dos versiones de un archivo JSON resulta mucho más legible cuando los cambios reales destacan sobre un fondo de indentación coherente. Si una persona del equipo formatea con dos espacios y otra con cuatro, los diffs muestran cambios masivos en cada línea aunque el contenido real apenas haya variado, lo que dificulta la revisión y aumenta el riesgo de aprobar cambios sin entenderlos completamente. Mantener una convención única elimina este ruido. Las plataformas de revisión como GitHub permiten configurar opciones para ignorar diferencias de espacio en blanco, pero la solución estructural es acordar y respetar una convención común desde el inicio del proyecto.
La compatibilidad con generadores automáticos de JSON es otra consideración. Algunos sistemas generan JSON con indentación específica que puede no coincidir con la convención del repositorio. Cuando importas estos archivos al repositorio, conviene reformatearlos para alinearlos con la convención local antes de hacer commit. FixTools facilita esta operación al permitir elegir la indentación de salida independientemente de la del archivo original. Esta práctica de normalización en el momento de importar es estándar en equipos maduros de DevOps que mantienen una calidad alta en los archivos versionados del repositorio compartido entre varios servicios.
Guía paso a paso para formatear json con indentación:
Identifica la convención de tu repositorio
Antes de formatear, revisa la convención de indentación que utiliza tu repositorio. Consulta el archivo .editorconfig si existe, la guía interna de desarrollo o los archivos JSON existentes en el proyecto para inferir la convención dominante. Si el repositorio no tiene una convención documentada, considera proponer una al equipo y documentarla antes de continuar. Una decisión consensuada evita conflictos posteriores cuando varios desarrolladores trabajen sobre los mismos archivos durante las próximas iteraciones del producto.
Copia el JSON desde la fuente
Localiza el JSON que vas a formatear y cópialo al portapapeles. Puede provenir de la consola del navegador, de la salida de una herramienta de prueba de API como Postman o Insomnia, de un archivo del repositorio o de un log estructurado. Selecciona el contenido completo con cuidado para no cortarlo a la mitad. Una copia incompleta genera errores de sintaxis al formatear y obliga a repetir la operación desde el principio del flujo de trabajo del usuario.
Abre FixTools y pega el contenido
Entra en fixtools.io y selecciona la herramienta de formatear JSON. Verifica que la conexión es HTTPS revisando el candado en la barra de direcciones. Pega el JSON en el campo de entrada con Ctrl+V o Cmd+V. La interfaz aparece preparada sin pasos de registro, lo que protege la confidencialidad cuando trabajas con payloads que contienen información personal sujeta al RGPD o datos comerciales sensibles propios de la organización.
Selecciona la indentación adecuada
Elige el nivel de indentación que coincida con la convención del repositorio. Dos espacios es habitual en proyectos JavaScript y Node.js. Cuatro espacios en proyectos Python siguiendo PEP 8. Tabulaciones en algunos proyectos antiguos o en infraestructura como código que prefiere la flexibilidad visual de cada editor. Mantener la convención del repositorio reduce diffs ruidosos y facilita las revisiones de pull request del equipo cuando varios miembros tocan los mismos archivos durante un sprint.
Formatea, copia y aplica en el repositorio
Pulsa el botón principal para formatear con la indentación elegida. Revisa el resultado para confirmar que la estructura coincide con la esperada. Copia el contenido al portapapeles y pégalo en el archivo del repositorio, sustituyendo la versión anterior. Si el archivo está bajo control de versiones, revisa el diff con Git antes de hacer commit para confirmar que los cambios son los esperados y que no se han introducido modificaciones accidentales en otras partes del contenido.
Situaciones comunes donde este enfoque marca la diferencia:
Equipo de Mercadona normalizando configuración
Un equipo de plataforma de Mercadona en Valencia mantiene una colección de archivos JSON con configuración de los sistemas internos de logística. Los archivos provienen de varios proveedores con convenciones de indentación distintas, lo que generaba diffs ruidosos en las revisiones. El equipo decide normalizar todos los archivos a dos espacios al importarlos al repositorio corporativo. FixTools permite reformatear cada archivo con la indentación común antes de hacer commit. El procesamiento local protege la información de configuración interna durante la normalización, sin exposición a servicios web externos. La coherencia resultante facilita las revisiones y reduce el riesgo de aprobar cambios sin entenderlos.
Desarrollador en Telefónica revisando archivos de microservicios
Un desarrollador del equipo de microservicios de Telefónica en Madrid revisa un pull request que modifica varios archivos JSON de configuración. Los archivos originales utilizaban cuatro espacios pero el autor del pull request los ha pegado con dos espacios, lo que genera un diff masivo y dificulta la revisión. El desarrollador reformatea los archivos con cuatro espacios usando FixTools y pide al autor que aplique esa convención. La solicitud queda documentada en el comentario del pull request como referencia para futuros cambios, y el flujo de revisión de pull request se acelera durante las siguientes iteraciones del proyecto.
Ingeniera en BBVA preparando un archivo de configuración
Una ingeniera del equipo de pagos de BBVA en Madrid prepara un nuevo archivo de configuración para un servicio interno de validación de tarjetas. El archivo se genera inicialmente con cuatro espacios desde una herramienta de exportación, pero el repositorio del equipo utiliza dos espacios como convención. La ingeniera reformatea el archivo con FixTools antes de añadirlo al repositorio, lo que evita un commit inicial con la indentación incorrecta y la necesidad de un commit posterior para corregirla. El procesamiento local de la herramienta protege la información de configuración del servicio durante la normalización del archivo.
Obtén mejores resultados con estas sugerencias de expertos:
Adopta dos espacios como convención por defecto
Si tu equipo no tiene una convención documentada, considera adoptar dos espacios como convención por defecto. Esta opción es la más extendida en el ecosistema web moderno, ocupa menos ancho horizontal en pantalla y facilita la lectura en monitores con ventanas divididas o en revisiones de pull request donde el espacio horizontal es limitado. La convención de dos espacios se utiliza por defecto en herramientas como Prettier, lo que la convierte en una elección segura para proyectos que pueden incorporar formateadores automáticos en el futuro como parte del flujo de calidad del repositorio.
Configura .editorconfig en el repositorio
Añade un archivo .editorconfig en la raíz del repositorio con las convenciones de indentación que utiliza el proyecto. Los editores modernos como VSCode, IntelliJ y Sublime respetan automáticamente esta configuración al editar archivos. La presencia del archivo en el repositorio elimina la necesidad de que cada desarrollador configure manualmente su editor para cada proyecto, lo que reduce errores de formato y facilita la incorporación de nuevos miembros al equipo. Esta práctica es estándar en repositorios maduros mantenidos por equipos profesionales de las principales empresas tecnológicas.
Incluye reglas de formato en el linter del proyecto
Configura el linter del proyecto para verificar la indentación de los archivos JSON durante el proceso de integración continua. Herramientas como Prettier, ESLint o JSONLint detectan archivos con indentación incorrecta y fallan el build si encuentran inconsistencias. Esta verificación automática evita que archivos mal formateados lleguen a la rama principal del repositorio y mantiene la coherencia a largo plazo, sin depender exclusivamente de la disciplina manual de cada miembro del equipo durante las revisiones de pull request del proyecto.
Other tools you might find useful:
Abre el JSON Formatter completo — gratis, sin cuenta, funciona en cualquier dispositivo.
Abrir JSON Formatter →Gratis · Sin cuenta · Funciona en cualquier dispositivo