Décoder et encoder en Base64 : en PDF, image ou fichier

Collez du Base64 pour récupérer le fichier (PDF, image, texte ou JWT), ou déposez un fichier pour obtenir son Base64. Tout se passe dans cet onglet.

33 formats de fichier reconnus à leurs propres octets · RFC 4648 · rien n'est envoyé
Encodé

Collez quelque chose ci-dessus, déposez un fichier sur la carte ou choisissez l'un des exemples.

Essayez

Tout reste dans cet onglet : rien de ce que vous collez ou déposez n'est envoyé, et le HTML ou le script décodé est affiché comme texte, jamais exécuté.

3 octets → 4 caractères
Exemple : Man
M77 · 4DOctet 1
a97 · 61Octet 2
n110 · 6EOctet 3
1922546

Trois octets font 24 bits. Base64 découpe ces mêmes 24 bits en quatre groupes de six, et chaque groupe désigne l'un des 64 caractères. Les lignes blanches marquent la fin des octets : elles ne tombent pas sur les limites des groupes, et c'est là tout le principe.

Caractère 1

16 + 2 + 1 = 19 T

Indice 19 dans l'alphabet standard.

1fin d'un octetajouté, pas à vousdifférent en compatible URLPointez un caractère pour voir ses six bits s'additionner.

Comment utiliser le décodeur et l'encodeur Base64

Collez n'importe quoi dans l'unique champ (du texte, du Base64, une data: URI complète ou un JWT), ou cliquez sur Choisir un fichier ou déposez un fichier sur la carte. L'outil détermine le sens, l'indique sur l'étiquette et garde l'autre lecture à un clic.

Au décodage d'un fichier, vous obtenez le type lu dans les octets eux-mêmes, la taille, la taille en pixels d'une image, l'onglet Aperçu pour une image ou un PDF, et un téléchargement avec la bonne extension. À l'encodage, vous obtenez le Base64, une data: URI prête à l'emploi et ce que l'encodage coûte en taille. Les options Alphabet, Remplissage et Retours à la ligne sous le résultat modifient la sortie.

Décodeur Base64 : du Base64 collé, décodé en document PDF, avec son type, sa taille et le schéma 3 octets → 4 caractèresDécodeur Base64 : du Base64 collé, décodé en document PDF, avec son type, sa taille et le schéma 3 octets → 4 caractèresUn seul champ, dans les deux sensCollez du texte, du Base64, une data: URI ou un JWT. L'étiquette indique comment c'est lu ; le menu permet de le changer.Choisir un fichierOu déposez-en un n'importe où sur la carte : il devient du Base64 et une data: URI, sans quitter l'onglet.Ce que sont les octetsAu décodage, le résultat s'ouvre sur le type, la taille et la signature du fichier, puis un aperçu et un téléchargement.Options de sortieAlphabet standard ou compatible URL, avec ou sans remplissage, et lignes coupées pour MIME ou PEM.3 octets → 4 caractèresVos propres octets, redécoupés en groupes de six. Pointez un caractère pour voir ses bits s'additionner.
L'outil en train de décoder un PDF. Sélectionnez un numéro pour voir à quoi sert chaque partie.

Qu'est-ce que le Base64, et pourquoi existe-t-il ?

Le Base64 écrit n'importe quels octets avec 64 caractères qui passent partout : A–Z, a–z, 0–9, + et /. Il existe parce que l'e-mail, les URL, le JSON et le XML ont été conçus pour du texte, et qu'un octet brut peut être un code de contrôle, un guillemet ou un octet nul qui les casse.

Il prend trois octets à la fois, aligne leurs 24 bits et coupe la rangée en quatre groupes de six. Six bits donnent 64 valeurs : chaque groupe désigne donc exactement un caractère. Trois octets en entrée, quatre caractères en sortie, à chaque fois : c'est pourquoi le Base64 est environ un tiers plus gros que ce qui y est entré.

Man → TWFu
M77 · 4DOctet 1
a97 · 61Octet 2
n110 · 6EOctet 3
1922546TWFu

Trois octets font 24 bits. Base64 les redécoupe en quatre groupes de six, et chaque groupe désigne l'un des 64 caractères imprimables : trois octets coûtent donc toujours quatre caractères. C'est de là que vient la hausse de 33 %.

Ma → TWE=
M77 · 4DOctet 1
a97 · 61Octet 2
pas d'octet—Octet 3
19224—TWE=

