Outil décodeur Base64 en ligne

1. 1

   Collez le Base64

   Déposez la chaîne dans le champ de saisie. Les retours à la ligne, le remplissage manquant et les caractères base64url sont tous gérés, et un data URI, un bloc PEM ou un JWT peuvent être collés entiers : l'enveloppe est détectée et retirée pour vous.

2. 2

   Lisez le résultat

   La sortie apparaît pendant la saisie jusqu'à 256 Ko ; au-delà, le décodage se lance avec le bouton Décoder. Le panneau indique le format trouvé, le type de fichier reconnu dans les octets et le jeu de caractères utilisé pour afficher le texte.

3. 3

   Ajustez si la détection s'est trompée

   Basculez l'affichage entre texte, hexadécimal et ASCII imprimable, choisissez un jeu de caractères précis si celui détecté a produit des caractères de remplacement, ou activez le mode strict pour que les entrées mal formées soient refusées plutôt que réparées.

4. 4

   Copiez ou téléchargez

   Copiez le texte, ou téléchargez la charge utile avec l'extension que ses propres octets justifient : un PNG décodé s'enregistre en .png, pas en .bin. Tout est traité sur votre appareil et rien n'est envoyé.

Cinq réglages, et chacun existe parce qu'une charge réelle en avait besoin. Aucun n'est réservé à une offre payante : un décodeur qui retient le décodage n'est pas limité, il est cassé.

Format d'entrée

Laissez-le sur Auto et collez n'importe quoi. L'outil cherche, dans l'ordre, un préfixe data URI, un bloc d'armure OpenPGP, un en-tête PEM et un JWT en trois parties, et traite sinon l'entrée comme une charge simple. Choisir un format explicitement en fait une affirmation : si vous choisissez PEM et que l'entrée n'a pas de ligne BEGIN, on vous le dit au lieu de décoder autre chose. Choisir Standard ou Sûr pour URL fixe en plus l'alphabet, si bien qu'en mode strict une charge utilisant l'autre est refusée exactement au caractère où elle diverge.

Mode strict

Désactivé par défaut, parce que la tâche quotidienne consiste à lire une chaîne que quelqu'un vous a envoyée, et la refuser pour un = manquant n'aide personne. Activé, quatre choses deviennent des erreurs plutôt que des réparations : les espaces hors d'un format à retours, un remplissage absent ou incorrect, un alphabet mélangé, et un groupe final dont les bits inutilisés ne sont pas nuls. Ce dernier point mérite d'être connu : il a sa propre section plus bas, et aucun autre décodeur du web ne le signale.

Découper l'entrée

Un mécanisme, deux usages. « Chaque ligne » décode séparément une liste de charges indépendantes et les affiche en résultats distincts, ce qu'on veut quand un fichier de journal ou une colonne de base de données contient une valeur Base64 par ligne. « Segments JWT » découpe aux points, si bien que l'en-tête et la charge d'un jeton se décodent chacun de leur côté et qu'une signature qui n'est pas du texte lisible ne gâche pas le reste. Auto choisit le second quand l'entrée est un JWT et laisse tout le reste tranquille.

Afficher le résultat en

Auto affiche du texte pour une charge textuelle et un vidage hexadécimal pour tout le reste, d'après ce que sont réellement les octets et non d'après le fait qu'un décodeur de texte ait produit quelque chose. Vous pouvez passer outre : l'hexadécimal est la bonne vue pour une charge binaire que vous inspectez, l'ASCII imprimable sert à repérer des chaînes intégrées dans un binaire, et forcer Texte est la façon de vérifier une charge que le détecteur a mal classée. Le changement de vue est instantané car il réaffiche des octets déjà décodés.

Jeu de caractères

Auto lit d'abord une marque d'ordre des octets, puis tout jeu déclaré par un data URI, puis teste si les octets sont de l'UTF-8 valide, et retombe sinon sur Windows-1252 en tant que supposition annoncée. Si le résultat contient des caractères de remplacement, le panneau en donne le nombre, et choisir le bon jeu dans la liste corrige cela sans redécoder le Base64.

Le Base64 est un seul encodage, mais il arrive emballé dans au moins sept choses différentes. Un décodeur qui n'accepte qu'une charge simple rejette l'essentiel de ce que les gens ont réellement dans leur presse-papiers.

