Qué es Base64 y por qué no es cifrado

"Está en Base64, así que va encriptado". Esa frase, muy repetida, es falsa, y puede costar caro: Base64 no protege nada. Es una forma de escribir cualquier dato como texto, igual de pública que el dato original. En esta guía verás cómo funciona, para qué sirve de verdad (y es mucho), por qué cualquiera puede decodificarlo en un segundo, y qué usar cuando lo que necesitas es proteger información.

Qué es Base64

Los archivos y muchos datos son binarios: secuencias de bytes que no corresponden a letras. Hay sitios por los que esos bytes no pueden viajar tal cual —el cuerpo de un correo, una cabecera HTTP, un JSON, una URL, una hoja de estilos— porque esperan texto. Base64 resuelve eso: toma los bytes de tres en tres (24 bits), los reparte en cuatro grupos de 6 bits y representa cada grupo con uno de 64 caracteres "seguros": A-Z, a-z, 0-9, + y /. Si al final sobran bytes, rellena con =. El resultado es texto que cualquier sistema acepta, a cambio de ocupar un 33 % más.

Un ejemplo: la palabra Hola son los bytes 72, 111, 108, 97. En Base64 se escribe SG9sYQ==. Los dos = indican que el último grupo quedó incompleto. Nada se ha ocultado: es la misma información escrita con otro alfabeto, como pasar un número de decimal a hexadecimal.

Por qué no es cifrado

Cifrar significa transformar un dato de modo que solo quien tiene una clave pueda recuperarlo. Base64 no tiene clave: el procedimiento para deshacerlo es público, fijo y trivial, y lo hace cualquier navegador, cualquier lenguaje y cualquier página web en milisegundos. Pegar una contraseña en Base64 en un archivo de configuración, un correo o un repositorio es exactamente igual que pegarla en texto plano, salvo que además da una falsa sensación de seguridad. Lo mismo vale para un token, una clave de API o un número de tarjeta.

Hay un caso que confunde especialmente: los JWT (los tokens de sesión que usan muchas apps). Tienen tres partes separadas por puntos, y las dos primeras son JSON en Base64 (en su variante URL-safe, con - y _). Cualquiera que tenga el token puede leer lo que dice: usuario, roles, fecha de caducidad. La tercera parte es una firma que impide modificarlo, pero no impide leerlo. Por eso un JWT nunca debe llevar datos sensibles en su cuerpo.

Para qué sirve de verdad

Imágenes incrustadas (data URI): <img src="data:image/png;base64,iVBOR…"> mete un icono o un logotipo pequeño dentro del HTML o del CSS, sin una petición extra. Para imágenes grandes no compensa: pesan un tercio más y no se cachean por separado.
Adjuntos de correo: el formato MIME codifica cada adjunto en Base64 para que viaje por un protocolo pensado para texto.
Autenticación básica HTTP: la cabecera Authorization: Basic … lleva usuario:contraseña en Base64. Por eso solo es aceptable sobre HTTPS: sin cifrado de transporte, la contraseña va a la vista.
JSON y APIs: enviar un archivo (una firma, una foto) dentro de un campo de texto JSON.
Claves y certificados: los archivos PEM (-----BEGIN CERTIFICATE-----) son binario en Base64 con cabeceras.
JWT, cookies y URLs: transportar estructuras pequeñas como una sola cadena sin caracteres problemáticos.

Compruébalo tú mismo: codifica y decodifica texto o archivos (con UTF-8 correcto y variante URL-safe) y verás que no hace falta ninguna clave. Todo en tu navegador, sin que lo que pegues salga de él.

Abrir el codificador Base64 →

Las variantes y los errores típicos

URL-safe: como + y / tienen significado en una URL, existe una variante que los cambia por - y _ y suele omitir el relleno =. Es la que usan JWT y muchos enlaces de activación; si decodificas uno "normal" y falla, prueba la otra. Acentos y emojis: Base64 codifica bytes, no letras, así que primero hay que convertir el texto a bytes (UTF-8). La función clásica del navegador, btoa, solo acepta caracteres de un byte: por eso en muchas herramientas "canción" o un emoji dan error o salen mal. La nuestra convierte a UTF-8 antes. Saltos de línea: algunos sistemas parten el Base64 en líneas de 76 caracteres; al decodificar hay que ignorarlos.

Qué usar cuando sí necesitas proteger datos

Si tienes que guardar contraseñas, no se cifran ni se codifican: se les aplica un hash lento con sal (bcrypt, scrypt o Argon2) que no se puede deshacer. Si tienes que transmitir datos sensibles, el canal debe ir cifrado (HTTPS/TLS), y el contenido, si hace falta, con un cifrado real con clave (AES-GCM, por ejemplo, disponible en el navegador vía Web Crypto). Si tienes que comprobar que un archivo no ha cambiado, usa un hash como SHA-256, que también tienes en nuestras herramientas para desarrolladores. Y si lo que necesitas es una clave o un secreto aleatorio, genéralo con el generador de contraseñas; en ¿es seguro un generador de contraseñas online? explicamos por qué importa dónde se genera.

Preguntas frecuentes

¿Base64 comprime?

Al contrario: aumenta el tamaño un 33 % (cada 3 bytes se convierten en 4 caracteres). Si necesitas reducir, comprime antes (gzip, o una imagen en WebP) y codifica después.

¿Cómo sé si una cadena es Base64?

Solo tiene letras, dígitos, + y / (o - y _), su longitud es múltiplo de 4 (contando el relleno =) y, decodificada, produce algo con sentido. Que parezca Base64 no garantiza que lo sea: un hash hexadecimal, por ejemplo, también es "texto raro".

