Minification ou mise en forme du JSON : quand utiliser chaque

Ce qui change réellement entre les deux

La minification supprime chaque octet qui ne change pas le sens : les espaces après les deux-points et les virgules, les sauts de ligne et l'indentation. La mise en forme (aussi appelée embellissement) réajoute ces espaces blancs selon un motif cohérent — généralement 2 ou 4 espaces par niveau d'imbrication — pour qu'un humain puisse voir la structure d'un coup d'œil.

// 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"]
  }
}

Les deux s'analysent en exactement le même objet en mémoire. Les 48 octets supplémentaires de la version mise en forme n'existent que pour la lisibilité humaine — ils ne portent aucune information sémantique.

Quand la minification est le bon choix

Réponses et requêtes d'API : chaque octet supprimé est un octet que le client ne télécharge pas. Sur une grosse charge utile — une liste paginée de centaines d'enregistrements — la minification peut retirer 15 à 25 % de la taille transférée avant même que la compression n'intervienne.

Configuration intégrée dans des bundles HTML ou JS : un blob JSON minifié inséré dans une balise <script> n'alourdit pas votre bundle d'un formatage dont aucun navigateur n'a besoin.

Lignes de journal et stockage : si vous écrivez du JSON dans un fichier de journal ou une colonne de base, un enregistrement par ligne, la forme minifiée garde chaque enregistrement sur une seule ligne — ce qui compte pour des outils comme grep, jq -c et les expéditeurs de journaux basés lignes.

Une réserve : si vos réponses sont déjà servies avec compression gzip ou brotli (c'est le cas de la plupart des API), l'économie d'octets de la minification rétrécit beaucoup — les espaces répétés se compressent extrêmement bien. Minifiez pour le cas non compressé (configurations intégrées, journaux), là où c'est le plus utile.

Quand la mise en forme est le bon choix

Tout ce qu'un humain lira : exemples de documentation d'API, fichiers de configuration édités à la main par des développeurs (package.json, tsconfig.json), sortie de débogage et diffs de revue de code. Un blob JSON minifié sur une ligne apparaît dans un diff git comme une seule ligne modifiée, quelle que soit la petitesse du changement réel — le JSON mis en forme montre un diff propre, ligne par ligne et révisable.

Configuration versionnée : une indentation de 2 ou 4 espaces avec une clé par ligne permet à git de montrer exactement quelle clé a changé, au lieu de marquer tout le blob comme modifié.

2 espaces, 4 espaces ou tabulations

Il n'y a aucune différence fonctionnelle — JSON.parse() les ignore totalement. 2 espaces est la convention la plus courante dans les écosystèmes JavaScript/TypeScript (npm, la plupart des guides de style JS) et empêche les objets profondément imbriqués de déborder de l'écran. 4 espaces est plus courant dans les outils proches de Python. Les tabulations sont rares pour JSON précisément parce qu'elles s'affichent de façon incohérente selon les éditeurs et les visionneuses de diff. Choisissez-en une et restez cohérent au sein d'un projet — l'indentation mixte en JSON est une source courante de diffs bruyants.