Deux octets font 16 bits. Base64 ajoute 2 bits à zéro pour compléter le troisième groupe, et un = tient la place du quatrième caractère.

M → TQ==
M77 · 4DOctet 1
pas d'octet—Octet 2
pas d'octet—Octet 3
1916——TQ==

Un octet fait 8 bits. Base64 ajoute 4 bits à zéro pour compléter le deuxième groupe, et deux = tiennent la place des troisième et quatrième caractères. = ne porte aucun bit.

Les lignes blanches marquent l'endroit où un octet finit et où le suivant commence. Elles ne tombent pas sur les limites des groupes de six, et ce décalage est tout le mécanisme. Source: RFC 4648 §4

Comment convertir du Base64 en PDF ?

Collez la chaîne et l'outil reconstitue le PDF : il affiche la version et la taille, ouvre le document dans la visionneuse PDF de votre navigateur et vous propose un téléchargement. Inutile de préciser qu'il s'agit d'un PDF ou de retirer d'abord un préfixe data:.

Un PDF se reconnaît à ses cinq premiers octets, %PDF- : le fichier est donc identifié même quand son nom, le type annoncé par l'expéditeur ou le champ d'où il vient disent autre chose. Si les octets ne sont pas un PDF, la page dit ce qu'ils sont au lieu d'échouer à ouvrir un document qui n'a jamais existé.

Le fichier est reconstitué dans votre navigateur. Rien n'est envoyé, ce qui compte quand le PDF est une fiche de paie, un contrat ou une facture.

Du JSON venant d'une API"document": "JVBERi0xLjcKJeLjz9MKMS…"Un champ dans une réponse. Les guillemets ne font pas partie du Base64.
Une pièce jointe d'e-mailContent-Transfer-Encoding: base64MIME coupe le corps à 76 caractères par ligne. Collez-le avec les retours à la ligne : ils sont ignorés.
Une data: URIdata:application/pdf;base64,JVBERi0x…Collez-la en entier. Le préfixe est lu, pas retiré à la main.
Les premiers octets disent ce que c'est
  1. 25%
  2. 50P
  3. 44D
  4. 46F
  5. 2D-
  6. 311
  7. 2E.
  8. 377

Les 5 premiers octets, %PDF-, forment la signature entière. Les octets 6 à 8 sont la version : 1.7. Aucune extension de fichier n'entre en jeu : un PDF que quelqu'un a nommé .txt revient quand même en PDF.

Trois endroits d'où l'on copie un PDF en Base64, et les octets qui l'identifient une fois décodé. Source: ISO 32000-1:2008 §7.5.2, RFC 8118 §8

Comment encoder une image en Base64, et quand le faire ?

Déposez l'image et vous obtenez son Base64 et une data: URI prête à coller dans du HTML ou du CSS. Savoir s'il faut le faire est la vraie question : le Base64 coûte toujours environ un tiers de plus, et une image intégrée ne peut pas être mise en cache à part.

Dans l'autre sens, du Base64 en image, vous obtenez le format, la taille et la vraie taille en pixels, lue dans l'en-tête du fichier lui-même et non dans l'image à l'écran, ainsi qu'un téléchargement avec la bonne extension.

  • Le fichier sur le disque12,9 ko 100 %
  • En Base6417,3 ko +33,4 %
  • Coupé à 76 caractères pour MIME17,5 ko +35,1 %
  • Le fichier, compressé en gzip11,7 ko -9,5 %
  • Le Base64, compressé en gzip12,5 ko -3,2 %
Un vrai fichier
  • téléchargé une fois
  • mis en cache par le navigateur et le CDN
  • chargé à côté de la page, pas dedans
La même image intégrée
  • un tiers plus lourde avant compression
  • mise en cache seulement avec le fichier qui la contient
  • analysée avec la feuille de style ou le HTML

La compression en récupère l'essentiel : compressé en gzip, le Base64 n'est que 7 % plus lourd que le fichier compressé. Ce qu'elle ne peut pas rendre, c'est l'entrée de cache propre à l'image : intégrée dans une page HTML, elle est retéléchargée avec chaque page qui la contient.

La règle empirique : intégrez quelques centaines d'octets (une icône, un espaceur, un logo dans un e-mail) et liez tout ce qui est plus gros. Cette image PNG de 12,9 ko a déjà franchi la limite.

Mesuré sur l'image que décode l'exemple de l'outil : les mêmes octets, transportés de cinq façons, compressés en gzip au niveau le plus élevé. Source: RFC 2045 §6.8

