Encoder / décoder du Base64 en ligne

Texte clair

Base64

Variante URL-safe : + devient -, / devient _, sans = final

La conversion se fait entièrement dans votre navigateur : rien n'est transmis — vérifiable dans l'onglet Réseau de vos outils de développement.

01Le Base64, à quoi ça sert ?

Le Base64 transforme n'importe quelle donnée binaire en texte inoffensif — 64 caractères sûrs (A-Z, a-z, 0-9, + et /) qui traversent sans dommage tout ce qui a été conçu pour du texte : emails (pièces jointes MIME), JSON, XML, URLs de données (data:image/png;base64,…), en-têtes HTTP Basic. Ce n'est pas du chiffrement : c'est un simple ré-encodage, réversible par n'importe qui — comme cette page le prouve.

Le piège JavaScript classique : btoa("café") lève une exception, car btoa ne connaît que l'ASCII. Cette page encode le texte en UTF-8 d'abord (TextEncoder), puis en Base64 — accents, émojis et idéogrammes passent sans casse. Les segments d'un jeton JWT utilisent la variante URL-safe, décodée ici aussi.

02Comprendre les variantes

Standard: L'alphabet historique (RFC 4648) : A-Z a-z 0-9 + / avec un padding = final pour aligner sur 4 caractères. 3 octets → 4 caractères : +33 % de volume.
URL-safe: Le + devient -, le / devient _, le padding = est généralement omis : la chaîne peut vivre dans une URL ou un nom de fichier sans échappement. C'est l'alphabet des JWT.
Padding =: Complète le dernier bloc pour que la longueur soit multiple de 4. Beaucoup de décodeurs l'exigent, d'autres s'en passent — celui-ci le reconstruit s'il manque.
UTF-8: Le texte doit être converti en octets avant l'encodage : c'est le choix de la table d'octets (UTF-8, Latin-1…) qui fait qu'un même « é » donne des Base64 différents.
data: URI: Une image ou une fonte embarquée directement dans le HTML/CSS en Base64 : pratique pour de petits fichiers, contre-productif au-delà de quelques Ko (+33 % et pas de cache séparé).

03Base64 n'est pas un secret

On croise régulièrement des mots de passe, des clés d'API ou des configurations « protégés » en Base64. N'importe qui peut les lire en une seconde — vous venez de le faire. L'en-tête Authorization: Basic lui-même n'est que utilisateur:motdepasse en Base64 : sans HTTPS, c'est du clair.

Pour protéger réellement une donnée, il faut du chiffrement (AES, age, GPG…) ou, pour un mot de passe stocké, un hachage dédié — voyez notre outil de hachage et notre générateur de mots de passe.

04Questions fréquentes

Pourquoi mon Base64 décodé affiche des caractères bizarres (Ã©, â€¦) ?

C'est un problème d'encodage du texte d'origine : la donnée a été encodée en UTF-8 mais relue en Latin-1, ou l'inverse. « é » en UTF-8 fait deux octets, qui relus en Latin-1 donnent « Ã© ». Cette page décode systématiquement en UTF-8, le standard actuel — si le résultat semble corrompu, la source était probablement dans un autre jeu de caractères.

Le Base64 est-il sûr pour transmettre un mot de passe ?

Non — ce n'est pas du chiffrement, juste une réécriture réversible instantanément. Sa seule protection est d'être illisible à l'œil nu. Un mot de passe doit transiter sous HTTPS (qui chiffre tout le canal) et être stocké haché avec un algorithme dédié (bcrypt, scrypt, argon2), jamais « encodé ».

Pourquoi la version encodée est-elle plus longue que l'original ?

Le Base64 représente 3 octets avec 4 caractères : +33 % incompressible, plus le padding éventuel. C'est le prix pour ne transporter que des caractères sûrs. Pour de gros volumes, on transmet le binaire brut (HTTP le gère très bien) et on réserve le Base64 aux contextes qui exigent du texte.

Quelle est la différence avec l'encodage URL (%20) ?

L'encodage pour-cent échappe seulement les caractères problématiques d'un texte dans une URL, caractère par caractère — le résultat reste lisible. Le Base64 ré-encode la totalité des octets, y compris du binaire pur, au prix de la lisibilité. Un JSON dans un paramètre d'URL sera percent-encodé ; une image dans une page sera en Base64.