Base64, encodage URL et JWT sont partout en développement et en administration système, et pourtant souvent mal compris — notamment la confusion fréquente entre "encodé" et "chiffré". Ce guide remet les bases au clair.
Le Base64 convertit des données binaires en une chaîne de caractères composée uniquement de lettres, chiffres et trois symboles (+, /, =), garantissant qu'elles peuvent être transportées sans problème dans des contextes qui n'acceptent que du texte simple : emails, JSON, URLs, fichiers de configuration XML/YAML.
Exemples d'usages courants :
data URI.Le Base64 augmente la taille des données d'environ 33% (3 octets binaires deviennent 4 caractères texte), c'est le compromis accepté en échange de la compatibilité universelle avec le texte.
Le Base64 n'est pas un mécanisme de sécurité. N'importe qui peut décoder du Base64 instantanément, sans clé, sans mot de passe — y compris avec l'outil de cette page. Ne jamais l'utiliser pour "cacher" une information sensible.
C'est une confusion fréquente chez les débutants : voir une chaîne illisible en Base64 (eyJhbGciOiJIUzI1NiJ9...) donne l'impression d'un contenu protégé, alors qu'il s'agit d'une simple transformation réversible sans aucune clé secrète. Le chiffrement (AES, RSA...) nécessite une clé pour être déchiffré ; l'encodage ne nécessite qu'une formule connue de tous.
Une URL ne peut contenir qu'un sous-ensemble restreint de caractères. L'encodage URL (aussi appelé percent-encoding) remplace tout caractère non autorisé par son code, précédé d'un % — par exemple un espace devient %20, un & devient %26.
C'est indispensable dès qu'une URL contient des données variables (paramètres de recherche, caractères accentués, symboles spéciaux) qui pourraient sinon être interprétées comme faisant partie de la structure de l'URL elle-même et casser son fonctionnement.
| Caractère | Encodage URL |
|---|---|
| Espace | %20 (ou + dans certains contextes) |
| & | %26 |
| ? | %3F |
| = | %3D |
| é | %C3%A9 (encodage UTF-8) |
Un JWT est un format standardisé pour transmettre des informations d'authentification ou de session de façon compacte et auto-portée (elle ne nécessite pas d'aller consulter une base de données pour être interprétée). Un JWT est constitué de trois parties séparées par des points :
HS256, RS256) et le type de token.Le header et le payload sont encodés en Base64URL (une variante du Base64 sans caractères +// problématiques dans une URL) — c'est pour cela qu'un outil comme celui de cette page peut les décoder et les afficher instantanément, sans connaître aucun secret.
La signature d'un JWT prouve que son contenu provient bien du serveur qui détient la clé secrète (ou privée) correspondante, et qu'il n'a pas été modifié depuis. Mais cette garantie n'existe que si la signature est effectivement vérifiée par celui qui reçoit le token.
Décoder un JWT (comme le fait cet outil) ne vérifie pas sa signature. N'importe qui peut décoder le contenu d'un JWT, et même en fabriquer un de toutes pièces avec n'importe quel contenu. Seule la vérification cryptographique de la signature, côté serveur, avec la bonne clé, permet de faire confiance à son contenu.
C'est pourquoi cet outil affiche systématiquement un avertissement : il est conçu pour inspecter et comprendre un token (déboguer une intégration, vérifier une date d'expiration), pas pour valider son authenticité.
Utiliser l'outil Base64 / URL / JWT →+ et / ne sont pas valides dans une URL, d'où la variante Base64URL (qui utilise - et _ à la place) utilisée notamment par les JWT.On peut modifier le contenu décodé librement, mais la signature ne correspondra alors plus aux nouvelles données — un serveur qui vérifie correctement la signature rejettera immédiatement ce token falsifié.
Non, c'est l'inverse : le Base64 augmente la taille des données d'environ 33%. Ce n'est pas un mécanisme de compression, seulement de représentation textuelle de données binaires.
Chaque caractère non autorisé directement dans une URL est remplacé par son équivalent percent-encoded. Plus le texte contient de caractères spéciaux ou accentués, plus l'encodage paraît dense.
Le champ exp du payload indique une date d'expiration prévue, mais c'est au serveur qui vérifie le token de refuser activement les tokens expirés — le JWT lui-même ne "s'autodétruit" pas, il reste techniquement décodable même après expiration.