Base64 ou Base64 compatible URL : quelle différence ?

Le Base64 compatible URL (RFC 4648 §5) est le même encodage avec deux caractères échangés : + devient - et / devient _. Le remplissage est souvent omis aussi.

Utilisez-le partout où le résultat va dans une URL, un nom de fichier ou un cookie. Les JSON Web Tokens l'utilisent d'un bout à l'autre, c'est pourquoi les parties d'un jeton ne finissent jamais par =. Cet outil lit les deux alphabets et vous signale quand une chaîne contient les deux.

Standard (RFC 4648 §4)+/8=
Compatible URL (RFC 4648 §5)-_8=
base64url dans un JWT (RFC 7515 §2)-_8
  • + → -Indice 62. Dans une chaîne de requête, un décodeur de formulaire lit + comme une espace, et les données reviennent fausses.
  • / → _Indice 63. Dans un chemin, / ouvre un nouveau segment, et la valeur est coupée en deux.
  • = suppriméDans une URL, = est généralement encodé en pourcent sous la forme %3D (RFC 4648 §5). Un JWT le supprime complètement (RFC 7515 §2) : la longueur seule indique où finissent les octets.

Les 62 premiers caractères des deux alphabets sont identiques : c'est pourquoi un outil qui lit les deux alphabets peut décoder l'un comme l'autre, et pourquoi cette page vous signale quand une chaîne contient les deux.

Seuls 2 caractères diffèrent entre les deux alphabets. Tout le reste est identique. Source: RFC 4648 §5, RFC 7515 §2

Le Base64 est-il un chiffrement ? Non.

Le Base64 ne cache rien. Il n'y a ni clé ni secret, et l'inverser ne demande aucun effort : un décodeur comme celui-ci le fait pendant que vous tapez.

C'est avec l'authentification HTTP Basic que cela compte le plus : l'en-tête transporte le nom d'utilisateur et le mot de passe sous la forme d'une seule chaîne Base64, lisible par quiconque la voit, et c'est pourquoi la RFC 7617 ne considère cette authentification comme sûre que sur une connexion chiffrée comme TLS. Si quelque chose doit rester illisible, il faut un chiffrement. Le Base64 ne fait que transporter des octets sans dommage à travers un canal conçu pour du texte.

Un en-tête Authorization, tel que le construit la RFC 7617 §2

Authorization: Basic dXNlcjpwYXNzd29yZA==

Une étape en arrière : aucune clé nécessaire, aucun mot de passe nécessaire

user:password

La RFC 7617 construit l'en-tête étape par étape, et la dernière étape est toute sa « protection » : le client « obtient les basic-credentials en encodant cette séquence d'octets en Base64 ». Son §1 dit ce que cela signifie : à moins que TLS ou un système similaire ne protège la connexion, « l'identifiant de l'utilisateur et le mot de passe sont transmis sur le réseau en clair ». Base64 n'a pas de clé, il n'y a donc rien à casser : quiconque a la chaîne a le mot de passe.

Les identifiants ci-dessus sont inventés. Les relire prend une étape et aucune clé : voilà ce que veut dire « un encodage, pas un chiffrement ». Source: RFC 7617 §2, §1

Pourquoi mon texte décodé affiche-t-il des caractères bizarres (mojibake) ?

Parce que le Base64 transporte des octets, et que les octets ne deviennent des lettres qu'une fois un encodage de caractères choisi. Lisez de l'UTF-8 comme si c'était de l'ISO-8859-1 et é devient é ; lisez de l'ISO-8859-1 comme de l'UTF-8 et il devient un caractère de remplacement.

Une data: URI peut déclarer son charset, et cette page lit le texte dans ce charset au lieu de tout forcer en UTF-8. Si votre navigateur n'a pas de décodeur pour celui qui est déclaré, la page le dit au lieu de vous montrer discrètement les mauvaises lettres.

« Café » écrit en UTF-8436166C3A9
« Café » écrit en ISO-8859-1436166E9

En UTF-8, é occupe 2 octets ; en ISO-8859-1, 1 octet. Base64 transporte des octets, pas des lettres : la chaîne elle-même ne peut pas dire à un décodeur lequel était voulu.

Lu correctementCafé
Octets UTF-8 lus en ISO-8859-1Café
Octets ISO-8859-1 lus en UTF-8Caf�
Le mojibake prend deux formes : du charabia lisible (Café) quand de l'UTF-8 est lu comme une page de code à un octet, et un caractère de remplacement (Caf�) quand les octets ne sont pas du tout de l'UTF-8 valide. Source: RFC 4648 §4, RFC 2397 §4