¿Es seguro pegar un token en una herramienta online para decodificarlo?

Solo si la herramienta trabaja en tu navegador. Un decodificador que envía lo que pegas a un servidor acaba de recibir tu token. Nuestras herramientas para desarrolladores no tienen backend: puedes desconectar internet y seguir usándolas.

Conclusión

Base64 es una herramienta de transporte, no de seguridad: convierte bytes en texto para que pasen por donde solo cabe texto, y cualquiera lo deshace sin clave. Úsalo para data URI, adjuntos, JWT y APIs; nunca para "esconder" contraseñas o datos. Y cuando quieras codificar, decodificar o inspeccionar una cadena, hazlo con el codificador Base64 de EzzyApps, que procesa todo en tu navegador.

"It's in Base64, so it's encrypted." That often-repeated line is false, and it can be costly: Base64 protects nothing. It's a way of writing any data as text, exactly as public as the original data. In this guide you'll see how it works, what it's really for (and that's a lot), why anyone can decode it in a second, and what to use when what you need is to protect information.

What Base64 is

Files and many kinds of data are binary: sequences of bytes that don't map to letters. There are places those bytes can't travel as is —the body of an email, an HTTP header, a JSON document, a URL, a stylesheet— because they expect text. Base64 solves that: it takes bytes three at a time (24 bits), splits them into four 6-bit groups and represents each group with one of 64 "safe" characters: A-Z, a-z, 0-9, + and /. If bytes are left over at the end, it pads with =. The result is text any system accepts, at the cost of being 33% larger.

An example: the word Hola is the bytes 72, 111, 108, 97. In Base64 it's written SG9sYQ==. The two = signs show the last group was incomplete. Nothing has been hidden: it's the same information written in another alphabet, like converting a number from decimal to hexadecimal.

Why it is not encryption

Encrypting means transforming data so that only someone holding a key can recover it. Base64 has no key: the procedure to undo it is public, fixed and trivial, and every browser, every language and every web page does it in milliseconds. Pasting a Base64 password into a config file, an email or a repository is exactly the same as pasting it in plain text, except it also gives a false sense of security. The same goes for a token, an API key or a card number.

One case is especially confusing: JWTs (the session tokens many apps use). They have three parts separated by dots, and the first two are JSON in Base64 (the URL-safe variant, with - and _). Anyone holding the token can read what it says: user, roles, expiry date. The third part is a signature that prevents modifying it, but not reading it. That's why a JWT should never carry sensitive data in its body.

What it is really for

Embedded images (data URI): <img src="data:image/png;base64,iVBOR…"> puts a small icon or logo inside the HTML or CSS, with no extra request. For large images it doesn't pay off: they weigh a third more and aren't cached separately.
Email attachments: the MIME format encodes every attachment in Base64 so it can travel over a text-oriented protocol.
HTTP basic authentication: the Authorization: Basic … header carries user:password in Base64. That's why it's only acceptable over HTTPS: without transport encryption, the password is in plain sight.
JSON and APIs: sending a file (a signature, a photo) inside a JSON text field.
Keys and certificates: PEM files (-----BEGIN CERTIFICATE-----) are binary in Base64 with headers.
JWT, cookies and URLs: carrying small structures as a single string with no problematic characters.

Check it yourself: encode and decode text or files (with proper UTF-8 and the URL-safe variant) and you'll see no key is needed. All in your browser, and what you paste never leaves it.

Open the Base64 encoder →

Variants and common mistakes

URL-safe: since + and / mean something in a URL, there's a variant that swaps them for - and _ and usually drops the = padding. It's the one JWTs and many activation links use; if decoding a "normal" one fails, try the other. Accents and emoji: Base64 encodes bytes, not letters, so the text must first be converted to bytes (UTF-8). The browser's classic function, btoa, only accepts single-byte characters: that's why in many tools "canción" or an emoji errors out or comes out wrong. Ours converts to UTF-8 first. Line breaks: some systems split Base64 into 76-character lines; when decoding, they must be ignored.

What to use when you actually need to protect data

If you have to store passwords, they're neither encrypted nor encoded: they get a slow, salted hash (bcrypt, scrypt or Argon2) that can't be undone. If you have to transmit sensitive data, the channel must be encrypted (HTTPS/TLS) and the content, if needed, with real keyed encryption (AES-GCM, for example, available in the browser via Web Crypto). If you have to check that a file hasn't changed, use a hash like SHA-256, which you also have in our developer tools. And if what you need is a random key or secret, generate it with the password generator; in are online password generators safe? we explain why where it's generated matters.

Frequently asked questions

Does Base64 compress?

The opposite: it increases size by 33% (every 3 bytes become 4 characters). If you need to shrink, compress first (gzip, or an image in WebP) and encode afterwards.

How do I know if a string is Base64?

It only contains letters, digits, + and / (or - and _), its length is a multiple of 4 (counting the = padding) and, decoded, it produces something meaningful. Looking like Base64 doesn't guarantee it is: a hex hash, for instance, is also "odd-looking text".

Is it safe to paste a token into an online tool to decode it?

Only if the tool works in your browser. A decoder that sends what you paste to a server has just received your token. Our developer tools have no backend: you can disconnect from the internet and keep using them.

Conclusion

Base64 is a transport tool, not a security tool: it turns bytes into text so they can pass where only text fits, and anyone can undo it without a key. Use it for data URIs, attachments, JWTs and APIs; never to "hide" passwords or data. And when you want to encode, decode or inspect a string, do it with the EzzyApps Base64 encoder, which processes everything in your browser.