JSON : Base64

Convertissez vos données JSON en Base64 et inversement.

JSON

Conversion

Options

Validation

Base64

Guide complet JSON vers Base64 : encoder pour transporter

Pourquoi je convertis du JSON en Base64

Dans mon travail quotidien avec les APIs et les systèmes d'intégration, je convertis fréquemment du JSON en Base64. Cette transformation permet de transmettre des données structurées complexes dans des contextes qui n'acceptent que du texte ASCII simple : paramètres URL sans échappement problématique, headers HTTP, payloads JWT, variables d'environnement, champs de base de données texte, ou même dans du XML ou YAML sans problème d'échappement de caractères spéciaux.

Comprendre l'encodage Base64

Base64 transforme des données binaires (ou texte) en une chaîne composée uniquement de 64 caractères ASCII imprimables : A-Z, a-z, 0-9, + et /. Le = sert de padding pour aligner sur des multiples de 4 caractères. L'algorithme encode chaque groupe de 3 octets (24 bits) en 4 caractères (6 bits chacun), ce qui explique l'augmentation de taille d'environ 33%.

Cas d'usage concrets

🔐 Tokens JWT (JSON Web Tokens)

Le payload d'un JWT est du JSON encodé en Base64URL. Comprendre cette conversion est essentiel pour déboguer les problèmes d'authentification et vérifier le contenu des tokens.

🔗 État dans les URLs (state parameter)

Passer un état complexe (filtres, configuration) via query string. Le JSON encodé en Base64URL évite tous les problèmes d'échappement des {, }, ", :.

⚙️ Configuration inline

Intégrer des configurations JSON dans des fichiers YAML, des variables d'environnement, ou des scripts shell sans se soucier de l'échappement.

📡 APIs et webhooks

Certaines APIs legacy ou webhooks n'acceptent que des chaînes simples. Encoder le JSON en Base64 préserve toute la structure pour le décodage côté récepteur.

Comment utiliser cet outil

  1. Entrez votre JSON — Dans l'éditeur de gauche, formaté ou minifié
  2. Choisissez le format — Activez « Base64 URL-safe » pour JWT et URLs
  3. Cliquez JSON → Base64 — La conversion est instantanée
  4. Copiez le résultat — Prêt à être utilisé dans votre application
  5. Conversion inverse — Base64 → JSON pour décoder

Base64 standard vs Base64URL

  • Base64 standard — Utilise + et / qui ont des significations spéciales dans les URLs. Le = de padding peut aussi poser problème
  • Base64URL (RFC 4648) — Remplace + par -, / par _, et omet le padding =. 100% compatible avec les URLs
  • JWT utilise Base64URL — C'est pourquoi les tokens JWT contiennent - et _ au lieu de + et /
  • Interopérabilité — Notre outil détection automatiquement les deux formats en décodage

Questions fréquentes

Le JSON encodé en Base64 est-il chiffré ou protégé ?

Non, absolument pas ! Base64 est un encodage, pas un chiffrement. C'est une transformation réversible triviale que n'importe qui peut décoder instantanément avec n'importe quel outil en ligne.

Erreurs courantes à éviter :

  • Ne stockez JAMAIS de mots de passe en Base64 en pensant qu'ils sont protégés
  • Ne mettez pas de clés API dans des JWT non chiffrés (seuls les JWT JWE sont chiffrés)
  • Le payload d'un JWT standard est lisible par tous — il est signé, pas chiffré

Pour la confidentialité, utilisez un vrai chiffrement (AES-256-GCM, etc.) AVANT l'encodage Base64.

Pourquoi le Base64 est-il environ 33% plus long que l'original ?

C'est une conséquence mathématique de l'algorithme :

  • Base64 utilise 64 caractères (2^6), donc chaque caractère représente 6 bits
  • L'encodage groupe 3 octets (24 bits) et les représente en 4 caractères (4×6 = 24 bits)
  • Ratio : 4 caractères sortie / 3 octets entrée = augmentation de 33%

Pour les données volumineuses, considérez la compression (gzip, LZ-string) AVANT l'encodage Base64 — vous pouvez souvent obtenir un résultat plus petit que l'original.

Puis-je utiliser ce Base64 comme payload dans un JWT ?

Presque — quelques nuances importantes :

  • Format — JWT utilise Base64URL (pas Base64 standard). Activez l'option « Base64 URL-safe »
  • Structure JWT — Un JWT complet = header.payload.signature. L'encodage du payload seul ne suffit pas
  • Signature — Sans signature valide (HMAC ou RSA), le JWT sera rejeté par tout système sérieux

Cet outil est parfait pour déboguer et comprendre le contenu d'un payload JWT, mais pas pour créer des JWT valides (utilisez une bibliothèque comme jsonwebtoken).

L'encodage préserve-t-il tous les types JSON (nombres, booléens, null) ?

Oui, parfaitement ! Le processus en deux étapes garantit l'intégrité :

  1. Le JSON est sérialisé en texte UTF-8 (JSON.stringify) — tous les types sont représentés textuellement
  2. Ce texte est encodé en Base64 — transformation bijective sans perte

Au décodage, JSON.parse() reconstruit les types originaux : nombres (pas de guillemets), booléens (true/false), null, tableaux, objets imbriqués. Rien n'est perdu.

Comment gérer les caractères Unicode (accents, emojis, chinois) ?

Cet outil gère correctement UTF-8 grâce à une technique spécifique :

  • Encodage — Le JSON est d'abord encodé en UTF-8 (encodeURIComponent), puis converti en Base64
  • Décodage — Le Base64 est décodé, puis les séquences UTF-8 sont reconstituées (decodeURIComponent)

Les accents (é, è, à), caractères asiatiques (中文), et emojis (😀) sont tous préservés. C'est plus robuste que le btoa() natif qui échoue sur les caractères non-ASCII.

Quelle est la différence exacte entre Base64 et Base64URL ?

Trois différences techniques définies par RFC 4648 :

  • + devient - (le + a une signification spéciale dans les URLs : espace)
  • / devient _ (le / est un séparateur de chemin)
  • = padding est omis (le = doit être percent-encodé en %3D dans les URLs)

Résultat : Base64URL peut être inséré directement dans une URL sans encodage supplémentaire. C'est pourquoi JWT l'utilise — les tokens sont souvent transmis dans des headers ou des query strings.

Puis-je compresser mon JSON avant de l'encoder en Base64 ?

Oui, et c'est souvent une excellente idée pour les gros JSON :

  • LZ-string — Bibliothèque JS légère, produit directement du Base64 compressé, réduction de 50-80%
  • pako (zlib) — Compression gzip en JS, plus efficace mais produit du binaire à encoder ensuite
  • Ordre — Toujours : JSON → compression → Base64 (pas l'inverse !)

Attention : le récepteur doit savoir que les données sont compressées et avoir la même bibliothèque pour décompresser.

Mes données sont-elles transmises à un serveur lors de la conversion ?

Non, tout reste local :

  • La conversion est effectuée en JavaScript dans votre navigateur
  • Aucune requête réseau n'est émise (vérifiable dans les DevTools)
  • Vos données ne quittent jamais votre machine
  • L'outil fonctionne même hors ligne une fois la page chargée

C'est particulièrement important quand vous travaillez avec des données sensibles (configs, tokens à déboguer).