Le Base64 en Python, JavaScript, Java, C#, Go, PowerShell et dans le shell

Tous les langages intègrent le Base64. Les pièges sont partout les mêmes : encodez des octets, pas une chaîne, et précisez dans quel encodage de caractères est le texte.

Le btoa() de JavaScript est le point le plus délicat : il n'accepte que les caractères jusqu'à U+00FF, donc tout ce qui dépasse le Latin-1 doit d'abord devenir des octets UTF-8 avec TextEncoder. Chaque exemple ci-dessous encode et décode « Man » et a été exécuté pour vérifier sa sortie.

import base64

b64 = base64.b64encode("Man".encode("utf-8")).decode("ascii")
print(b64)                                    # TWFu
print(base64.b64decode(b64).decode("utf-8"))  # Man

Exécuté avec Python 3.14.4 le 26 octobre 2026 : le code affiche ce que montrent les commentaires.

Chaque extrait a été exécuté sur « Man » et affiche ce que montrent ses commentaires. Le base64 -d du shell s'écrit -D sur les anciennes versions de macOS. Source: gnu.org, developer.mozilla.org

L'alphabet Base64, de 0 à 63

Chaque groupe de six bits est un nombre de 0 à 63, et voici la table où il est cherché. Le Base64 est sensible à la casse : A vaut 0 et a vaut 26, donc changer la casse d'une lettre casse la chaîne.

Cela vaut la peine de le reconnaître à l'œil : une suite de A est une suite d'octets nuls, et une chaîne Base64 qui commence par JVBER est un PDF, par iVBOR un PNG et par /9j/ un JPEG.

  1. A0
  2. B1
  3. C2
  4. D3
  5. E4
  6. F5
  7. G6
  8. H7
  9. I8
  10. J9
  11. K10
  12. L11
  13. M12
  14. N13
  15. O14
  16. P15
  17. Q16
  18. R17
  19. S18
  20. T19
  21. U20
  22. V21
  23. W22
  24. X23
  25. Y24
  26. Z25
  27. a26
  28. b27
  29. c28
  30. d29
  31. e30
  32. f31
  33. g32
  34. h33
  35. i34
  36. j35
  37. k36
  38. l37
  39. m38
  40. n39
  41. o40
  42. p41
  43. q42
  44. r43
  45. s44
  46. t45
  47. u46
  48. v47
  49. w48
  50. x49
  51. y50
  52. z51
  53. 052
  54. 153
  55. 254
  56. 355
  57. 456
  58. 557
  59. 658
  60. 759
  61. 860
  62. 961
  63. +Compatible URL : -62
  64. /Compatible URL : _63

0–25 sont A–Z, 26–51 sont a–z, 52–61 sont 0–9. Seuls les deux derniers caractères de la table diffèrent entre les deux alphabets, signalés ci-dessus. = n'est pas du tout dans la table : ce n'est pas une valeur, c'est la marque qui indique que le dernier groupe de trois octets était court.

Les 64 caractères, dans l'ordre que donne la RFC 4648 §4. Le nombre sous chacun est la valeur sur six bits qu'il représente. Source: RFC 4648 §4

Base64 : questions et réponses

Que veut dire décoder du Base64 (« Base64 decode ») ?

Décoder du Base64 transforme chaque groupe de quatre caractères en les trois octets qu'il représente. Ces octets peuvent être du texte, ou un fichier entier comme un PDF, une image PNG ou une archive ZIP. Cet outil lit les premiers octets pour savoir lequel, puis vous montre le texte ou le fichier lui-même plutôt qu'un écran de symboles, et vous permet de le télécharger.

Comment décoder un fichier Base64 ?

Collez la chaîne Base64 dans le champ. L'outil la décode, compare les premiers octets aux signatures de fichiers qu'il connaît (33 formats de fichier au total), nomme le format, affiche l'aperçu d'une image ou d'un PDF et vous propose un téléchargement avec la bonne extension. Vous n'avez jamais à dire de quel type de fichier il s'agit, et rien n'est envoyé pour le savoir.

À quoi sert le Base64 ?