• Standard — l'alphabet du RFC 4648 — A–Z, a–z, 0–9, + et /, complété par =. Ce qu'émettent la plupart des encodeurs.
• Sûr pour URL (base64url) — le même, avec - et _ à la place de + et /, pour que la chaîne survive dans une URL ou un nom de fichier. Généralement sans remplissage. Détecté et décodé sans réglage.
• MIME — du Base64 standard coupé à 76 colonnes, comme dans les corps de courriel. Les retours à la ligne sont retirés ; en mode strict ce sont les seuls espaces qui restent légaux, car le format est défini par eux.
• PEM — une charge entre des lignes -----BEGIN X----- et -----END X-----, comme pour les certificats, les clés privées et les CSR. Les libellés doivent coïncider aux deux extrémités, et un bloc dont BEGIN et END divergent est signalé comme endommagé plutôt que décodé en silence.
• ASCII-Armor OpenPGP — le cousin de PEM, avec des en-têtes d'armure facultatifs et une ligne de somme =CRC24. La somme est vérifiée : c'est le seul contrôle d'intégrité que porte une variante de Base64, et un outil qui la retire sans la regarder a jeté la seule preuve qu'offre le format.
• Data URI — data:image/png;base64,…, ce qu'on obtient en copiant une image intégrée depuis du CSS ou les outils de développement. Le préfixe est retiré, et son type de média et son jeu de caractères déclarés sont utilisés plutôt que devinés.
• JWT — trois segments base64url séparés par des points. Découpé aux points pour que l'en-tête et la charge se décodent chacun en le JSON qu'ils sont — y compris les jetons à segment de signature vide, que produit alg:none et qu'un découpage plus strict refuserait.

C'est la partie que la plupart des décodeurs Base64 sautent, et c'est pour cela que tant d'entre eux vous rendent un écran de points d'interrogation. Le Base64 ne dit rien de son contenu. Une fois les octets là, en revanche, ils le disent généralement d'eux-mêmes : presque tous les formats binaires commencent par une signature, et la lire coûte peu.

Une quarantaine de signatures sont vérifiées, couvrant les images (PNG, JPEG, GIF, WebP, BMP, ICO, TIFF, AVIF, HEIC), les documents (PDF, RTF), les archives (ZIP, gzip, bzip2, xz, zstd, 7z, RAR), l'audio et la vidéo (MP3, FLAC, Ogg, WAV, MP4, WebM, AVI), les polices (TTF, OTF, WOFF, WOFF2) et les exécutables. Les formats fondés sur ZIP sont affinés d'un cran en lisant le nom de la première entrée de l'archive, si bien qu'un .docx décodé est proposé en .docx et non en .zip, et qu'un fichier OpenDocument est identifié par le type de média que porte sa propre entrée mimetype. Quand rien ne correspond, on vérifie si les octets sont même du texte — un octet NUL est le signal, avec une exception pour l'UTF-16, qui est par construction à moitié fait d'octets NUL — et un texte commençant par une accolade n'est étiqueté JSON que s'il s'analyse réellement.

Deux conséquences visibles dans l'interface. Le bouton de téléchargement propose le fichier sous l'extension que ses propres octets justifient, si bien qu'un PNG décodé s'enregistre en .png et s'ouvre d'un double clic. Et une charge binaire ne passe jamais dans un décodeur de texte pour produire une page de caractères de remplacement U+FFFD : elle va directement à la vue hexadécimale, et le panneau dit ce qui a été trouvé.

C'est la raison la plus courante pour qu'un décodage « semble faux », et ce n'est pas un défaut du décodeur. Le Base64 encode des octets. Il n'a aucun champ pour un encodage, aucun en-tête et aucune convention à ce sujet. Tout outil qui vous montre du texte a choisi un encodage à votre place, et la plupart ne disent pas lequel.

• Une marque d'ordre des octets est une affirmation — si les octets décodés commencent par une BOM, le producteur a dit quel est l'encodage, et c'est celui-là qui est utilisé. UTF-8, UTF-16 dans les deux ordres et UTF-32 dans les deux sont reconnus.
• Un data URI peut en déclarer un — data:text/plain;charset=windows-1251;base64,… nomme son propre jeu, et il est respecté — mais il passe après une BOM, car une BOM est dans les données alors que le paramètre n'est qu'une affirmation à leur sujet.
• De l'UTF-8 valide est presque une preuve — l'UTF-8 a assez de structure pour qu'un document d'une longueur quelconque soit très improbablement valide par hasard. Si les octets se décodent strictement en UTF-8, c'est ce qu'ils sont.
• L'ASCII pur ne prouve rien — l'ASCII est de l'UTF-8 valide et valide dans tout jeu à un octet, la question n'a donc pas de réponse. L'outil dit « ambigu » plutôt que d'affirmer une détection sûre que les données ne soutiennent pas.
• Sinon c'est une supposition, et elle est annoncée comme telle — une charge qui n'est pas de l'UTF-8 valide est dans un encodage à un octet, et les octets ne peuvent pas dire lequel. Windows-1252 est de loin le plus répandu, c'est donc le recours — affiché comme supposition, avec la liste complète à un clic.

