Mode d’emploi
- Choisissez Encoder ou Décoder. La variante compatible URL est présélectionnée, avec le remplissage désactivé.
- Saisissez ou collez du texte, entrez des octets en hexadécimal ou ouvrez un fichier. Le résultat se met à jour pendant la saisie.
- N’activez le remplissage que si le système destinataire exige des signes = à la fin.
- Copiez le résultat ou téléchargez-le.
Qu’est-ce que Base64URL ?
Base64URL est défini dans la section 5 de la RFC 4648 sous le nom « Base 64 Encoding with URL and Filename Safe Alphabet ». Il fonctionne exactement comme le Base64 standard, avec 6 bits par caractère, mais remplace les deux caractères qui posent problème dans les URL et les chemins de fichiers :
| Base64 standard | Base64URL | |
|---|---|---|
| Valeur 62 | + | - |
| Valeur 63 | / | _ |
| Remplissage | =, obligatoire | généralement omis |
Dans une URL, + peut être interprété comme une espace, / sépare les segments du chemin et = sépare les clés de leurs valeurs dans la chaîne de requête : le Base64 standard doit donc être encodé en pourcentage avant d’être placé dans un lien. Base64URL ne nécessite aucun échappement. La RFC 4648 autorise l’omission du remplissage lorsque la longueur est connue par le contexte, et la plupart des spécifications fondées sur Base64URL font précisément ce choix.
Où Base64URL est utilisé
- JSON Web Tokens. L’en-tête, la charge utile et la signature d’un JWT sont chacun encodés en Base64URL sans remplissage (RFC 7515). Pour en lire un, utilisez le décodeur JWT.
- OAuth 2.0 PKCE. Le
code_challengeest la forme Base64URL sans remplissage du hachage SHA-256 du code verifier (RFC 7636) ; il fait donc toujours 43 caractères. - JSON Web Keys et WebAuthn. Les paramètres de clé tels que
n,e,xety, ainsi que les challenges WebAuthn et les identifiants d’authentifiants (credential ID), sont échangés en Base64URL. - Jetons, identifiants et noms de fichiers. Les liens de réinitialisation, les URL signées et les clés de cache transportent du Base64URL sans échappement ; un identifiant aléatoire de 16 octets devient une chaîne de 22 caractères. Sur les systèmes de fichiers insensibles à la casse, préférez Base32, car Base64URL distingue les majuscules des minuscules.
Convertir entre Base64 et Base64URL
Les deux variantes encodent les mêmes octets : la conversion se résume donc à un échange de caractères. Remplacez + par - et / par _, puis supprimez les = finaux. Pour revenir en arrière, échangez de nouveau les caractères et ajoutez des = jusqu’à ce que la longueur soit un multiple de 4. Le décodeur de cette page accepte les deux alphabets, avec ou sans remplissage.
// Node.js 16+
Buffer.from(data).toString('base64url')
Buffer.from(str, 'base64url')
# Python (urlsafe_b64encode conserve le remplissage)
base64.urlsafe_b64encode(data).rstrip(b'=')
// Go
base64.RawURLEncoding.EncodeToString(data)
// Java
Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)Spécifications
| Alphabet | A-Z a-z 0-9 - _ |
|---|---|
| Taille de sortie | 4 caractères pour 3 octets (environ 133 %) |
| Remplissage | Facultatif, généralement omis |
| Norme | RFC 4648, section 5 |
| Sensible à la casse | Oui |
Exemples
| Entrée (UTF-8) | Sortie |
|---|---|
Hello, World! | SGVsbG8sIFdvcmxkIQ |
Base64.is | QmFzZTY0Lmlz |
你好 | 5L2g5aW9 |
Questions fréquentes
Base64URL revient-il à encoder une chaîne Base64 pour une URL ?
+, / et = en %2B, %2F et %3D, ce qui allonge la chaîne. Base64URL utilise un alphabet différent, si bien qu’aucun échappement n’est nécessaire. Les deux formes ne sont pas interchangeables sans conversion.Base64URL doit-il comporter du remplissage ?
urlsafe_b64encode de Python et l’encodeur URL par défaut de Java l’ajoutent. Dans le doute, omettez-le : ce décodeur accepte les deux formes.Pourquoi un décodeur Base64 standard refuse-t-il ma chaîne Base64URL ?
- et _, et certains exigent le remplissage. Échangez les caractères et ajoutez des signes = pour que la longueur soit un multiple de 4, ou décodez la chaîne ici.Comment vérifier un code challenge PKCE ?
BASE64URL(SHA256(code_verifier)), sans remplissage. Décodez-le ici avec la sortie Hexa : une valeur correcte donne exactement 32 octets, que vous pouvez comparer au hachage SHA-256 du verifier.