Encodeur et Décodeur Base64

Introduction

L'Encodeur et Décodeur Base64 est un outil gratuit en ligne pour convertir du texte en Base64 et décoder du Base64 en texte. Les deux opérations se produisent en temps réel pendant la saisie, sans rechargement de page ni bouton d'envoi. L'outil s'exécute entièrement dans votre navigateur — rien n'est envoyé à un serveur.

Deux sections indépendantes se trouvent sur la même page : une pour encoder, une pour décoder. Chacune a sa propre zone de texte, zone de chargement et boutons d'action, afin que vous puissiez travailler dans les deux directions sans changer de mode.

Qu'est-ce que Base64 ?

Base64 est une façon de représenter des données binaires en utilisant uniquement des caractères ASCII imprimables. Ce n'est pas un schéma de chiffrement ou de compression — son but est de rendre les données binaires sûres à transporter sur des systèmes conçus pour le texte.

Comment fonctionne l'encodage

L'alphabet Base64 utilise 64 caractères :

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

Le processus d'encodage divise l'entrée en groupes de 3 octets (24 bits), puis divise chaque groupe en quatre valeurs de 6 bits. Chaque valeur de 6 bits (0–63) est attribuée à un caractère de l'alphabet.

Entrée :      F   o   o
Binaire :     01000110 01101111 01101111
6 bits :      010001 100110 111101 101111
Décimal :     17     38     61     47
Base64 :      R     b    9     v
}

"Foo" est encodé en `Rm9v`.

### Pourquoi 64 ?

64 a été choisi car c'est la plus grande puissance de deux qui utilise uniquement des caractères disponibles dans pratiquement tous les jeux de caractères (lettres, chiffres et deux signes de ponctuation). Cela rend Base64 fiable sur les systèmes de messagerie, les charges utiles JSON, les URL et autres canaux textuels qui pourraient altérer ou rejeter les octets non ASCII.

Chaque caractère Base64 transporte 6 bits d'information, contre 8 bits par octet. Ce rapport 6 pour 8 explique pourquoi la sortie encodée est environ 33 % plus grande que l'entrée d'origine — un sujet traité plus en détail plus loin.

### Quand l'entrée n'est pas un multiple de 3 octets

Si le dernier groupe a moins de 3 octets, du bourrage est ajouté. L'encodeur ajoute des caractères `=` pour rendre la longueur de sortie un multiple de 4 :

- 1 octet restant → 2 caractères Base64 + `==`
- 2 octets restants → 3 caractères Base64 + `=`
- 3 octets complets → 4 caractères Base64, pas de bourrage

Par exemple, "Fo" (2 octets) est encodé en `Rm8=`.

### Une note sur ce que Base64 n'est pas

Base64 est souvent confondu avec le chiffrement car la sortie ressemble à du charabia. Un décodage rapide révèle le texte original sans aucune clé. Si vous devez protéger des données, utilisez un algorithme de chiffrement approprié (AES, ChaCha20, etc.) puis encodez les octets chiffrés avec Base64 pour le transport. Base64 seul n'offre aucune confidentialité.

## Utilisations courantes de Base64

Base64 apparaît dans de nombreux endroits quotidiens sur le web, souvent sans que les utilisateurs le remarquent.

### Data URIs

Les navigateurs modernes permettent d'intégrer des images, polices et autres médias directement dans le HTML ou le CSS en utilisant des `data:` URIs :

