> encodeur base64 | texte | fichier <

Tapez ou collez votre texte dans la zone ENTRÉE ci-dessus. L'auto-encodage est activé par défaut — le résultat Base64 apparaît dans la zone SORTIE pendant la frappe. Cliquez sur [ENCODE] ou appuyez sur Ctrl/Cmd + Entrée pour déclencher l'encodage manuellement. Activez --url-safe ou --no-padding selon l'endroit où sera utilisé le Base64 (JWT, OAuth, URLs → les deux activés). Tout s'exécute localement dans votre navigateur : aucun téléversement, aucun journal, aucune requête réseau liée à votre entrée.

Cliquez sur le bouton [upload file] sous la zone d'entrée et choisissez un fichier jusqu'à 100 Mo. L'encodeur le lit avec FileReader.readAsArrayBuffer, fait passer les octets dans btoa par blocs de 32 Ko (pour que les gros fichiers ne plantent pas le navigateur) et écrit le Base64 complet dans la zone SORTIE. Pour les fichiers plus volumineux, utilisez un encodeur en ligne de commande : base64 < input.bin > output.txt (macOS/Linux), ou PowerShell : [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Si vous souhaitez que le Base64 soit formaté comme une Data URI (ex. data:image/png;base64,...), ajoutez en préfixe le type MIME et ;base64, à la sortie, ou utilisez notre outil dédié Image vers Base64, qui produit des Data URI prêtes à coller pour PNG, JPG, GIF, WebP et SVG.

Les trois sont définis dans le RFC 4648 :

• Base64 standard (§4) utilise l'alphabet A-Z a-z 0-9 + / avec padding =. La longueur de sortie est toujours un multiple de 4. Sûr pour MIME, HTTP Basic Auth et les valeurs de chaîne JSON.

• Base64 URL-safe (§5) remplace + par - et / par _. Obligatoire lorsque le Base64 est placé dans des chemins d'URL, des paramètres de requête, des noms de fichiers ou des segments JWT — les caractères standards +/ nécessiteraient sinon un pourcent-encodage.

• Sans padding (à la fois §4 et §5, base64url sans padding) supprime les caractères = finaux. La longueur n'est plus un multiple de 4, mais les décodeurs peuvent calculer la longueur d'origine à partir du reste modulo 4. Utilisé par JWT (base64url selon le RFC 7515), WebAuthn et certaines implémentations CBOR/COSE.

Les décodeurs doivent être informés de la variante à attendre — notre décodeur Base64 détecte automatiquement les trois.

Tous les langages et runtimes majeurs embarquent l'encodage Base64. Extraits prêts à copier-coller :

JavaScript (navigateur) :
btoa('Hello') // SGVsbG8=
// Pour UTF-8 :
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // sûr pour UTF-8

Node.js :
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-safe, sans padding

Python :
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-safe sans padding

PHP : base64_encode('Hello')
Ruby : Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go : base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...) (sans padding)
Java : Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C# : Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust : base64::engine::general_purpose::STANDARD.encode("Hello")

Shell (macOS/Linux) : echo -n 'Hello' | base64 → SGVsbG8=. Utilisez base64 -w 0 sur Linux pour supprimer le retour à la ligne à 76 colonnes.

La sortie Base64 est ~33 % plus grande que l'entrée : tous les 3 octets d'entrée deviennent 4 caractères de sortie. Formule exacte : ceil(n / 3) × 4 en incluant le padding, ou ceil(n × 4 / 3) sans. Plus quelques octets supplémentaires de surcharge si vous ajoutez un retour à la ligne à 76 colonnes (MIME) ou 64 colonnes (PEM).

Exemples :
• 1 Ko binaire → ~1,37 Ko Base64
• Image de 100 Ko → ~137 Ko en Data URI
• PDF de 1 Mo → ~1,37 Mo Base64 dans du JSON

Quand éviter Base64 :
• Transferts de gros fichiers : une image de 10 Mo intégrée en Base64 dans du HTML devient 13,7 Mo de texte analysé, bloque le thread principal et ne peut pas être mise en cache séparément. Préférez <img src="/assets/photo.png">.
• APIs sensibles aux performances : une charge utile Base64 de 500 Ko dans du JSON s'analyse ~2-3× plus lentement qu'un endpoint binaire équivalent.
• Comme mesure de sécurité : Base64 n'est pas du chiffrement — n'importe qui peut le décoder. Utilisez AES-GCM ou similaire pour la confidentialité.
• BLOBs de base de données : stockez les octets bruts en BLOB/BYTEA, pas en texte Base64, pour économiser 33 % de stockage et éviter les allers-retours d'encodage/décodage.

JWT (RFC 7515) et OAuth PKCE (RFC 7636) utilisent tous deux du Base64 URL-safe sans padding, souvent appelé base64url. Pour le produire dans cet outil : activez les deux cases --url-safe et --no-padding, puis encodez votre texte.

Équivalents programmatiques :
• JavaScript : btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js : Buffer.from(s).toString('base64url')
• Python : base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go : base64.RawURLEncoding.EncodeToString([]byte(s))
• Java : Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

Champs JWT courants qui nécessitent base64url : les trois segments séparés par des points (en-tête, charge utile, signature), les code_verifier/code_challenge d'OAuth PKCE, les challenges WebAuthn, les clés p256dh/auth de Web Push, et les paramètres Request.state de Google.

