Base64 Encoder, Decoder & Inspector
Encodez n'importe quel fichier — pas seulement des images — avec l'alphabet, le remplissage et la largeur de ligne que le destinataire attend vraiment. Décodez une charge utile et découvrez ce qu'elle est réellement : le format lu dans ses octets magiques, les premiers octets en hexadécimal, sa taille après gzip et son SHA-256.
Comment ça marche
Amenez la charge utile
Tapez-la, collez-la, déposez un fichier de n'importe quel type, ou laissez un autre outil de la suite vous la transmettre. Déposer un fichier ne lit encore rien.
Choisissez la sortie
Alphabet standard ou compatible URL, remplissage oui ou non, coupé à 64, 76 ou 100 colonnes en LF ou CRLF. Ce sont exactement les points sur lesquels les analyseurs réels ne s'accordent pas.
Regardez les octets
Le format est lu dans les nombres magiques, pas deviné d'après le nom. Vous obtenez le vidage hexadécimal, la taille après gzip, le SHA-256 et une vérification de réversibilité.
Emportez-le
Copiez la chaîne brute, une URL data:, une règle CSS, une balise img, un corps JSON ou un bloc PEM — ou envoyez le fichier décodé directement vers un autre outil.
Trois octets, quatre caractères
Base64 coûte toujours 33 % de plus que les octets qu'il transporte, et l'outil affiche les deux chiffres plus la taille après gzip, car sur les charges proches du texte gzip récupère presque tout, et sur un PNG presque rien.
Alphabet compatible URL
Passez à - et _ et la charge utile survit à une chaîne de requête, un nom de fichier ou un JWT sans rien à échapper. Le remplissage peut aussi être retiré, ce qu'attendent les formats de jeton.
Inspecteur hexadécimal
Voyez les vrais octets, seize par ligne, avec l'ASCII imprimable à côté. Le nombre magique est mis en évidence, donc un fichier tronqué se trahit immédiatement.
Il vous dit ce qui a cassé
Quel caractère n'est pas dans l'alphabet et à quelle position, si le remplissage manquait, si le dernier caractère porte des bits jetés. Pas un simple « Base64 invalide ».
Format lu dans les octets
PNG, JPEG, GIF, WebP, AVIF, HEIC, PDF, ZIP et les formats Office qu'il contient, WOFF2, MP4, WASM, SQLite et d'autres, identifiés par leur signature — pour que le téléchargement porte la bonne extension.
Les gros fichiers restent fluides
Les fichiers sont consommés par blocs de 3 Mo sur un fil séparé, avec une vraie barre de progression et un bouton Arrêter qui fonctionne. L'onglet continue de répondre pendant la conversion d'une charge de 200 Mo.
Mesurable, pas seulement produit
Chaque exécution fournit la taille après gzip et le SHA-256, calculés sur les mêmes octets. C'est ainsi que vous décidez si l'intégration bat une seconde requête, et que vous prouvez que l'aller-retour n'a rien perdu.
Vérification de réversibilité
Chaque encodage de texte est immédiatement redécodé et comparé octet par octet, donc une combinaison d'alphabet et de remplissage que votre destinataire refuserait est signalée avant que vous ne la collez.
La charge utile, pas seulement la chaîne
La plupart des outils Base64 vous donnent une chaîne et s'arrêtent là. Celui-ci garde les octets : il identifie le format par sa signature, vide le premier kilo-octet en hexadécimal, mesure ce que la charge utile coûte réellement après gzip, la hache pour que vous puissiez prouver l'aller-retour, et vous dit précisément quel caractère à quelle position a cassé une charge au lieu d'accuser l'ensemble. À l'encodage il accepte n'importe quel fichier — une police, un PDF, un module WebAssembly — parce que Base64 n'a jamais concerné seulement les images.
Rien ne quitte votre navigateur
L'encodage, le décodage, la détection de format, le vidage hexadécimal, la mesure gzip et le SHA-256 sont tous des API natives du navigateur exécutées dans votre propre onglet, sur un fil séparé pour tout ce qui est volumineux. Il n'y a ni envoi, ni requête, ni rien à journaliser — et cela compte, car les charges que l'on colle dans un outil Base64 sont couramment des clés privées, des jetons de session et des documents internes.
Conçu pour les charges utiles qui arrivent sans étiquette
Un blob sorti d'une colonne de base de données sans aucun type MIME noté nulle part. Un segment de JWT qui refuse de se décoder parce qu'il utilise l'alphabet compatible URL et n'a pas de remplissage. Un SVG intégré dans une feuille de style qui s'affiche comme une image cassée. Une URL data: qui annonce image/png alors que les octets sont clairement un JPEG. Un certificat coupé à 64 colonnes qu'un analyseur strict refuse. Base64Bolt les lit tous, dit ce que sont vraiment les octets, et vous laisse sortir le résultat en fichier avec la bonne extension.
Pas d'inscription, pas de quota journalier, pas d'offre payante qui cache la moitié utile de l'outil. Les fichiers que vous ouvrez sont lus localement et ne sont jamais transmis ; l'onglet oublie tout à la fermeture.
Questions fréquentes
QPourquoi mon JWT ou mon jeton échoue-t-il ailleurs mais fonctionne ici ?+
Parce qu'il utilise l'alphabet compatible URL — tiret et tiret bas au lieu de plus et barre oblique — et que son remplissage a généralement été retiré. Un décodeur qui ne connaît que l'alphabet standard échoue dès le premier tiret. Base64Bolt détecte quel alphabet l'entrée utilise, restaure le remplissage manquant, et vous signale les deux.
QBase64 agrandit-il mon fichier ?+
Toujours, d'exactement un tiers : trois octets deviennent quatre caractères, plus jusqu'à deux caractères de remplissage. Que cela vous coûte quelque chose dépend de la compression, et c'est pourquoi l'outil affiche la taille après gzip à côté de la taille brute. Intégrer un petit SVG gagne généralement ; intégrer un gros JPEG perd généralement, car il est déjà compressé et Base64 défait une partie de ce travail.
QPuis-je encoder autre chose qu'une image ?+
Oui, n'importe quel fichier. Des polices pour une règle @font-face, un PDF pour un lien de téléchargement, un module WebAssembly, un ZIP, un extrait audio. L'ancienne limitation aux images était arbitraire : Base64 ne se soucie pas de ce que signifient les octets.
QQue veut dire « le dernier caractère porte des bits qui sont jetés » ?+
Chaque caractère Base64 contient six bits, mais le dernier groupe d'une charge utile en a souvent besoin de moins. QQ== et QR== décodent tous deux en l'unique octet 0x41, car les quatre derniers bits du R sont jetés. Aucun encodeur ne produit la seconde forme : la voir signifie que la chaîne a été tronquée ou modifiée à la main — bon à savoir avant de faire confiance au résultat.
QPourquoi le décodage dit-il que les octets ne sont pas de l'UTF-8 ?+
Parce que ce n'est pas du texte. Base64 transporte des octets, et beaucoup de charges utiles sont des images, des archives ou des clés. L'ancien comportement était d'annoncer « Base64 invalide », ce qui était simplement faux : le Base64 allait très bien. Passez à l'onglet Base64 vers fichier et l'outil identifiera le format et vous laissera le télécharger.
QFaut-il couper la sortie à 76 colonnes ?+
Seulement si quelque chose en aval l'attend. Les corps MIME et les blocs PEM sont coupés par spécification — PEM à 64 colonnes, MIME à 76 — et certains analyseurs de courrier refusent une seule ligne énorme. Pour une URL data: dans une feuille de style ou un champ JSON, laissez la coupe désactivée.
QQuelque chose est-il envoyé à un serveur ?+
Non. Chaque étape est une API native du navigateur exécutée dans votre onglet, donc l'outil continue de fonctionner hors ligne une fois la page chargée. Rien n'est envoyé, mis en cache à distance ou journalisé.