UltKit

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.

Mode

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 _.

  1. 0A
  2. 1B
  3. 2C
  4. 3D
  5. 4E
  6. 5F
  7. 6G
  8. 7H
  9. 8I
  10. 9J
  11. 10K
  12. 11L
  13. 12M
  14. 13N
  15. 14O
  16. 15P
  17. 16Q
  18. 17R
  19. 18S
  20. 19T
  21. 20U
  22. 21V
  23. 22W
  24. 23X
  25. 24Y
  26. 25Z
  27. 26a
  28. 27b
  29. 28c
  30. 29d
  31. 30e
  32. 31f
  33. 32g
  34. 33h
  35. 34i
  36. 35j
  37. 36k
  38. 37l
  39. 38m
  40. 39n
  41. 40o
  42. 41p
  43. 42q
  44. 43r
  45. 44s
  46. 45t
  47. 46u
  48. 47v
  49. 48w
  50. 49x
  51. 50y
  52. 51z
  53. 520
  54. 531
  55. 542
  56. 553
  57. 564
  58. 575
  59. 586
  60. 597
  61. 608
  62. 619
  63. 62+ -
  64. 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éeOctetsStandardCompatible URLLongueur
U1VQ==VQ4
Ul2VWw=VWw4
Ult3VWx0VWx04
UltK4VWx0Sw==VWx0Sw8
UltKi5VWx0S2k=VWx0S2k8
UltKit6VWx0S2l0VWx0S2l08

À 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.