Un bug courant consiste à envoyer un JWT avec du Base64 standard (+/) — les APIs le rejetteront comme malformé, car le + est URL-décodé en espace lors du transport.

Oui, avec une réserve. Cet encodeur produit la partie Base64 d'une Data URI — la partie après ;base64,. Pour construire une Data URI complète, ajoutez en préfixe :

data:<mime-type>;base64,<sortie-encodée>

Types MIME courants :
• data:image/png;base64,... — image PNG
• data:image/jpeg;base64,... — image JPEG
• data:image/svg+xml;base64,... — SVG (ou utilisez data:image/svg+xml;utf8, sans Base64 — généralement plus petit)
• data:application/pdf;base64,... — fichier PDF
• data:application/font-woff2;base64,... — police intégrée
• data:text/plain;charset=utf-8;base64,... — texte encapsulé en Base64

Pour les images et SVG, l'outil Image vers Base64 produit la Data URI complète prête à coller dans background-image CSS, en ligne dans <img src="..."> ou dans des balises <object data="...">.

Avertissement de taille : les Data URI de plus de 20-30 Ko dégradent le LCP (Largest Contentful Paint) car le navigateur ne peut pas les précharger — gardez les images Base64 en ligne petites, et préférez des <img> classiques avec loading="lazy" pour les ressources plus volumineuses.

Oui — rien ne quitte votre navigateur. L'encodeur s'exécute entièrement en JavaScript en utilisant les APIs natives btoa(), TextEncoder et FileReader. Il n'y a aucun appel réseau sur le contenu entré, aucune télémétrie, aucun journal, aucune analytique tierce sur ce que vous encodez. Vous pouvez ouvrir l'onglet Réseau des DevTools pendant l'encodage et observer zéro requête associée.

Cependant, Base64 n'est pas du chiffrement — c'est un encodage réversible, et quiconque possède la sortie peut la décoder. Donc :
• Ne collez pas de secrets de production dans du chat, des captures d'écran ou des journaux, même sous forme encodée.
• Pour HTTP Basic Auth, l'en-tête Base64 Authorization: Basic n'est sûr que sur TLS (HTTPS). En HTTP en clair, il est trivialement interceptable.
• Pour une véritable confidentialité, utilisez AES-GCM, age, sops ou un KMS — puis encodez le chiffré en Base64 pour le transport si nécessaire.

Pour des politiques strictes d'exfiltration de données, enregistrez cette page hors ligne (Cmd/Ctrl + S). L'encodeur fonctionne totalement isolé après un seul chargement, puisqu'il n'y a aucune dépendance serveur.

L'encodeur prend en charge les fichiers jusqu'à 100 Mo via la limite stricte du gestionnaire de fichiers — suffisamment pour la plupart des images, PDF, archives ZIP et même de courtes vidéos. Cibles de performance :

• < 1 Mo : l'encodage se termine en <50 ms, aucun gel d'interface.
• 1 – 10 Mo : 100-500 ms selon le CPU. Le navigateur reste réactif car nous encodons par blocs de 32 Ko.
• 10 – 100 Mo : 2-15 secondes. La zone de texte de sortie peut légèrement ramer lors du collage/défilement de chaînes Base64 si grandes. Envisagez de télécharger la sortie comme un fichier .txt depuis les DevTools si nécessaire.
• > 100 Mo : bloqué — la surcharge mémoire du navigateur (octets d'entrée + chaîne binaire + chaîne Base64 ≈ 3-4× la taille du fichier) risque de faire planter l'onglet. Utilisez :

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

Pour les workflows en streaming/multi-Go, consultez encoder de gros fichiers en Base64 pour une approche par blocs avec Node.js/Python qui évite de tout charger en mémoire.

Cet encodeur utilise UTF-8, le même encodage utilisé par le web moderne, JSON, Linux, macOS et presque tous les langages de programmation par défaut. En interne, le texte est passé à travers new TextEncoder().encode(input), qui produit toujours des octets UTF-8, et n'est qu'ensuite encodé en Base64.

Pourquoi c'est important : l'ancienne fonction JavaScript btoa() ne gère que le Latin-1 et lève InvalidCharacterError sur des caractères comme é, 中 ou 😀. Notre wrapper gère la conversion UTF-8 à votre place, afin que les emojis, le chinois, le japonais, le coréen, l'arabe, le cyrillique et tout point de code Unicode s'encodent correctement.

Si vous avez besoin d'un encodage différent :
• UTF-16 LE (natif Windows) : rare — généralement un signe d'interopérabilité hérité. Utilisez quand même new TextEncoder({ fatal: true }).encode(s) et convertissez en amont.
• ISO-8859-1 / Latin-1 : mappez manuellement les points de code 0-255 en octets avant l'encodage.
• GB18030, Shift_JIS, EUC-KR : utilisez une bibliothèque comme iconv-lite en Node.js pour transcoder d'abord.

Un piège subtil : si vos données source sont déjà dans un encodage non-UTF-8 (ex. lecture d'un dump MySQL hérité), décodez-les d'abord avec le bon codec, puis ré-encodez en UTF-8 avant le Base64 — sinon le Base64 décodé préservera le mojibake.