Codificador y decodificador Base64 gratuito en línea

¿Qué es Base64?

Base64 es un esquema de codificación binario-a-texto, una forma de representar cualquier secuencia de bytes (datos binarios) como una secuencia de caracteres ASCII corrientes que pueden viajar por canales solo-texto sin corrupción. El nombre refleja el tamaño del alfabeto: 64 caracteres elegidos específicamente porque sobreviven a una transmisión limpia de 7 bits sin alteración. El alfabeto estándar es A-Z (posiciones 0-25), a-z (26-51), 0-9 (52-61), luego + (62) y / (63). El carácter = queda reservado como relleno cuando la longitud de entrada no es múltiplo exacto de tres. Cada tres bytes de entrada (24 bits) se convierten en cuatro caracteres de salida (cada uno con 6 bits), por eso los datos codificados en Base64 son aproximadamente un 33 % más grandes que el original.

La mecánica: tomar tres bytes (24 bits), reagrupar en cuatro tramos de 6 bits, buscar cada tramo en el alfabeto de 64 caracteres. El ejemplo clásico: los tres bytes ASCII M a n (0x4D 0x61 0x6E) forman el patrón de 24 bits 01001101 01100001 01101110; reagrupado en tramos de 6 bits: 010011 010110 000101 101110 = 19, 22, 5, 46 en decimal = caracteres T W F u. Así que "Man" se codifica en Base64 como "TWFu". Si la longitud de entrada no es divisible por tres, el codificador rellena con uno o dos =: 1 byte de entrada produce 2 caracteres + ==, 2 bytes de entrada producen 3 caracteres + =.

Una breve historia de Base64

Base64 nació del esfuerzo Privacy Enhanced Mail (PEM) del IETF. RFC 989 en febrero de 1987 fue la primera definición formal; RFC 1113 en agosto de 1989 la revisó; RFC 1421 en febrero de 1993 finalizó la especificación PEM con la codificación Base64 incluida. Base64 entra al correo electrónico generalista cuando la especificación MIME (Multipurpose Internet Mail Extensions) la adopta: RFC 2045 en noviembre de 1996 definió Base64 como codificación estándar para adjuntos binarios de correo, por eso cada PDF o imagen que has adjuntado a un correo viajó por la red como Base64. La especificación canónica actual es RFC 4648 («The Base16, Base32, and Base64 Data Encodings»), publicada en octubre de 2006 por Simon Josefsson, que sustituye a RFC 3548 (julio de 2003) y unifica las codificaciones de la familia Base16 / Base32 / Base64 en un solo documento. RFC 4648 es la spec a la que apunta toda implementación moderna de Base64.

Base64 URL-safe, por qué se intercambian dos caracteres

El alfabeto estándar de Base64 usa + y /, dos caracteres reservados en URL. + en una cadena de consulta URL típicamente significa «espacio» (convención form-encoded); / es el separador de ruta. Poner Base64 estándar en una URL implica percent-encoding de ambos, lo que infla aún más la cadena y la afea. RFC 4648 §5 define una variante URL-safe: sustituir + por - (guion-menos) y / por _ (subrayado). A veces llamada Base64URL o base64url. El resultado es una cadena que se inserta directamente en URL sin más escapado, exactamente lo que usan JWT (JSON Web Tokens), parámetros state de OAuth, IDs de credenciales WebAuthn y la mayoría de las API web modernas. Algunas implementaciones también descartan el = final de relleno porque la longitud es implícita por el siguiente campo. La estructura de tres partes separadas por puntos de JWT (encabezado.carga.firma) consiste en tres segmentos codificados en Base64URL; si alguna vez has decodificado un JWT a mano, has visto los caracteres - y _ que lo marcan como Base64URL en vez de Base64 estándar.

La familia Base-N, Base16, Base32, Base58, Base85

Base64 no es la única codificación binario-a-texto. Base16 (hex) usa 16 caracteres (0-9 y A-F), 100 % de expansión (cada byte se convierte en 2 caracteres hex), pero trivialmente legible y el valor por defecto universal para salidas de hash, sumas de verificación e identificadores de máquina. Base32 (RFC 4648, también variante de Crockford) usa 32 caracteres procurando excluir pares visualmente ambiguos como 0/O y 1/I/L; 60 % de expansión; usado para claves secretas TOTP, ULIDs y direcciones onion de Tor. Base58 es canónico para Bitcoin: 58 caracteres excluyendo los fácilmente confundibles 0/O/I/l, más los especiales de Base64 estándar +/=. Las direcciones Bitcoin, las direcciones Solana y muchos identificadores de billeteras cripto usan Base58Check (Base58 más una suma de verificación de 4 bytes). Base85 / Ascii85 empaca más densidad (codificando 4 bytes como 5 caracteres, solo 25 % de expansión) pero usa un alfabeto que incluye puntuación URL-unsafe; los formatos PostScript y PDF de Adobe usan Base85 internamente para datos binarios incrustados. El compromiso general: más caracteres en el alfabeto significa menos expansión pero un conjunto de caracteres más restringido; menos caracteres significa transporte más seguro a costa de salida más grande.

