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

Qué cambia 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) devuelve esos espacios con un patrón consistente, normalmente 2 o 4 espacios por nivel de anidamiento, para que veas 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 en el mismo objeto en memoria. Los 48 bytes extra de la versión embellecida sirven a la legibilidad humana y no llevan información semántica.

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, como una lista paginada de cientos de registros, la minificación puede recortar un 15-25 % del tamaño de transferencia antes de que entre la compresión.

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, minificar mantiene cada registro en una sola línea, y herramientas como grep, jq -c y los log shippers basados en líneas dependen de eso.

Una advertencia: si ya sirves las respuestas 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, porque los espacios en blanco repetidos comprimen muy bien. Minifica para los casos sin comprimir (configs embebidas, logs), donde más ayuda.

Cuándo el embellecido es la decisión correcta

Cualquier cosa que vaya a leer una persona: 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 aparece en un diff de git como una sola línea cambiada, por pequeño que sea el cambio, mientras que el JSON embellecido te da un diff limpio por líneas para revisar.

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

JSON.parse() ignora la indentación, así que la elección no tiene efecto funcional. 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 muy anidados se salgan de la pantalla. 4 espacios aparece más en herramientas cercanas a Python. Los tabuladores son raros en JSON porque editores y visores de diff los muestran de forma inconsistente. Elige uno y mantenlo en todo el proyecto, porque la indentación mezclada produce diffs ruidosos.