Minificar JSON frente a embellecerlo: cuándo usar cada cosa

Qué cambia realmente entre ambos

La minificación elimina cada byte que no cambia el significado: espacios tras los dos puntos y las comas, saltos de línea e indentación. El embellecido (también llamado beautify) añade esos espacios en blanco de vuelta con un patrón consistente — normalmente 2 o 4 espacios por nivel de anidamiento — para que un humano vea la estructura de un vistazo.

// Minified (48 bytes)
{"user":{"id":7,"active":true,"tags":["a","b"]}}

// Prettified (2-space indent, 96 bytes)
{
  "user": {
    "id": 7,
    "active": true,
    "tags": ["a", "b"]
  }
}

Ambos se analizan exactamente en el mismo objeto en memoria. Los 48 bytes extra de la versión embellecida existen puramente para la legibilidad humana — no portan información semántica alguna.

Cuándo la minificación es la decisión correcta

Respuestas y peticiones de API: cada byte que eliminas es un byte que el cliente no descarga. En una carga útil grande — una lista paginada de cientos de registros — la minificación puede recortar un 15-25 % del tamaño de transferencia antes incluso de que la compresión entre en juego.

Configuración embebida en HTML o bundles JS: un blob JSON minificado incrustado en una etiqueta <script> no infla tu bundle con formato que ningún navegador necesita.

Líneas de log y almacenamiento: si escribes JSON en un archivo de log o una columna de base de datos a un registro por línea, el formato minificado mantiene cada registro en una sola línea — lo cual importa para herramientas como grep, jq -c y los log shippers basados en líneas.

Una advertencia: si tus respuestas ya se sirven con compresión gzip o brotli (la mayoría de las APIs lo hacen), el ahorro de bytes de la minificación se reduce mucho — los espacios en blanco repetidos comprimen extremadamente bien. Minifica para el caso sin comprimir (configs embebidas, logs), donde más importa.

Cuándo el embellecido es la decisión correcta

Cualquier cosa que un humano vaya a leer: ejemplos de documentación de APIs, archivos de configuración que los desarrolladores editan a mano (package.json, tsconfig.json), salida de depuración y diffs de revisión de código. Un blob JSON minificado en una línea se muestra en un diff de git como una sola línea cambiada por muy pequeño que sea el cambio real — el JSON embellecido muestra un diff limpio y revisable a nivel de línea.

Configuración bajo control de versiones: indentación de 2 o 4 espacios con una clave por línea significa que git puede mostrar exactamente qué clave cambió, en lugar de marcar el blob entero como modificado.

2 espacios frente a 4 espacios frente a tabuladores

No hay diferencia funcional — JSON.parse() lo ignora por completo. 2 espacios es la convención más común en los ecosistemas JavaScript/TypeScript (npm, la mayoría de guías de estilo JS) y evita que los objetos profundamente anidados se salgan de la pantalla. 4 espacios es más común en herramientas cercanas a Python. Los tabuladores son raros para JSON en concreto porque se renderizan de forma inconsistente entre editores y visores de diff. Elige uno y mantente consistente dentro de un proyecto — la indentación mezclada en JSON es una fuente común de diffs ruidosos.