Trente et un jeux de caractères sont proposés, et la liste est construite en demandant au navigateur lesquels il prend réellement en charge plutôt qu'en énumérant ceux qu'il est censé prendre en charge. L'UTF-32 fait exception : aucun navigateur ne l'implémente dans son décodeur de texte, il est donc décodé ici directement, et c'est pourquoi il figure dans la liste.

Le Base64 met trois octets dans quatre caractères. Quand la longueur de l'entrée n'est pas un multiple de trois, le groupe final est court — et certains bits de son dernier caractère n'appartiennent à aucun octet.

Dans un groupe final de deux caractères, les quatre derniers bits sont en trop. Dans un groupe de trois, les deux derniers. Un encodeur conforme y écrit des zéros. Rien n'oblige un décodeur à regarder, et pratiquement aucun ne le fait : QQ== et QR== se décodent tous deux en l'unique octet 0x41, en silence, dans tous les navigateurs, dans tous les outils en ligne de commande et sur tous les sites que nous avons testés. L'une de ces chaînes vient d'un encodeur et l'autre était corrompue ou modifiée à la main, et aucun outil ne les distingue.

Le mode strict vérifie. C'est signalé comme une erreur en mode strict et comme un avertissement sinon, si bien que les octets restent consultables : le but n'est pas de refuser les données, mais que vous sachiez que la chaîne n'a pas été produite comme elle le prétend. Il en va de même d'une charge qui mélange les deux alphabets : - et _ n'entrent jamais en collision avec + et /, elle se décode donc sans ambiguïté, mais l'un des deux est déplacé et quelqu'un devrait probablement le savoir.

Chaque refus indique l'index du caractère, la ligne et la colonne du problème, et quel était le caractère. Aucune des deux fonctions Base64 du navigateur ne signale de position, et aucun outil concurrent non plus — sur une charge de quatre mégaoctets avec un caractère parasite, « invalide » n'est pas un diagnostic.

• Base64 invalide — un caractère hors de l'alphabet. En mode indulgent ce n'est signalé que pour des caractères vraiment étrangers : les espaces et retours à la ligne sont retirés avant. Une espace insécable, ce que produit souvent une copie depuis une page web affichée, compte comme étrangère, et la position vous dit exactement où elle a atterri.
• Tronquée — la charge a un groupe final d'un caractère, ce qu'aucune entrée ne peut produire. C'est le seul signal sans ambiguïté « la chaîne a été coupée » que possède le Base64.
• Données après le remplissage — il y a des caractères après les signes =. Presque toujours deux chaînes Base64 collées bout à bout, dont tout décodeur indulgent fera volontiers un charabia plausible.
• Remplissage absent ou inattendu — en mode strict seulement. Les caractères = manquent, sont trop nombreux, ou n'ont pas la longueur qu'exige la longueur de la charge elle-même.
• Espaces non autorisés — en mode strict seulement, et seulement hors des formats à retours. Les retours à la ligne dans MIME, PEM et PGP font partie de ces formats et restent légaux.
• Alphabet incorrect ou mélangé — en mode strict seulement. La charge utilise des caractères de l'alphabet que vous n'avez pas choisi, ou des deux.

Le Base64 est un encodage, pas un chiffrement ni une frontière de sécurité. Il sert à faire passer des octets par des canaux qui n'acceptent que du texte, et les octets de l'autre côté sont ceux que quelqu'un y a mis.

• La sortie décodée est une entrée non fiable — une charge peut se décoder en un script, un exécutable ou du balisage conçu pour s'exécuter ailleurs. Avoir été du Base64 ne rend rien sûr, et le fait que ce soit arrivé encodé est parfois précisément le but.
• Ne collez pas de secrets que vous ne colleriez pas ailleurs — cette page s'exécute entièrement sur votre appareil et n'envoie rien, ce que vous pouvez vérifier avec les outils réseau de votre navigateur — mais mieux vaut ne pas prendre l'habitude de coller des identifiants dans des formulaires web, car la plupart des pages qui ressemblent à celle-ci, elles, envoient.
• La charge d'un JWT n'est pas vérifiée — découper un jeton et décoder ses segments vous montre ce qu'il affirme. Cela ne vérifie pas la signature, et n'importe qui peut produire un jeton disant n'importe quoi. Lisez-le comme une affirmation, jamais comme un fait.
• Une somme d'armure n'est pas une signature — le CRC-24 d'un bloc PGP détecte une corruption accidentelle. Ce n'est pas un contrôle cryptographique et il ne dit pas qui a produit le bloc.