```html
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">

Les données d'image encodées en Base64 vivent dans le fichier HTML lui-même — aucune requête HTTP séparée n'est nécessaire. C'est courant pour les petites icônes, sprites et polices web, où le round-trip HTTP supplémentaire coûterait plus cher que les octets en ligne.

Cependant, les Data URIs Base64 ne sont pas toujours le meilleur choix pour les assets plus volumineux. La surcharge de taille de 33 % signifie qu'une icône de 100 Ko devient 133 Ko de texte en ligne, et le navigateur ne peut pas la mettre en cache séparément de la page HTML. La plupart des sites utilisent les Data URIs uniquement pour les assets de moins de quelques kilo-octets.

JWT et Tokens d'API

Les JSON Web Tokens utilisent Base64url (la variante sécurisée pour les URL) pour encoder les segments d'en-tête, de charge utile et de signature d'un token. Si vous avez déjà inspecté un JWT comme celui-ci :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

chaque segment séparé par des points est du JSON encodé en Base64url. Vous pouvez coller n'importe quel segment dans la section de décodage de cet outil pour inspecter son contenu.

Pièces Jointes d'Email (MIME)

Le courrier électronique a été conçu à l'origine pour l'ASCII 7 bits. Pour envoyer des pièces jointes binaires (images, PDF, feuilles de calcul), la norme MIME les encode en Base64. Votre client de messagerie les décode automatiquement lorsque vous ouvrez le message.

Un détail qui prête parfois à confusion : le Base64 MIME coupe conventionnellement les lignes à 76 caractères. Si vous extrayez des données Base64 d'une source d'email, elles peuvent contenir des sauts de ligne intégrés. Le décodeur de cet outil gère les sauts de ligne automatiquement — vous pouvez coller du Base64 MIME multiligne sans supprimer d'abord les sauts de ligne.

Certificats et Clés PEM

Les certificats SSL/TLS et les clés privées sont distribués au format PEM, qui encapsule des données DER encodées en Base64 entre des lignes d'en-tête et de pied :

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----

Le PEM est essentiellement du Base64 avec une enveloppe étiquetée. Vous pouvez décoder le corps Base64 d'un fichier PEM pour inspecter son contenu DER brut, bien que le résultat soit binaire, pas du texte lisible.

Authentification de Base HTTP

L'en-tête d'authentification de base HTTP encode utilisateur:motdepasse en Base64 :

Authorization: Basic YWRtaW46c2VjcmV0

La chaîne YWRtaW46c2VjcmV0 est l'encodage Base64 de admin:secret. Base64 est ici un mécanisme de sérialisation, pas de sécurité — les identifiants sont trivialement décodables par quiconque voit l'en-tête.

Qu'est-ce qu'un fichier .b64 ?

Un fichier .b64 est un fichier texte brut dont le contenu entier est une chaîne Base64. L'extension .b64 est une convention de nommage qui signale "ce fichier contient des données Base64" — par opposition à du texte arbitraire, du code source ou un format binaire.

Vous pouvez rencontrer des fichiers .b64 lorsque :

• Vous exportez des sorties encodées depuis des outils comme celui-ci
• Vous stockez des clés cryptographiques ou certificats dans un format texte portable
• Vous échangez des données Base64 entre des systèmes utilisant des flux de travail basés sur des fichiers

Comme les fichiers .b64 sont du texte brut, vous pouvez les ouvrir dans n'importe quel éditeur de texte, inspecter le contenu ou copier la chaîne dans un décodeur. Cet outil accepte les fichiers .b64 à la fois dans la section Encoder et Décoder via glisser-déposer ou le sélecteur de fichiers.

Fonctionnement

L'outil utilise les fonctions Base64 natives du navigateur avec une couche supplémentaire pour la sécurité UTF-8.

Conversion Principale

JavaScript fournit deux fonctions natives pour Base64 :

• btoa(entrée) — convertit une chaîne en Base64 (binaire vers ASCII)
• atob(entrée) — convertit Base64 en chaîne (ASCII vers binaire)

Ces fonctions ne fonctionnent qu'avec les caractères Latin-1 (ISO-8859-1). Si vous passez une chaîne contenant des caractères chinois, japonais, emoji ou tout caractère en dehors de la plage Latin-1, btoa() lance une DOMException.

Encodage UTF-8 Sécurisé

Pour traiter correctement tout texte Unicode, l'outil enveloppe les fonctions natives :

function encode(text, urlSafe, noPad) {
  let utf8 = encodeURIComponent(text);
  let base64 = btoa(utf8);
  if (urlSafe) base64 = base64.replace(/\+/g, '-').replace(/\//g, '_');
  if (noPad) base64 = base64.replace(/=+$/, '');
  return base64;
}

function decode(base64) {
  let restored = base64.replace(/-/g, '+').replace(/_/g, '/');
  while (restored.length % 4 !== 0) restored += '=';
  let utf8 = atob(restored);
  return decodeURIComponent(utf8);
}

encodeURIComponent convertit le texte en forme encodée en pourcentage UTF-8, qui ne contient que des caractères ASCII que btoa peut traiter. Le chemin de décodage inverse ceci dans l'ordre opposé.

Pour voir pourquoi c'est important, essayez d'encoder l'emoji "😊" directement avec btoa — cela lance une erreur. Avec l'enveloppe UTF-8, il devient J UmbKSA4bQ, qui se décode correctement en 😊.

Gestion des Entrées Sécurisées pour les URL

La fonction de décodage effectue toujours deux transformations avant de passer la chaîne à atob :

1. Remplacer - par + et _ par / (annulant l'encodage sécurisé pour les URL)
2. Ajouter du bourrage = si la longueur de la chaîne n'est pas un multiple de 4

Cela signifie que vous n'avez jamais besoin de modifier un paramètre côté décodage. Que votre entrée soit du Base64 standard, du Base64 sécurisé pour les URL, avec ou sans bourrage, le décodeur la traite automatiquement.

Flux d'Événements

Lorsque vous tapez ou collez dans une zone de texte, un écouteur d'événement input se déclenche. Le planificateur met en tampon les frappes rapides (débruité à environ 16 ms pour s'aligner sur une image) puis exécute la fonction d'encodage ou de décodage. Le résultat apparaît dans la zone de texte de sortie au prochain rafraîchissement de l'écran.

Base64 Standard vs Base64 Sécurisé pour les URL

Les deux cases à cocher dans la section Encoder correspondent à deux variantes bien définies de Base64.

Base64 Standard (RFC 4648 §4)

Utilise l'alphabet complet : A–Z, a–z, 0–9, +, /. C'est la forme originale et fonctionne partout, sauf là où + et / ont une signification particulière.

Base64 Sécurisé pour les URL (RFC 4648 §5)

Remplace les deux caractères qui posent problème dans les URL :

Le Base64 standard Pz4/Pj8+QA== devient Pz4_Pj8- QA_ sous forme sécurisée pour les URL (note : le bourrage = est également omis dans l'exemple, bien que la version sécurisée pour les URL puisse utiliser du bourrage).

Quand utiliser chaque variante

Le côté décodage de cet outil détecte automatiquement quelle variante a été utilisée, vous pouvez donc coller n'importe quel format sans changer de paramètres.

Un Malentendu Courant

Certains développeurs croient que le Base64 sécurisé pour les URL est un algorithme différent. Ce n'est pas le cas — seuls deux caractères de l'alphabet changent. N'importe quel décodeur Base64 standard peut être adapté en mappant - → + et _ → / avant le traitement, ce qui est exactement ce que cet outil fait côté décodage.

Bourrage dans Base64

Le caractère = à la fin d'une chaîne Base64 est du bourrage — il ne fait pas partie des données encodées.

Pourquoi le bourrage existe

Base64 traite l'entrée par groupes de 3 octets. Si le dernier groupe a moins de 3 octets, l'encodeur ajoute = comme bourrage pour rendre la longueur totale un multiple de 4. Ceci est requis par certains décodeurs et permet de concaténer plusieurs chaînes Base64 sans ambiguïté.

Ce que signifie "sans bourrage"

Lorsque vous activez "Sans bourrage", l'encodeur supprime les caractères = finaux de la sortie. Par exemple :

• Entrée : Fo → Rm8= (avec bourrage) → Rm8 (sans bourrage)
• Entrée : Foo → Rm9v (pas de bourrage dans les deux cas — multiple exact de 3)

De nombreux systèmes modernes acceptent le Base64 sans bourrage, et le décodeur de cet outil le gère toujours. Activez cette option lorsque le système auquel vous envoyez la sortie n'exige pas ou ne veut pas de bourrage.

Matrice d'Interopérabilité

La section de décodage de cet outil accepte les quatre combinaisons automatiquement :

Il n'y a pas de paramètre à ajuster. Le décodeur normalise l'entrée avant le traitement.

Quand le bourrage est requis

Certains systèmes exigent strictement du bourrage, notamment :

• Data URIs : data:image/png;base64,... — l'analyseur du navigateur attend du Base64 correctement bourré.
• Anciennes bibliothèques Base64 : Certaines implémentations rejettent complètement les entrées sans bourrage.

Si vous n'êtes pas sûr que le système cible nécessite du bourrage, laissez-le activé (par défaut). Supprimer le bourrage n'est sûr que lorsque vous contrôlez à la fois l'encodeur et le décodeur.

Base64 vs Autres Schémas d'Encodage

Base64 est l'un des plusieurs schémas d'encodage binaire-vers-texte, chacun avec différents compromis en densité, taille d'alphabet et cas d'utilisation.

Pourquoi Base64 est le plus populaire

Base64 atteint le point idéal pour la plupart des applications pratiques. Comparé à Hex — qui double la taille d'entrée — la surcharge de 33 % de Base64 est significativement plus efficace. Comparé à Base85, Base64 est plus simple à implémenter (chaque langage a un décodeur intégré), et son alphabet évite les problèmes de citation que les caractères Base85 comme " et \ peuvent causer dans certains contextes.

Quand utiliser autre chose

• Hex : Quand la lisibilité humaine et le débogage importent plus que la taille. Une chaîne Hex comme 4f6f est instantanément reconnaissable comme des données encodées ; b293 est moins évident comme Base64.
• Base32 : Quand la sensibilité à la casse n'est pas souhaitée (par exemple, pour dicter au téléphone, imprimé sur des produits). Base32 utilise uniquement des lettres majuscules et des chiffres.
• Base85 : Quand chaque octet de surcharge compte dans un canal restreint et que vous contrôlez les deux extrémités du pipeline.

Pour l'encodage web général, Base64 reste le choix par défaut correct. Cet outil suit cette convention.

Performance et Considérations de Taille

Base64 est simple et universel, mais il a des coûts réels qui comptent lorsque vous travaillez avec des données plus volumineuses.

La Surcharge de 33 %

Tous les 3 octets d'entrée deviennent 4 octets de sortie, un rapport 4:3. En pratique, y compris le bourrage et les sauts de ligne, la surcharge est d'environ 37 % pour les petites entrées et se stabilise à 33 % pour les entrées suffisamment grandes.

Base64 et Compression

La compression Gzip (ou Brotli) du texte Base64 est généralement inefficace. La sortie Base64 a une distribution de caractères uniforme — chacun des 64 caractères apparaît avec à peu près la même fréquence — ce qui élimine les motifs qu'exploitent les algorithmes de compression. Une chaîne Base64 compressée n'est souvent que 5 à 10 % plus petite que la forme non compressée, contre une réduction de 60 à 80 % réalisable avec les données binaires d'origine.

Cela signifie :

• Ne faites pas d'encodage Base64 avant de compresser. Compressez d'abord, puis encodez si nécessaire.
• Ne comptez pas sur la compression au niveau du transport (par exemple, HTTP gzip) pour compenser la surcharge Base64. Elle ne le fera pas.

Quand ne pas utiliser Base64

Base64 a du sens lorsque vous devez faire entrer des données binaires dans un canal texte uniquement. Si le canal prend en charge le transfert binaire nativement, évitez Base64 :

• Téléchargements de fichiers : Utilisez multipart/form-data avec du binaire brut, pas du Base64 dans du JSON. Le fichier arrive au serveur 33 % plus gros et prend plus de temps à télécharger.
• Stockage en base de données : Stockez les données binaires en BYTEA (PostgreSQL), BLOB (MySQL/SQLite) ou varbinary (MSSQL) plutôt qu'en texte Base64.
• Appels API entre services : Utilisez gRPC, Thrift ou MessagePack avec des champs binaires plutôt que des chaînes JSON encodées en Base64.

Pour les charges utiles textuelles (charges utiles JWT, contenu HTML, corps d'email), la surcharge est négligeable et la commodité de Base64 vaut le compromis.

Implications de Mise en Cache

Lorsque vous intégrez une Data URI Base64 dans du HTML ou CSS, le contenu encodé fait partie de la ressource de la page. Le navigateur ne peut pas mettre cette Data URI en cache indépendamment — toute modification de la page l'invalide. Un fichier image séparé demandé via <img src="icon.png"> peut être mis en cache entre les pages avec un en-tête Cache-Control lointain. Pour les assets de plus de quelques kilo-octets, les fichiers séparés sont presque toujours plus performants.

Erreurs Courantes et Idées Reçues

Base64 est simple, mais plusieurs malentendus récurrents causent de véritables erreurs.

Base64 N'est Pas du Chiffrement

C'est l'idée reçue la plus courante. Parce que la sortie Base64 ressemble à des caractères aléatoires, de nombreux développeurs supposent qu'elle offre un certain niveau de protection. Ce n'est pas le cas. Le décodage ne nécessite ni clé ni secret. Traitez toute chaîne Base64 comme du texte publiquement lisible.

Si vous voyez un service stocker des mots de passe ou des clés d'API en Base64, traitez-le comme un problème de sécurité — les données sont stockées en texte clair.

Sensibilité à la Casse

L'alphabet Base64 distingue les majuscules et les minuscules :

• Majuscules : A–Z (valeurs 0–25)
• Minuscules : a–z (valeurs 26–51)

Une faute de frappe comme R vs r change complètement la valeur décodée. Si votre sortie décodée semble incorrecte, vérifiez la présence d'erreurs de casse dans l'entrée.

Sauts de Ligne MIME

Les pièces jointes d'email encodées en MIME coupent le corps Base64 tous les 76 caractères :

SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdCBvZi BiYXNlNjQgZW5jb2Rpbmcu
VGhpcyBpcyB0aGUgc2Vjb25kIGxpbmUu

Tous les décodeurs Base64 ne gèrent pas ces sauts de ligne intégrés. Cet outil le fait — collez le Base64 MIME multiligne directement sans prétraitement. Un décodeur qui ne gère pas les sauts de ligne produira un résultat altéré ou une erreur.

Espaces Blancs Cachés

Copier du texte depuis des emails, PDF ou pages web peut introduire des caractères d'espacement invisibles (espaces, tabulations, espaces de largeur nulle, espaces insécables). Ce ne sont pas du Base64 valide. Si une chaîne Base64 d'apparence valide ne se décode pas, collez-la d'abord dans un éditeur de texte brut pour vérifier les caractères cachés, ou recopiez-la depuis la source.

Concaténation de Chaînes avec Bourrage

Deux chaînes Base64 avec bourrage concaténées directement ne se décodent pas nécessairement correctement. Le bourrage = appartient au dernier groupe de chaque chaîne, et la concaténation peut créer des limites ambiguës. C'est intentionnel — le bourrage empêche l'ambiguïté pour les chaînes individuelles. Pour les données en plusieurs parties, traitez chaque partie séparément.

Utilisation

L'utilisation de l'Encodeur et Décodeur Base64 ne nécessite aucune configuration, inscription ni compte.

Encoder du Texte en Base64

1. Dans la section Encoder en Base64, tapez ou collez votre texte dans la zone de texte d'entrée.
2. La zone de sortie se met automatiquement à jour avec le résultat encodé.
3. Activez optionnellement Sécurisé pour les URL pour utiliser la variante web sécurisée, ou Sans bourrage pour supprimer les caractères = finaux.
4. Cliquez sur Copier pour copier le texte encodé dans le presse-papiers, ou Télécharger le Base64 pour le sauvegarder en fichier .b64.

Décoder du Base64 en Texte

1. Dans la section Décoder le Base64, collez une chaîne Base64 dans la zone d'entrée.
2. Le texte décodé apparaît dans la zone de sortie instantanément.
3. Si l'entrée n'est pas un Base64 valide, un message d'erreur s'affiche.
4. Cliquez sur Copier ou Télécharger pour sauvegarder le résultat décodé.

Utiliser le Chargement de Fichiers

• Section Encoder : déposez un fichier .txt sur la zone de chargement pour charger son contenu à encoder.
• Section Décoder : déposez un fichier .b64 ou .txt pour charger du contenu Base64 à décoder.

Le contenu du fichier est lu, placé dans la zone de texte d'entrée et traité immédiatement.

Tutoriel

Scénario : Vous construisez une application web qui communique avec une API. L'API s'attend à ce que la charge utile de la requête inclue un champ texte court encodé en Base64 sécurisé pour les URL sans bourrage. Vous devez encoder votre texte, vérifier la sortie et confirmer que l'API l'accepte. Plus tard, vous recevez une réponse de la même API avec un champ encodé en Base64 que vous devez décoder.

Ce tutoriel vous guide à travers le parcours complet.

Partie 1 : Encoder

1. Ouvrez l'Encodeur et Décodeur Base64 dans votre navigateur. Vous voyez deux sections côte à côte — Encoder à gauche, Décoder à droite.

2. Dans la zone d'entrée Encoder, tapez le texte suivant :

   Bonjour, serveur API. Voici ma charge utile.
   

   La zone de sortie affiche immédiatement l'encodage Base64 standard. Le résultat commence par Qm9uam91ciwg. Jusqu'ici tout va bien.

3. La spécification de l'API exige du Base64 sécurisé pour les URL sans bourrage. Activez les deux cases Sécurisé pour les URL et Sans bourrage. Observez le changement de la sortie :

   • Les caractères + (s'il y en a) deviennent -
   • Les caractères / deviennent _
   • Les caractères = finaux disparaissent

4. Cliquez sur Copier pour copier le résultat encodé dans votre presse-papiers. Collez-le dans la charge utile de votre requête API.

Partie 2 : Décoder

5. L'API répond avec une charge utile JSON contenant un champ encodé en Base64 :

   {
     "status": "ok",
     "message": "eyJzdWIiOiAiMTAwMSIsICJuYW1lIjogIkFQSSBHYXRld2F5In0="
   }
   

6. Copiez la valeur de message et collez-la dans la zone d'entrée Décoder.

   La zone de sortie affiche instantanément le texte décodé :

   { "sub": "1001", "name": "API Gateway" }
   

7. La charge utile JSON de type JWT est maintenant lisible. Si l'API avait utilisé du Base64 sécurisé pour les URL (pas de + ou / dans la chaîne, ou avec - et _), le décodeur l'aurait traité automatiquement.

Partie 3 : Flux de Travail Basé sur des Fichiers

8. Supposons que vous deviez envoyer la charge utile encodée à un collègue qui préfère les fichiers. Cliquez sur Télécharger le Base64 dans la section Encoder. La boîte de dialogue Enregistrer sous de votre navigateur s'ouvre, suggérant download.b64 comme nom de fichier. Sauvegardez le fichier.

9. Votre collègue reçoit le fichier et ouvre ce même outil. Il fait glisser download.b64 sur la zone de chargement de la section Décoder. Le contenu du fichier apparaît dans la zone d'entrée, et le texte décodé apparaît immédiatement.

Ce parcours — encoder avec options → copier ou télécharger → décoder avec détection automatique — couvre le flux de travail réel le plus courant. L'outil gère toute la normalisation pour que vous n'ayez pas à penser aux variantes de caractères ou aux règles de bourrage.

Conseils d'Expert

• Encodez et décodez simultanément : Les deux sections sont indépendantes. Vous pouvez taper du texte dans la section Encoder et coller une chaîne Base64 séparée dans la section Décoder en même temps. Utilisez ceci pour comparer l'entrée et la sortie des deux directions côte à côte.

• Sécurisé pour les URL pour les JWT : Lorsque vous travaillez avec des tokens JWT, activez toujours le mode sécurisé pour les URL. Les segments JWT utilisent la variante sécurisée pour les URL (RFC 7515). Si vous collez un segment JWT dans la section de décodage, l'outil détecte les caractères sécurisés pour les URL automatiquement.

• Supprimez les espaces avant de coller : Certaines sources de données Base64 incluent des sauts de ligne ou espaces finaux. Le décodeur traite mieux les entrées nettoyées. Si vous voyez une erreur "Chaîne Base64 invalide", vérifiez si le texte collé contient des espaces supplémentaires.

• Téléchargez pour les sorties volumineuses : Pour les longues chaînes Base64, utilisez les boutons Télécharger au lieu de Copier. La boîte de dialogue Enregistrer sous native vous permet de choisir où sauvegarder le fichier, et le résultat est sauvegardé en fichier .b64 ou .txt que vous pouvez transférer ou archiver.

• Chargez comme alternative à la saisie : Si vous avez déjà un fichier contenant le texte ou les données Base64, faites-le glisser sur la zone de chargement. C'est plus rapide que d'ouvrir le fichier, tout sélectionner, copier et coller — surtout pour les fichiers volumineux.

• Décodez d'abord pour vérifier le format : Si vous recevez une chaîne Base64 et n'êtes pas sûr qu'elle contienne du texte ou des données binaires, collez-la dans la section de décodage. Si la sortie est du texte lisible, vous avez terminé. Si elle contient des caractères altérés ou des glyphes de remplacement ( ), la source originale était probablement binaire (une image, un PDF ou un autre format non textuel).

Alternatives

Il existe plusieurs autres façons d'encoder ou de décoder du Base64, chacune avec différents compromis.

Pour encoder ou décoder du texte Base64 avec confidentialité, retour en temps réel et sans connaissance de la ligne de commande, cet outil offre la meilleure expérience utilisateur.

Confidentialité des Données

L'Encodeur et Décodeur Base64 traite chaque caractère entièrement dans votre navigateur. Aucun texte que vous entrez n'est transmis à un serveur, stocké dans une base de données ou journalisé dans un système.

Toute la conversion est effectuée en utilisant les fonctions natives btoa() et atob() de JavaScript dans la mémoire du navigateur. La page n'inclut aucun script d'analyse, pixel de suivi ou contenu intégré tiers. Aucun cookie, entrée localStorage ou sessionStorage n'est créé ou lu.

Après le chargement initial de la page, l'outil fonctionne entièrement hors ligne. Vous pouvez vous déconnecter d'Internet et continuer à encoder et décoder sans interruption. Vérifiez-le en utilisant l'outil en mode avion ou en inspectant l'activité réseau dans les outils de développement de votre navigateur — aucune requête ne quitte votre appareil après le chargement de la page.

Dépannage

Spécifications Techniques

• Algorithme Principal : btoa() / atob() enveloppé avec encodeURIComponent / decodeURIComponent pour la sécurité UTF-8
• Norme : RFC 4648 §4 (Base64 standard), RFC 4648 §5 (Base64 sécurisé pour les URL)
• Gestion d'entrée : Conversion automatique des caractères sécurisés pour les URL (- → +, _ → /) et normalisation du bourrage au décodage
• Traitement en Temps Réel : Écouteur d'événement input sur les zones de texte, débruité à environ une image (16 ms)
• E/S Fichiers : API FileReader pour le chargement, showSaveFilePicker (File System Access API) avec repli <a download>
• Formats de Téléchargement : .b64 (encodé), .txt (décodé)
• Formats de Chargement : .txt (section Encoder), .b64 / .txt (section Décoder)

Benchmarks de Performance

Mesuré sur un ordinateur portable milieu de gamme de 2020 (Chrome 120). Les performances évoluent linéairement avec la taille d'entrée. Pour les charges utiles texte typiques de moins de 100 Ko, la conversion est pratiquement instantanée.

Compatibilité des Navigateurs

showSaveFilePicker nécessite les navigateurs basés sur Chromium (Chrome, Edge, Opera, Samsung Internet). Dans Firefox et Safari, le téléchargement utilise automatiquement la méthode <a download> comme repli.

Confidentialité et Sécurité

• Zéro transmission de données : tout le traitement du texte se produit dans la mémoire du navigateur
• Aucun cookie, localStorage ou sessionStorage utilisé
• Aucun script d'analyse ou de suivi sur la page de l'outil
• Entièrement fonctionnel en mode hors ligne après le chargement initial de la page
• Aucune inscription, connexion ou clé API requise

Fonctionnalités

• Encoder du texte en Base64 et décoder du Base64 en texte avec conversion en temps réel
• Mode sécurisé pour les URL utilisant -_ au lieu de +/ pour un Base64 compatible web (RFC 4648 §5)
• Option sans bourrage pour supprimer les signes égal de fin (RFC 4648 §3.2)
• Explication intégrée du schéma d'encodage Base64 et du format de fichier .b64
• Télécharger des fichiers .txt et .b64 avec prise en charge du glisser-déposer
• Télécharger les résultats en fichiers .b64 ou .txt avec la boîte de dialogue native Enregistrer sous
• Entièrement côté client — aucun envoi vers le serveur, fonctionne hors ligne

Questions fréquentes