Il fait passer des octets là où seul du texte est prévu : pièces jointes d'e-mail (MIME), data: URI dans le HTML et le CSS, champs binaires dans le JSON et le XML, JSON Web Tokens, authentification HTTP Basic, certificats et clés dans les fichiers PEM. Dans chaque cas, les données doivent traverser un canal qui pourrait modifier ou perdre des octets bruts : elles voyagent donc en simples lettres et chiffres.

Le Base64 est-il un chiffrement ?

Non. Le Base64 est un encodage, pas un chiffrement : il n'a ni clé ni secret, et n'importe qui peut l'inverser en un instant, comme le fait cette page pendant que vous tapez. Considérez tout ce qui est écrit en Base64 comme visible de tous. Si des données doivent rester privées, chiffrez-les d'abord, puis encodez les octets chiffrés en Base64 s'ils doivent voyager sous forme de texte.

Est-il sûr de décoder du Base64 en ligne ?

Sur cette page, oui, et vous pouvez le vérifier : tout est décodé par JavaScript dans votre propre onglet, et rien de ce que vous collez ou déposez n'est envoyé. Le HTML, le SVG et les scripts décodés sont affichés comme texte, jamais exécutés ; une image ou un PDF est affiché par la visionneuse de votre navigateur. Ouvrez l'onglet Réseau des outils de développement pendant que vous l'utilisez : aucune requête ne transporte vos données.

Pourquoi le Base64 est-il 33 % plus gros que l'original ?

Parce que chaque groupe de trois octets devient quatre caractères, et quatre divisé par trois donne 1,33. Jusqu'à deux caractères de remplissage = peuvent s'ajouter à la fin, et couper les lignes à 76 caractères pour l'e-mail ajoute un retour à la ligne à chaque ligne : une longue chaîne est donc souvent environ 35 % plus grosse que les octets qu'elle transporte. Une compression comme gzip en récupère l'essentiel.

Qu'est-ce que le Base64 compatible URL ?

C'est du Base64 où + est remplacé par - et / par _, comme le définit la RFC 4648 §5, pour que le résultat puisse aller dans une URL, un nom de fichier ou un cookie sans être échappé. Le remplissage est généralement supprimé aussi, comme dans les JSON Web Tokens. Cet outil lit les deux alphabets, même mélangés dans une seule chaîne, et peut écrire l'un ou l'autre.

Pourquoi mon décodage Base64 échoue-t-il ?

Presque toujours à cause d'un seul caractère absent de l'alphabet Base64 : des points de suspension là où une messagerie a coupé la chaîne, un guillemet typographique venu d'un traitement de texte ou une espace insécable venue d'un PDF. Cet outil nomme le caractère, le montre à sa place avec sa position, vous dit ce qui s'est décodé proprement avant lui et propose « Le retirer et décoder » quand le reste peut encore être décodé.

Peut-on convertir du Base64 en image ?

Oui. Collez la chaîne, avec ou sans préfixe comme data:image/png;base64,, et l'image apparaît avec son format, sa taille et sa vraie taille en pixels, lue dans l'en-tête du fichier lui-même. Téléchargez-la ensuite avec la bonne extension. PNG, JPEG, GIF, WebP, BMP, ICO et AVIF sont prévisualisés ; un SVG est d'abord affiché comme texte, car un SVG peut contenir du script.

Que signifie le = à la fin d'un Base64 ?

Il signifie que le dernier groupe de trois octets était incomplet. Deux octets restants donnent trois caractères et un =, un octet restant donne deux caractères et ==. Le remplissage ne porte aucune donnée : il indique seulement à un décodeur où finissent les octets. Beaucoup de décodeurs, dont celui-ci, lisent aussi le Base64 dont le remplissage a été omis.

Y a-t-il une limite de taille ?

Un fichier choisi ou déposé peut peser jusqu'à 10 Mo ; un fichier plus gros est refusé avec son nom et sa taille, jamais lu à moitié. La limite pour le texte collé est de 14 349 002 caractères : assez pour le Base64 d'un fichier de 10 Mo avec ses retours à la ligne, si bien que tout ce que l'outil encode peut être décodé à nouveau. Les grosses entrées sont lues en arrière-plan, pour que la saisie reste fluide.

Puis-je décoder un JWT ici ?

Oui. Collez le jeton : son en-tête et sa charge utile s'affichent en JSON mis en forme, avec les dates à côté des revendications iat et exp, et la signature sous forme d'octets. Cette page ne fait que décoder les trois parties base64url : elle ne vérifie pas la signature et ne dit jamais qu'un jeton est valide. Ne vous en servez donc pas pour décider de faire confiance à un jeton.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil