Encoder et décoder en Base64
Convertissez du texte ou un fichier en Base64, ou décodez du Base64 en texte lisible. L’Unicode est correctement pris en charge, l’alphabet URL-safe s’active en un clic, et le décodage accepte les deux alphabets, avec ou sans remplissage.
0 caractères · 0 mots · 0 lignes
0 caractères · 0 mots · 0 lignes
Fonctionne entièrement dans cet onglet du navigateur. Votre texte n’est jamais envoyé ni stocké.
L’alphabet Base64
Indice → caractère selon la RFC 4648. Les deux derniers, mis en évidence, diffèrent dans la variante compatible URL : 62 est + ou -, 63 est / ou _.
- 0A
- 1B
- 2C
- 3D
- 4E
- 5F
- 6G
- 7H
- 8I
- 9J
- 10K
- 11L
- 12M
- 13N
- 14O
- 15P
- 16Q
- 17R
- 18S
- 19T
- 20U
- 21V
- 22W
- 23X
- 24Y
- 25Z
- 26a
- 27b
- 28c
- 29d
- 30e
- 31f
- 32g
- 33h
- 34i
- 35j
- 36k
- 37l
- 38m
- 39n
- 40o
- 41p
- 42q
- 43r
- 44s
- 45t
- 46u
- 47v
- 48w
- 49x
- 50y
- 51z
- 520
- 531
- 542
- 553
- 564
- 575
- 586
- 597
- 608
- 619
- 62+ -
- 63/ _
Taille de la sortie
Chaque groupe de 3 octets en entrée devient 4 caractères ; un dernier groupe de 1 ou 2 octets est complété par = en Base64 standard et laissé sans remplissage dans la forme compatible URL.
| Entrée | Octets | Standard | Compatible URL | Longueur |
|---|---|---|---|---|
U | 1 | VQ== | VQ | 4 |
Ul | 2 | VWw= | VWw | 4 |
Ult | 3 | VWx0 | VWx0 | 4 |
UltK | 4 | VWx0Sw== | VWx0Sw | 8 |
UltKi | 5 | VWx0S2k= | VWx0S2k | 8 |
UltKit | 6 | VWx0S2l0 | VWx0S2l0 | 8 |
À quoi sert le Base64
Le Base64, défini par la RFC 4648, écrit des octets quelconques avec 64 caractères ASCII imprimables : A–Z, a–z, 0–9, + et /. Chaque groupe de trois octets (24 bits) est découpé en quatre nombres de 6 bits, et chaque nombre désigne un caractère de l'alphabet. Quand la longueur de l'entrée n'est pas un multiple de trois, le dernier groupe est complété par un ou deux signes =. Le résultat est toujours environ 33 % plus volumineux que l'entrée : 4 caractères pour 3 octets.
Il existe parce que de nombreux canaux ont été conçus pour du texte. Les e-mails (MIME), les URL data: en HTML et CSS, les champs JSON qui transportent des images ou des certificats et les en-têtes d'authentification HTTP Basic utilisent tous le Base64 pour transmettre des données binaires sans risque. Ce n'est pas du chiffrement et il ne cache rien : le décodage n'exige aucune clé.
Unicode et la variante URL-safe
Le Base64 encode des octets, pas des lettres : le texte doit donc d'abord être converti en octets. Cet outil utilise toujours l'UTF-8, l'encodage sur lequel repose le web : é devient deux octets et un emoji quatre. La fonction btoa intégrée au navigateur renvoie à elle seule une erreur pour tout caractère au-delà de U+00FF, ce qui explique pourquoi les encodeurs naïfs échouent sur les accents et les emoji ; ici, le texte passe d'abord par TextEncoder, et le décodage fait l'inverse avec TextDecoder. Si les octets décodés ne forment pas de l'UTF-8 valide (une image, un fichier zip), l'outil les affiche en hexadécimal plutôt qu'en texte illisible.
Le Base64 standard utilise + et /, qui ont une signification dans les URL et les noms de fichiers. L'alphabet compatible URL de la section 5 de la RFC 4648 les remplace par - et _, et le remplissage est généralement supprimé. Les JSON Web Tokens utilisent exactement cette forme. Le décodeur accepte les deux alphabets ainsi que l'absence de remplissage : vous pouvez donc coller l'un ou l'autre.
Encoder des fichiers et des images
Choisissez un fichier : l'outil le lit localement avec FileReader et renvoie son Base64, ou une URL data: complète avec le type MIME du fichier, prête à coller dans une balise img ou un arrière-plan CSS. Les images intégrées économisent une requête HTTP, mais elles gagnent un tiers de volume et ne peuvent pas être mises en cache séparément : elles conviennent donc aux petites icônes plutôt qu'aux photos. Pour des images avec aperçu et extraits HTML et CSS prêts à l'emploi, utilisez Image en Base64.
Questions fréquentes
- Pourquoi le résultat en Base64 est-il plus long que mon texte d’origine ?
- Chaque groupe de 3 octets devient 4 caractères : le résultat fait donc environ 4/3 de la taille de l'entrée, plus jusqu'à deux caractères de remplissage. Le texte non ASCII est encore plus long, car l'UTF-8 utilise de deux à quatre octets par caractère.
- À quoi servent les signes = à la fin ?
- Le remplissage. Ils rendent la longueur de la sortie multiple de quatre lorsque celle de l'entrée n'est pas un multiple de trois. Un seul = signifie que le dernier groupe comptait deux octets, deux = qu'il n'en comptait qu'un.
- Pourquoi le décodage échoue-t-il avec une erreur de caractère non valide ?
- L'entrée contient un caractère extérieur à l'alphabet, comme une espace au milieu d'un mot, un guillemet ou un % issu d'un encodage d'URL. Les sauts de ligne et l'absence de remplissage sont tolérés ; les autres caractères ne le sont pas.
- Est-il sûr d’encoder un mot de passe en Base64 ?
- Le Base64 n'offre aucune protection. L'authentification HTTP Basic envoie user:password en Base64, ce qui explique pourquoi elle ne doit être utilisée qu'en HTTPS. Pour protéger des secrets, utilisez un vrai chiffrement ou un hachage.
- Quelle est la différence entre Base64 et Base64url ?
- Seulement deux caractères et le remplissage : le Base64url utilise - et _ à la place de + et /, et omet généralement =, afin que le résultat puisse figurer dans des URL et des noms de fichiers sans échappement.