Décodeur Base64/URL

Décodez et encodez en Base64, analysez les chaînes encodées URL, prévisualisez les images Base64 et décodez les segments d'en-tête ou de charge utile JWT

La sortie apparaîtra ici.
Aperçu de l'image
Aucune image détectée.
Les images décodées seront affichées ici.

Comment utiliser

Étape 1

Choisir le mode d'analyse

Basculez entre l'analyse Base64, URL ou de segment JWT.

Étape 2

Coller la valeur encodée

Entrez du texte encodé, une URL de données d'image ou un jeton JWT complet.

Étape 3

Décoder et inspecter

Lisez la sortie décodée, prévisualisez les images et copiez les résultats.

FAQ

Puis-je décoder des images Base64 directement dans le navigateur ?

Oui. Collez une URL de données ou une chaîne d'image Base64 brute et l'outil affiche un aperçu de l'image avec le type MIME et la taille détectés.

Le décodage d'URL gère-t-il correctement les signes plus ?

Oui. En mode décodage, les signes plus sont interprétés comme des espaces avant le décodage URI, conformément au comportement courant d'encodage de formulaire.

Puis-je décoder uniquement l'en-tête ou la charge utile du JWT ?

Oui. Le mode JWT vous permet de choisir et de décoder indépendamment l'en-tête, la charge utile ou les segments liés à la signature.

Quelle est la différence entre le Base64 standard et le Base64 compatible URL ?

Le Base64 standard (RFC 4648 section 4) utilise + et /, qui entrent en collision avec les caractères réservés des URL. L'alphabet compatible URL (section 5) les remplace par - et _. Les JWT utilisent toujours l'alphabet compatible URL - c'est pourquoi les signatures de jetons ne contiennent jamais + ou /. Cet outil détecte automatiquement l'un ou l'autre alphabet.

Pourquoi le Base64 se termine-t-il par des signes =, et peut-on les supprimer ?

Le Base64 encode 3 octets en 4 caractères ; les entrées qui ne sont pas un multiple de 3 sont donc complétées avec = pour que la longueur reste un multiple de 4. Un = signifie 2 octets restants, deux = signifient 1. Le remplissage peut être omis en toute sécurité lorsque la longueur est connue par un autre moyen - c'est exactement ce que font les segments JWT - et les décodeurs le rétablissent automatiquement.

L'encodage Base64 peut-il corrompre un texte non anglais ?

Base64 est en soi sans perte, mais la fonction JavaScript courante btoa() n'accepte que les caractères Latin-1 et lève une erreur pour tout le reste. La bonne approche consiste à encoder d'abord en UTF-8 (TextEncoder), puis à encoder les octets en Base64. Cet outil gère ce pipeline automatiquement, de sorte que les textes chinois, arabes ou avec des emoji font des allers-retours sans aucune corruption.

Comment savoir si une chaîne est réellement du Base64 ?

Vérifiez trois signaux : le jeu de caractères se limite à A-Z, a-z, 0-9, +, / (ou aux équivalents URL-safe - et _) ; la longueur est un multiple de 4 une fois le remplissage rétabli ; et le décodage produit des octets cohérents. Aucune méthode n'est fiable à 100 % car de nombreuses chaînes ordinaires (comme abcd) sont aussi du Base64 valide - le contexte compte.

Le Base64 est-il une forme de chiffrement ?

Non. Base64 est un encodage réversible que tout le monde peut décoder sans aucun secret - il n'offre aucune confidentialité. Ne l'utilisez jamais pour protéger des mots de passe ou des clés d'API. Pour vous protéger, utilisez TLS en transit et un vrai chiffrement comme AES-256-GCM ; le seul rôle de Base64 est de rendre les données binaires sûres pour les canaux texte.

{-- * External Resources Component(#18 Phase 3b 内容佐证工程) * 工具页「权威引用」区块:RFC / W3C / WHATWG / ECMA / IANA / 官方规范站 / Wikipedia。 * * - 接受 :slug 属性 → 经 config/tool-sources.php 家族矩阵渲染该工具的权威引用 * - slug 未命中映射时不渲染(无权威来源的工具静默跳过) * - 链接 title 保持英文(引用源专名);description 经 * common.resources.descriptions.{key} 本地化,lang 未命中回退英文(线上不裸奔) * - 链接保持 dofollow(rel="noopener noreferrer") * * @param string|null $slug --}}