Encodez ou décodez les deux variantes localement avec l'encodeur multi-format.
Ce qu'est réellement Base64
Base64 transforme des données binaires en ASCII avec 64 caractères : A–Z, a–z, 0–9, plus + et /. Un = final sert de rembourrage pour que la longueur de sortie reste un multiple de 4.
C'est un encodage, pas un chiffrement. N'importe qui peut décoder du Base64 sans clé. Son rôle est de transporter des données binaires par des canaux texte uniquement comme l'e-mail, le JSON ou les URL.
Trois octets d'entrée deviennent quatre caractères de sortie : 24 bits se divisent en quatre groupes de 6 bits qui choisissent chacun l'un des 64 caractères de l'alphabet. La sortie est donc environ un tiers plus longue.
Dans le navigateur, btoa() et atob() n'acceptent que des chaînes Latin-1 : les emojis ou autres textes UTF-8 déclenchent une erreur ou produisent du texte illisible.
Pourquoi les URL cassent le Base64 standard
Les 62e et 63e caractères de l'alphabet, + et /, ne sont pas compatibles URL. Dans une chaîne de requête, + est interprété comme un espace et / peut scinder un segment de chemin.
Le rembourrage = cause aussi des problèmes : il est parfois supprimé par les analyseurs et souvent retiré dans les formats compacts comme les JWT.
L'encodage en pourcentage peut réparer cela, mais chaque couche qui décode l'URL doit attendre le même échappement, et les erreurs de double encodage arrivent vite. Remplacer les deux caractères supprime le problème à la source.
- + se lit comme un espace dans les chaînes de requête
- / termine ou scinde un segment de chemin
- Le rembourrage = est supprimé par certains analyseurs et formats de jetons
Côte à côte
Seuls deux caractères diffèrent, et les octets décodés sont identiques. Remplacez + par - et / par _, retirez le rembourrage = : vous tenez la forme Base64URL des mêmes données.
La ligne du rembourrage mérite un second regard : le Base64 standard est défini avec rembourrage, le Base64URL le laisse facultatif, et JWT l'omet.
| Propriété | Base64 | Base64URL |
|---|---|---|
| 62e caractère | + | - |
| 63e caractère | / | _ |
| Rembourrage | Requis | Généralement supprimé |
| Usage typique | MIME e-mail, data URIs | JWT, noms de fichiers, chaînes de requête |
| Compatibilité décodeur | La plus large | Exige une gestion sûre pour URL |
Quand utiliser quelle variante
En pratique, ce sont les segments JWT que vous verrez le plus souvent en Base64URL : l'en-tête, le payload et la signature arrivent sans rembourrage. Lorsque j'ai dû décoder un payload JWT dans un script, choisir le décodeur sûr pour URL a tout réglé en une ligne.
- Utilisez Base64URL pour les segments d'en-tête et payload JWT, les noms de fichiers et tout ce qui est intégré dans une URL
- Utilisez le Base64 standard pour les pièces jointes MIME et les données qui ne touchent jamais d'URL
- En cas de doute, préférez Base64URL dans les applications web et le Base64 standard dans les formats hérités
Remarque: Les deux ne diffèrent que par l'alphabet et le rembourrage. Un segment JWT est du Base64URL sans rembourrage ; ne rajoutez pas de rembourrage lors du décodage.
Encoder et décoder localement, pas à pas
L'outil affiche la sortie avec et sans rembourrage, et le décodeur accepte les deux, donc vous pouvez coller un segment JWT tel quel dans l'encodeur multi-format.
- Ouvrez l'encodeur multi-format dans votre navigateur.
- Choisissez Base64 ou Base64URL dans les options d'encodage.
- Collez votre texte ou le contenu du fichier et encodez-le.
- Passez au décodeur et collez le résultat pour vérifier l'intégrité de l'aller-retour.
FAQ
Q.Base64URL reste-t-il du Base64 ?
A.Oui. Il utilise la même idée et les mêmes règles de rembourrage ; seuls deux caractères de l'alphabet changent (- et _ au lieu de + et /). Les octets décodés sont identiques, et la plupart des bibliothèques standard proposent une variante sûre pour URL, par exemple Buffer sous Node ou le module base64 de Python.
Q.Base64URL a-t-il besoin de rembourrage ?
A.Le rembourrage est facultatif en Base64URL et généralement supprimé dans les formats compacts comme JWT. Les décodeurs acceptent les deux formes, car la longueur est dérivable des données (un multiple de 4). Vous l'ajoutez rarement à la main : un décodeur le rétablit tout seul. atob() dans le navigateur attend du Base64 rembourré, donc convertissez d'abord.
Q.Base64URL est-il plus sûr que Base64 ?
A.Non. Les deux sont des encodages sans aucun secret ; l'alphabet ne change rien à la confidentialité. Base64URL évite seulement les problèmes d'analyse d'URL. Quand la confidentialité compte, utilisez un vrai chiffrement comme AES-256-GCM et encodez le résultat en Base64URL s'il doit voyager dans une URL. Traitez-le comme un format de transport.
Références
- RFC 4648 – The Base16, Base32, and Base64 Data Encodings : https://www.rfc-editor.org/rfc/rfc4648
- RFC 7515 – JSON Web Signature (JWS) : https://www.rfc-editor.org/rfc/rfc7515
- MDN – btoa() : https://developer.mozilla.org/fr/docs/Web/API/Window/btoa
Encodez vous-même
Base64, Base64URL, URL et Hex dans votre navigateur. Collez, encodez, copiez.
Base64URL pour les URL, Base64 pour le MIME
Utilisez Base64URL partout où les données toucheront une URL, un nom de fichier ou un en-tête JWT. Gardez le Base64 simple pour le MIME e-mail et les formats qui ne voient jamais d'URL.
Aucune variante ne cache quoi que ce soit, donc chiffrez le contenu sensible séparément avec le chiffreur AES-256-GCM et encodez-le ensuite avec l'encodeur multi-format.
Une habitude qui fait gagner du temps : une chaîne contenant + ou / est du Base64 standard, une chaîne contenant - ou _ est du Base64URL. Un seul coup d'œil vous dit quel décodeur choisir.