Usos comunes de Base64

• Adjuntos de correo (MIME). RFC 2045 desde 1996. Cada PDF, imagen o documento que has adjuntado a un correo viajó por la red como Base64 porque SMTP era originalmente un protocolo de texto limpio de 7 bits que no podía manejar binario crudo.
• URI data: en HTML/CSS. data:image/png;base64,iVBORw0KGgo... incrusta una imagen pequeña directamente en HTML o una hoja de estilos CSS, eliminando una petición HTTP. Útil para iconos por debajo de ~10 KB; contraproducente para imágenes mayores porque la expansión Base64 del 33 % supera el ahorro del coste de petición HTTP.
• Binario en cargas útiles JSON. JSON es solo-texto por spec, no hay forma de meter bytes crudos en un valor JSON. Las API que necesitan transmitir imágenes, PDFs u otro binario los incrustan como cadenas Base64 en un campo JSON. Las cargas útiles de webhooks de Stripe, las API MMS de Twilio y muchos endpoints de AI-vision usan este patrón.
• JWT (JSON Web Tokens). Las tres partes separadas por puntos de un JWT (encabezado.carga.firma) están todas codificadas en Base64URL. La spec de JWT (RFC 7519, mayo de 2015) se apoya en JOSE (RFC 7515-7518, también mayo de 2015), todas las cuales mandan Base64URL en todo.
• OAuth y OpenID Connect. El parámetro state, los code verifiers PKCE, los ID tokens y los access tokens en muchas implementaciones usan Base64URL.
• Autenticación HTTP Basic. El encabezado Authorization: Basic dXNlcjpwYXNz lleva Base64(usuario:contraseña). Nota: esto es codificación para transporte, NO cifrado, Basic Auth sobre HTTP plano expone credenciales en texto plano a cualquiera que mire la red. Combinar siempre con HTTPS.
• Subresource Integrity (SRI). El atributo integrity="sha384-..." en etiquetas <script> y <link> lleva un hash codificado en Base64 del contenido esperado del archivo; los navegadores verifican que el archivo descargado coincide antes de ejecutar.
• Fondos SVG en CSS. background-image: url("data:image/svg+xml;base64,...") incrusta un SVG directamente en una hoja de estilos. La forma Base64 a veces se prefiere sobre la forma URL-encoded (que mantiene el SVG legible pero usa reglas de escapado diferentes).

Codificar no es cifrar, un error de seguridad común

Base64 ofrece cero seguridad. La codificación es totalmente reversible por cualquiera en milisegundos, el alfabeto es público, el algoritmo es trivial, y cualquier navegador o comando CLI de una línea puede decodificarlo. A pesar de esto, «datos sensibles codificados en Base64» es uno de los ejemplos más citados en CWE-261 de MITRE (Weak Encoding for Password) y aparece constantemente en auditorías de seguridad: claves de API «ofuscadas» con Base64 en código cliente; contraseñas «codificadas» con Base64 en backups de bases de datos; secretos «cifrados» con Base64 antes de ser commiteados a un repositorio Git público. Ninguno de ellos está protegido. Si necesitas confidencialidad real, usa cifrado real: AES-256-GCM para simétrico, RSA-OAEP o ECDH+ChaCha20-Poly1305 para asimétrico. Base64 es apropiado para transporte (convertir binario en forma text-friendly) pero nunca para protección.

Implementación del navegador: btoa / atob y el escollo Unicode

JavaScript expone dos funciones globales integradas para Base64: btoa() (binary-to-ASCII, codificar) y atob() (ASCII-to-binary, decodificar). Ambas son API legacy de la era Netscape temprana y tienen una limitación famosa: solo funcionan sobre cadenas de bytes Latin-1. Llamar a btoa('é') lanza InvalidCharacterError porque la cadena JavaScript 'é' contiene un code point por encima de U+00FF que no cabe en un solo byte. La corrección moderna es codificar primero a bytes UTF-8 vía TextEncoder, luego convertir el Uint8Array resultante a una cadena Latin-1 para consumo de btoa(). El patrón: btoa(String.fromCharCode(...new TextEncoder().encode(str))). Decodificación al revés: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))). Los navegadores más nuevos exponen Uint8Array.toBase64() y Uint8Array.fromBase64() como métodos integrados, pero la adopción aún se está desplegando en 2026, el polyfill vía btoa/atob sigue siendo el default cross-browser. Para archivos específicamente, FileReader.readAsDataURL() es la ruta más sencilla: suelta un archivo en un input, el reader devuelve una cadena data:mime/type;base64,... con todo correctamente codificado; quita el prefijo data: para obtener solo la porción Base64.