Le Base64 n'arrive pas que par le presse-papiers. Il est enregistré dans des fichiers .txt et .b64, dans des certificats .pem et des blocs d'armure .asc, et intégré dans des documents .json, .xml et .eml — tout cela peut être déposé sur la page.

Ce que comprend la version gratuite

Jusqu'à 25 Mo de Base64, une entrée à la fois, et toutes les capacités de l'outil : les sept formats d'entrée, les trente et un jeux de caractères, le mode strict, les vues hexadécimale et ASCII, la détection du type de fichier, le téléchargement typé et les modes de découpage. La limite porte sur l'échelle, jamais sur le fait que l'outil fonctionne : 25 Mo de Base64 font environ 18,75 Mo de données décodées, une charge importante selon toute mesure normale.

Ce qu'ajoute Pro

Jusqu'à vingt entrées à la fois, toutes téléchargeables en une seule archive, et la limite de taille remplacée par ce que votre appareil peut réellement gérer plutôt que par un nombre fixe plus grand. La compression dans l'archive est choisie par fichier selon ce que la charge s'est révélée être : un lot d'images décodées est stocké au lieu d'être recompressé inutilement, tandis qu'un lot de JSON décodé est bien compressé.

Plusieurs encodages ressemblent assez au Base64 pour être confondus avec lui, et un décodeur qui les accepte quand même produit un charabia convaincant. Si la sortie est illisible et que le jeu de caractères n'est pas en cause, vérifiez si l'entrée est l'une de celles-ci.

• Encodage pour cent — %20 et %E2%9C%93 sont de l'encodage d'URL, pas du Base64. Utilisez plutôt l'encodeur et décodeur d'URL.
• Hexadécimal — une chaîne composée uniquement de 0–9 et a–f, de longueur paire, est bien plus probablement de l'hexadécimal que du Base64 — et l'hexadécimal est aussi du Base64 valide, ce qui est précisément pourquoi l'erreur produit un décodage plutôt qu'un message.
• Base32 — des majuscules A–Z et 2–7, complétées par =. Elle partage le caractère de remplissage et rien d'autre.
• Un hachage — un condensé MD5, SHA-1 ou SHA-256 n'est pas une donnée encodée et ne peut être redécodé en quoi que ce soit. C'est une empreinte à sens unique ; utilisez le générateur de hachage pour en produire une.
• Du texte déjà décodé — les mots ordinaires sont faits de caractères Base64, donc une phrase collée dans un décodeur « se décodera » en octets. Si le résultat est binaire et que l'entrée était lisible, l'entrée n'était pas encodée.

Prenez le décodeur quand vous avez déjà une chaîne Base64 et qu'il vous faut ce qu'elle contient. Utilisez l'encodeur pour le sens inverse.

• Inspecter un champ Base64 dans une réponse d'API, un corps de webhook ou une ligne de journal.
• Lire l'en-tête et la charge d'un JWT pour voir ce qu'affirme un jeton.
• Extraire une image ou une police d'un data URI intégré dans du CSS, du HTML ou un SVG.
• Vérifier ce que contient réellement un certificat PEM ou un bloc d'armure PGP.
• Récupérer du texte stocké en Base64 dans une colonne de base de données ou un fichier .env.
• Confirmer avec le mode strict qu'un encodeur a produit une sortie conforme.
• Retransformer une charge Base64 en un vrai fichier ouvrable portant la bonne extension.

Le décodeur utilise la voie Base64 que fournit votre navigateur : les plus récents en ont une native, les plus anciens retombent sur une voie présente partout et produisant une sortie identique octet pour octet. Il n'y a rien à configurer ni à installer. Les jeux de caractères viennent du navigateur, la liste exacte varie donc très légèrement d'un moteur à l'autre ; l'outil montre ce que le vôtre prend réellement en charge, pas ce qu'il est censé prendre en charge.

Le décodage s'exécute hors du fil principal, sur votre appareil, en utilisant la voie Base64 la plus rapide que propose votre navigateur. Mesuré sur une machine de bureau, une charge de 25 Mo se décode en environ 170 millisecondes de bout en bout, identification des octets comprise.

• Encodeur Base64
• Encodeur/Décodeur Base64
• Encodeur/Décodeur d'URL
• Générateur de hachage
• Générateur d'UUID
• Lecteur de QR code
• Formateur JSON
• Validateur JSON
• Minifieur JSON
• XML vers JSON
• Convertisseur de casse
• Nettoyeur de texte
• Convertisseur de couleurs
• Tous les convertisseurs