L’encodage pourcent (RFC 3986) écrit chaque octet non sûr sous la forme % suivie de deux chiffres hexadécimaux : l’espace donne %20, & donne %26 et é donne %C3%A9. Le mode composant sert aux valeurs de query, URI complète préserve / ? et #, et + = espace imite les formulaires HTML.
Mode d’emploi
- Choisissez un format : Base64, Base32, Hex, Binaire, URL, HTML, Unicode ou Punycode.
- Choisissez Encoder ou Décoder, puis saisissez ou collez. Le résultat se met à jour pendant la frappe.
- Touchez le résultat pour le copier ou téléchargez-le. Le bouton d’inversion place la sortie dans l’entrée et change de sens.
- En Base64, déposez n’importe quel fichier pour obtenir du Base64 ou une data URL. Le décodage d’une image en Base64 affiche un aperçu téléchargeable.
- Si l’entrée ne peut pas être décodée, l’erreur indique le caractère et la position exacts.
- Tout est en UTF-8 : emoji, accents et tous les alphabets sont conservés.
- Le décodage Base64 accepte l’alphabet standard et URL-safe, l’absence de remplissage, les retours à la ligne et les data URL.
- Le mode composant d’URL encode tous les caractères réservés (/ ? & = #) ; URI entière conserve la structure. Utilisez « + = espace » pour les données de formulaire.
- Punycode convertit les noms de domaine internationalisés : münchen.de ⇄ xn--mnchen-3ya.de. Collez une URL complète : seul l’hôte est converti.
- Rien n’est envoyé : tout se passe dans votre navigateur.
Encoder n’est pas chiffrer
Tous ces formats sont des façons réversibles d’écrire des octets sous forme de texte, définies par des normes publiques : Base64 et Base32 par la RFC 4648, l’encodage pourcent par la RFC 3986, les entités par le standard HTML et Punycode par la RFC 3492. N’importe qui peut les décoder sans clé. Ils servent à faire passer des données par des systèmes qui n’acceptent que certains caractères, jamais à cacher un secret.
Comment fonctionne Base64
Base64 prend les octets par groupes de 3 (24 bits) et les écrit en 4 caractères parmi A–Z, a–z, 0–9, + et /. Le résultat est donc environ 33 % plus long, et = complète le dernier groupe : Man devient TWFu, Hello devient SGVsbG8=. La variante URL remplace + et / par - et _ pour tenir dans une URL ou un nom de fichier ; c’est celle des JWT.
Le texte est d’abord converti en octets UTF-8 : é (2 octets, c3 a9) et € (3 octets, e2 82 ac) sont donc encodés correctement. Les outils qui sautent cette étape échouent dès qu’un caractère sort de l’ASCII.
Quel format choisir
L’encodage URL convient aux valeurs de query string (une espace devient %20, ou + dans un formulaire HTML), les entités HTML à l’insertion de texte saisi par un utilisateur, l’hexadécimal et le binaire à l’inspection d’octets, Base32 aux codes insensibles à la casse comme les secrets TOTP, et Punycode aux noms de domaine internationalisés : münchen.de s’écrit xn--mnchen-3ya.de dans le DNS.
Questions fréquentes
Le Base64 est-il un chiffrement ?
Non. Le Base64 est un encodage que n’importe qui inverse instantanément, sans clé. Il permet seulement d’envoyer des données binaires sous forme de texte. Chiffrez d’abord si les données doivent rester privées.
Pourquoi le Base64 grossit-il les données ?
Chaque groupe de 3 octets devient 4 caractères : la taille augmente d’environ 33 %, plus jusqu’à deux signes = de remplissage. Une image de 30 Ko fait environ 40 Ko en Base64.
Quelle différence entre encoder un composant et une URI complète ?
Le mode composant encode les caractères réservés comme / ? & = # pour qu’une valeur tienne dans une query string. Le mode URI complète les laisse intacts pour que l’adresse entière reste valable.
Pourquoi voit-on %20 dans certaines URL et + dans d’autres ?
Les deux représentent une espace. %20 est l’encodage standard (RFC 3986) ; + n’est valable que dans les données de formulaire application/x-www-form-urlencoded. Activez l’option + = espace pour ce type de query string.
Peut-on décoder du Base64 en image ou en fichier ?
Oui. Collez le Base64 ou une data: URL en mode Décoder ; s’il s’agit d’une image, un aperçu s’affiche, et tout fichier peut être téléchargé avec ses octets d’origine.
Les emojis et alphabets non latins sont-ils gérés ?
Oui. L’entrée passe en UTF-8 avant l’encodage et repart de l’UTF-8 au décodage : emojis, accents, cyrillique, japonais et coréen reviennent tels quels.