Alcance honesto: qué hace y qué no hace esta herramienta

Esta herramienta codifica texto o archivos (hasta 5 MB) a Base64 y decodifica cadenas Base64 a texto o archivos descargables. Usa el alfabeto estándar RFC 4648 (con + y /) por defecto; Base64URL URL-safe (con - y _) es un toggle de funcionalidad futura. El texto UTF-8 se maneja correctamente vía TextEncoder, el escollo btoa-Latin-1 está corregido. El límite de 5 MB existe porque Base64 expande los datos un 33 % y la cadena codificada vive entera en memoria del navegador; un archivo binario de 5 MB produce ~6,7 MB de texto Base64 más el buffer original, lo cual funciona en cualquier dispositivo moderno. Para archivos más grandes, las alternativas estándar son línea de comandos base64 en macOS/Linux (base64 -i input.bin -o output.txt), el módulo base64 de Python, o Buffer.from(data).toString('base64') de Node.js. Esta herramienta no maneja: Base64 en streaming (codificación archivo-por-fragmento para archivos mayores que la memoria); la variante URL-safe en esta versión (planificado); ni codificación quoted-printable MIME (un esquema RFC 2045 diferente para contenido texto de correo).

Privacidad: por qué importa el solo-navegador

Base64 no es cifrado, pero los datos que se codifican suelen ser sensibles: claves de API que estás incrustando en un archivo de config, certificados que estás codificando para transporte, capturas internas que estás incrustando como URI data en documentación, o recibos PDF que estás codificando para un cliente. Los codificadores del lado servidor ven tu entrada. Esta herramienta corre entera en tu navegador vía JavaScript, verifícalo en la pestaña Network de DevTools al pulsar Encode, o pon la página offline (modo avión) tras cargarla y la herramienta sigue funcionando. Segura para codificar credenciales de API, capturas con PII, documentos internos o cualquier dato que no quieras ver copiado en el disco duro de un desconocido.

Preguntas frecuentes

¿Es Base64 seguro?

No. Base64 es codificación, no cifrado. Cualquiera puede decodificar una cadena Base64. Nunca uses Base64 para proteger datos sensibles, usa cifrado adecuado (AES, RSA) para seguridad.

¿Por qué Base64 hace los archivos más grandes?

La codificación Base64 aumenta el tamaño de los datos aproximadamente un 33%. Tres bytes de datos binarios se convierten en cuatro caracteres Base64. Esta sobrecarga es el precio de poder transmitir datos binarios como texto.

¿Puedo codificar archivos?

¡Sí! Arrastra y suelta cualquier archivo en el codificador, o haz clic para buscar. El archivo se convertirá en un Data URI Base64 que puedes pegar directamente en HTML, CSS o JavaScript.

¿Cuál es la diferencia entre Base64 y Base64URL?

Dos caracteres. Base64 estándar (RFC 4648 §4) usa + y / como caracteres 62 y 63 del alfabeto. Base64URL URL-safe (RFC 4648 §5) usa - y _ en su lugar, así la cadena codificada se inserta directamente en URL sin percent-encoding. JWT, OAuth, WebAuthn y la mayoría de las API web modernas usan Base64URL. Esta herramienta emite actualmente Base64 estándar; URL-safe está en la lista de funcionalidades futuras. Para convertir estándar a URL-safe a mano: sustituir + por -, / por _, opcionalmente quitar el = final de relleno.

¿Por qué mi texto Unicode falla en algunas herramientas Base64?

Porque la función legacy btoa() de JavaScript solo funciona sobre cadenas de bytes Latin-1, llamar a btoa('é') lanza InvalidCharacterError. Muchos codificadores antiguos basados en navegador usan btoa directamente sin el paso de conversión UTF-8, así que cualquier entrada no-ASCII rompe. El código moderno (y esta herramienta) codifica las cadenas vía TextEncoder primero, produciendo una secuencia de bytes UTF-8 que btoa puede entonces codificar sin riesgo. El método integrado más nuevo Uint8Array.toBase64() maneja UTF-8 de forma nativa pero aún no es baseline en todos los navegadores.

¿Mis datos se suben a algún sitio?

No. La codificación y decodificación corren enteras en tu navegador vía JavaScript. Texto y archivos nunca cruzan la red, verifícalo en la pestaña Network de DevTools al pulsar Encode, o pon la página offline (modo avión) tras cargarla y la herramienta sigue funcionando. Segura para credenciales de API, capturas con PII, archivos de config internos o cualquier dato que no quieras ver copiado en el disco duro de un desconocido.

Herramientas relacionadas