Encodeur et décodeur Base64

Collez la chaîne dans le champ de saisie et le résultat décodé apparaît aussitôt dans le même onglet, sans bouton, sans compte et sans envoi. Si la chaîne se trouve dans un fichier, ouvrez directement un .txt ou un .b64 plutôt que de la coller. Le décodeur lit aussi bien l'alphabet standard (+ /) que l'alphabet URL-safe (- _), écarte les retours à la ligne et les espaces venus avec la copie, et affiche la longueur en octets à côté du résultat.

Passez du côté encodage, saisissez ou collez votre texte, et la sortie Base64 est produite avec un remplissage canonique par défaut. Le texte est d'abord converti en octets UTF-8, si bien que les accents, les cédilles et les émojis reviennent identiques après l'aller-retour. Choisissez l'alphabet URL-safe si la chaîne doit voyager dans une URL ou un nom de fichier, et désactivez le remplissage si le système destinataire attend une chaîne sans signe égal.

Non : ce que vous collez ne quitte pas l'onglet, car le décodage s'exécute entièrement dans la page déjà chargée et n'émet aucune requête réseau pendant l'opération. C'est exactement ce qu'exige le matériel que l'on décode d'ordinaire — jetons de session, extraits de journaux, secrets de configuration — qu'il est souvent interdit de coller dans un service distant.

Oui : une fois la page chargée, vous pouvez couper le réseau et continuer à décoder et encoder, et aucune inscription n'est demandée à aucun moment. Rien n'est téléchargé pendant le décodage, un poste isolé se comporte donc comme un poste connecté. Seul le chargement initial de la page réclame une connexion : gardez l'onglet ouvert si vous savez que le réseau va disparaître.

Ouvrez cette page dans Safari sur iPhone ou iPad, touchez le sélecteur de fichier et choisissez le .b64 dans Fichiers ou iCloud Drive : aucune application n'est installée. C'est utile en mobilité, car iOS ne sait pas ouvrir l'extension .b64 tout seul et affiche souvent une chaîne brute illisible. Le texte décodé se copie d'un geste, et un résultat binaire est enregistré comme téléchargement plutôt qu'affiché.

Parce que des caractères de données apparaissent après un signe égal, or le remplissage ne peut se trouver qu'à la toute fin d'une chaîne Base64. Le message pointe la position du premier signe égal et celle des données qui le suivent, ce qui montre l'endroit où deux fragments ont été recollés. La correction consiste à récupérer la chaîne entière depuis sa source, et non à supprimer les signes égal du milieu.

Parce que les octets décodés ne forment pas de l'UTF-8 valide, ou contiennent des octets de contrôle qu'aucun fichier texte ne porterait : ils sont donc déclarés binaires plutôt qu'affichés en charabia. La vérification est stricte et ne remplace jamais une séquence cassée par un caractère de substitution ; vous obtenez le verdict et le décalage de la première séquence fautive. Si les octets commencent par une signature d'image connue, le conteneur est nommé et le fichier proposé au téléchargement.

L'entrée accepte jusqu'à 2 000 000 de caractères et la charge décodée jusqu'à 2 000 000 d'octets, les deux plafonds étant contrôlés avant toute allocation de mémoire. Un collage trop volumineux est donc refusé immédiatement avec une erreur de taille qui rappelle les décomptes et la limite, au lieu de figer l'onglet en tentant de construire un tampon impossible. L'écran prévisualise 200 000 caractères d'un texte long, tandis que la copie et le téléchargement emportent la totalité.

Oui : une chaîne Base64 dont la longueur laisse un reste de deux ou trois caractères se décode normalement et reçoit simplement une note indiquant l'absence de remplissage. Les JWT et les paramètres d'URL circulent presque toujours sans remplissage, le refuser serait une erreur. Seul un reste d'un caractère est rejeté, car six bits isolés ne peuvent composer aucun octet complet.

Le décodage lui-même est sans risque ici, car la charge n'est traitée que comme des octets inertes : rien n'est exécuté, le HTML décodé n'est pas rendu et aucune URL contenue dans le résultat n'est appelée. Le danger se déplace vers l'étape suivante : un exécutable ou un document à macros décodé reste aussi dangereux une fois enregistré et ouvert qu'il l'était dans le message. L'outil dit ce que sont les octets, pas s'ils sont malveillants.

Le Base64 standard emploie + et / pour les valeurs 62 et 63, tandis que la variante URL-safe emploie - et _ afin que la chaîne tienne telle quelle dans une URL ou un nom de fichier. Les octets obtenus sont identiques, et cet outil accepte les deux en indiquant celui qu'il a détecté. Une chaîne qui mélange les deux est refusée, car ce mélange trahit presque toujours deux copies différentes assemblées par erreur.

Non : un décodage propre prouve seulement que les caractères formaient une séquence Base64 bien construite, pas que les données sont authentiques ni qu'elles n'ont pas été modifiées. Base64 est un encodage, ni un chiffrement ni une signature : n'importe qui peut altérer le contenu, le réencoder et obtenir une chaîne qui se décode tout aussi proprement. La confiance vient de la provenance, pas du succès du décodage.