Encodeur et Décodeur Base64
Encodez n'importe quel texte en Base64 ou décodez-le instantanément — outil gratuit pour développeurs.
Votre texte reste sur votre appareil
Rien à supprimer ensuite
Conçu pour décoder des identifiants
Fonctionne dans tout navigateur moderne
Comment ça marche
- 1
Collez votre texte
Du texte brut à encoder, ou une chaîne Base64 à décoder.
- 2
Choisissez le sens et l’alphabet
Encoder ou décoder, standard ou compatible URL, selon la destination du résultat.
- 3
Copiez le résultat
Emportez-le dans un en-tête, un data URI, une valeur de configuration ou une requête.
Pourquoi cet outil
Les deux alphabets
Base64 standard et la variante compatible URL, pour qu’un jeton devant traverser une chaîne de requête y survive.
Remplissage géré dans les deux sens
Une entrée avec ou sans `=` final se décode, et vous choisissez ce que porte la sortie.
UTF-8 traité correctement
Arabe, turc et emoji font l’aller-retour intacts au lieu de se décoder en caractères de remplacement.
Instantané dans les deux sens
Encoder et décoder au même endroit, sans changer d’outil au milieu d’une session de débogage.
Rien n’est envoyé
La conversion a lieu dans votre navigateur — un jeton que vous collez n’atteint jamais un serveur.
Gratuit et sans compte
Aucune inscription, aucun filigrane et aucune limite sur la quantité convertie.
Base64 n’est pas du chiffrement, et le croire est une vraie vulnérabilité
C’est le point le plus important à comprendre sur ce format, et il est constamment mal compris. Base64 n’a ni clé, ni secret, ni la moindre propriété de sécurité. C’est une correspondance publique et réversible que n’importe qui peut défaire en une étape — exactement ce que fait cette page. Et pourtant Base64 apparaît régulièrement en guise de protection : mots de passe stockés encodés en Base64 dans une base de données, clés d’API « obfusquées » dans un fichier de configuration, données personnelles encodées dans un cookie pour que « ça ne ressemble à rien ». Rien de tout cela n’est caché. C’est simplement écrit dans un autre alphabet, et toute personne ou tout scanner qui le trouve le lit immédiatement. Si l’objectif est que quelqu’un ne puisse pas lire une valeur, il faut du chiffrement ou du hachage, et Base64 n’est ni l’un ni l’autre.
Sa vraie fonction : faire passer des octets par des canaux purement textuels
Base64 résout un problème précis et peu glorieux. Beaucoup de systèmes n’acceptent que du texte imprimable : corps d’e-mails, champs de chaînes JSON, en-têtes HTTP, documents XML, URL. Confiez à l’un d’eux du binaire brut — une image, une archive compressée, une clé de chiffrement — et quelque chose sur le trajet l’abîmera, car les octets qui ressemblent par hasard à des caractères de contrôle ou à des fins de ligne sont réécrits en transit. Base64 contourne cela en réexprimant des octets quelconques à l’aide de 64 caractères que tous les systèmes s’accordent à laisser tranquilles. Voilà pourquoi une pièce jointe est en Base64 dans le message, pourquoi une image intégrée en CSS est un `data:` URI, et pourquoi un certificat binaire est livré sous forme de bloc PEM. Le format est une enveloppe de transport, ni un format de stockage ni une mesure de sécurité.
Cela vous coûte un tiers d’octets en plus, et parfois cela compte
L’arithmétique est fixe : trois octets en entrée deviennent quatre caractères en sortie, donc la donnée encodée est environ 33 % plus grosse que ce qui est entré, avant remplissage. La plupart du temps cela n’a aucune importance. Cela cesse d’être sans importance quand on intègre des images en `data:` URI dans du CSS ou du HTML pour économiser une requête HTTP. Une image de 90 Ko devient 120 Ko de caractères et, contrairement à un vrai fichier image, elle ne peut pas être mise en cache séparément, ne peut pas être chargée paresseusement et bloque la feuille de styles qui la contient. Pour une petite icône, le marché est honnête. Pour une photographie, c’est en général une erreur qui se manifeste plus tard par un premier affichage lent. Si vous encodez quelque chose pour l’intégrer, regardez ce que la taille devient avant de vous engager.
L’alphabet compatible URL existe parce que trois caractères cassent les URL
Base64 standard utilise `+`, `/` et `=`, et les trois signifient autre chose dans une URL. Le signe plus est lu comme une espace dans les chaînes de requête, la barre oblique est un séparateur de chemin et le signe égal sépare un paramètre de sa valeur. Envoyez un jeton encodé en standard dans une URL et il arrive corrompu, souvent d’une manière qui n’apparaît que pour certaines entrées — d’où la fréquence du signalement « ça marche dans mon client d’API mais casse dans le navigateur ». La variante compatible URL corrige cela en substituant `-` à `+` et `_` à `/`, et en abandonnant généralement le remplissage. Les JWT l’utilisent, comme la plupart des formats de jetons modernes. Les deux alphabets ne sont pas interchangeables : décoder une chaîne compatible URL avec un décodeur standard strict échoue, alors faites correspondre la variante au chemin qu’a emprunté la valeur.
Ce que font les signes égal en fin de chaîne
Le remplissage est la partie que tout le monde remarque et dont personne n’est sûr. Comme l’encodage travaille par groupes de trois octets, une entrée dont la longueur n’est pas un multiple de trois laisse un groupe partiel, et les `=` complètent la sortie jusqu’à un multiple de quatre. Un signe égal signifie que l’entrée s’est terminée par deux octets restants ; deux signifient qu’elle s’est terminée par un. C’est tout ce qu’ils portent : une indication de longueur, pas des données. En pratique, les décodeurs divergent sur leur caractère obligatoire : certains refusent d’emblée une entrée sans remplissage, d’autres l’acceptent, et la convention compatible URL l’omet généralement car `=` est malcommode dans une URL. Si une valeur échoue à se décoder ailleurs et semble correcte ici, les attentes de remplissage divergentes méritent d’être vérifiées avant toute cause plus exotique.
Pourquoi décoder en local compte ici plus que presque partout ailleurs
Regardez ce que l’on colle réellement dans un décodeur Base64. C’est un en-tête `Authorization: Basic`, qui contient un nom d’utilisateur et un mot de passe séparés par deux-points. C’est la moitié charge utile d’un JWT, qui porte un identifiant d’utilisateur et souvent une adresse e-mail. C’est une chaîne de connexion, une clé d’API, un cookie de session, un certificat. Toute la raison pour laquelle on se tourne vers un décodeur est qu’on tient une valeur illisible, et les valeurs illisibles sont massivement des identifiants de connexion. Coller cela dans un décodeur hébergé remet un secret opérationnel à un tiers, par un canal qui ne laisse aucune trace. Cet outil convertit dans la page et ne transmet rien, ce que vous pouvez vérifier dans l’onglet Réseau des outils de développement — et pour ce format précis, ce n’est pas un raffinement.
Erreurs courantes à éviter
- Utiliser Base64 pour cacher quelque chose. Il n’y a ni clé ni secret — n’importe qui décode en une étape ; si une valeur ne doit pas être lisible, il faut du chiffrement ou du hachage, pas un autre alphabet.
- Envoyer une valeur encodée en standard dans une URL. Les caractères `+`, `/` et `=` y signifient autre chose ; utilisez l’alphabet compatible URL, sinon la valeur arrive corrompue pour certaines entrées et pas pour d’autres.
- Intégrer une grande image en `data:` URI. L’encodage ajoute environ un tiers à la taille, et le résultat ne peut être ni mis en cache séparément ni chargé paresseusement — acceptable pour une icône, coûteux pour une photographie.
- Supposer que le remplissage est facultatif partout. Certains décodeurs exigent les `=` finaux, d’autres les refusent ; si une valeur se décode ici et échoue ailleurs, vérifiez cette attente avant toute cause exotique.
- Coller un en-tête Authorization ou un JWT dans un décodeur hébergé. Ces valeurs sont des identifiants actifs, et le collage ne laisse aucune trace de cet envoi ; décodez en local.
Comparaison
| Critère | Cet outil | Décodeurs en ligne | Une ligne de commande |
|---|---|---|---|
| Contenu envoyé à un serveur | Jamais | Le plus souvent | Non |
| Alphabet compatible URL | Oui | Variable | Nécessite une option |
| UTF-8 traité correctement | Oui | Variable | Oui |
| Installation nécessaire | Aucune | Aucune | Un terminal |
| Compte ou inscription | Pas nécessaire | Souvent exigé | Pas nécessaire |
| Prix | Gratuit | Gratuit / offres payantes | Gratuit |
Fonctionnalités
Encodage et décodage
Les deux sens au même endroit, avec l’entrée et la sortie côte à côte.
Variante compatible URL
L’alphabet `-` et `_` qu’utilisent les JWT et tout ce qui voyage dans une URL.
Remplissage optionnel
Émettez ou retirez les `=` finaux pour correspondre à ce qu’attend le système destinataire.
Prise en charge complète d’Unicode
Le texte est d’abord encodé en UTF-8, si bien que les écritures non latines survivent au trajet.
Supporte les grandes entrées
De longues chaînes se convertissent sans envoi ni plafond de taille.
Entrée invalide signalée
Une chaîne qui n’est pas du Base64 valide le dit, au lieu de renvoyer un charabia silencieux.
Rien à installer
Pas de ligne de commande, pas d’environnement d’exécution, pas de dépendances : tout se passe sur la page web.
Compatible arabe et RTL
Interface complète en huit langues, dont l’arabe de droite à gauche.
Sécurisé par défaut
Servi en HTTPS, sans suivi du contenu ni envoi à un tiers.
Qui l’utilise
Développeurs
Lire un en-tête d’authentification ou la charge d’un jeton en plein débogage, sans le confier à un tiers.
Ingénieurs sécurité
Inspecter une valeur encodée trouvée dans un journal, un cookie ou un fichier de configuration.
Intégrateurs d’API
Construire ou vérifier un en-tête d’authentification basique avant d’envoyer une requête avec lui.
Développeurs front-end
Produire un `data:` URI pour une petite ressource intégrée et voir ce qu’elle coûte en taille.
Questions Fréquentes
Non. Tout s’exécute localement dans votre navigateur — votre texte n’est jamais envoyé, stocké ni partagé.
Oui — entièrement gratuit, sans compte et sans limite.