Codificar / Decodificar Base64
Codifica y decodifica Base64 con soporte completo de UTF-8.
Tus tokens y llaves no salen de tu equipoCodificar o decodificar Base64 online
Sobre este codificador de Base64
Base64 convierte cualquier dato en texto ASCII plano, y por eso aparece en todas partes: JWTs, data URLs, adjuntos de correo, cabeceras de autenticación y payloads de API. Esta herramienta codifica y decodifica en ambas direcciones con manejo correcto de UTF-8, así que los acentos y emojis sobreviven el viaje de ida y vuelta.
También soporta Base64 seguro para URLs (la variante que usa - y _ en vez de + y /), que es lo que usan los JWTs y muchas APIs. ¿Decodificando un segmento de JWT? Pégalo directamente.
El mecanismo es sencillo. El RFC 4648 toma la entrada de tres bytes en tres bytes —24 bits— y reescribe cada grupo como cuatro caracteres de seis bits cada uno, sacados de un alfabeto de 64 símbolos: A–Z, a–z, 0–9 y dos extras. Cuatro caracteres por cada tres bytes significa que la salida mide 4 × techo(n/3), aproximadamente un tercio más que la entrada: un mebibyte de datos se convierte en 1 398 104 caracteres. Cuando la entrada no es múltiplo de tres, el último grupo se rellena con = para que la longitud siga siendo divisible entre cuatro. Si sobra un byte se ponen dos signos =, si sobran dos se pone uno, y si la longitud es múltiplo exacto de tres no se pone ninguno. Por eso "A" se codifica como QQ== y "AB" como QUI=.
Vale la pena separar dos palabras que en español se confunden todo el tiempo: codificar no es cifrar. Base64 no oculta nada; es un cambio de representación que cualquiera revierte en un segundo, sin clave ni contraseña. La autenticación Basic de HTTP (RFC 7617) es literalmente Base64 de usuario, dos puntos y contraseña, y el propio RFC advierte que el esquema no se considera seguro salvo que viaje sobre TLS. Si alguna vez ves credenciales "protegidas" con Base64 en un repositorio o en una captura de pantalla, están expuestas. Del mismo detalle sale otra regla: como los dos puntos separan usuario de contraseña, un usuario que contenga dos puntos es inválido en Basic.
Los límites de esta página, sin adornos. Es texto que entra y texto que sale: al decodificar, los bytes pasan por un decodificador UTF-8, así que si pegas un PNG o un ZIP en Base64 vas a obtener caracteres de reemplazo, no un archivo. El codificador devuelve una sola línea continua, sin el corte a 76 caracteres que exige el RFC 2045 para cuerpos MIME, así que no sirve tal cual para pegar en un correo crudo. Y si el Base64 ya viene repartido en varias líneas —el cuerpo de un certificado PEM, el código fuente de un correo— puede salir "Base64 inválido": únelo en una sola línea primero. Por último, recuerda que Base64 hace los datos un 33% más grandes: si buscas payloads más chicos, comprime antes de codificar, nunca después.
El alfabeto Base64, el relleno y por qué btoa rompe la ñ
Entran tres bytes, salen cuatro caracteres. Cada carácter de salida lleva exactamente seis bits, y con 64 símbolos alcanza para representar todos los valores de seis bits. Todo lo demás en Base64 se deduce de esa proporción.
| Entrada | Bytes | Base64 |
|---|---|---|
| A | 1 | QQ== (dos signos de relleno) |
| AB | 2 | QUI= (uno) |
| ABC | 3 | QUJD (ninguno) |
| ABCD | 4 | QUJDRA== (otra vez dos) |
| Ñ | 2 en UTF-8 | w5E= |
| café | 5 en UTF-8 | Y2Fmw6k= |
Fíjate en las dos últimas filas: Ñ y café son uno y cuatro caracteres de texto, pero dos y cinco bytes de UTF-8, porque Base64 codifica bytes, no letras. Ahí es donde falla la función antigua btoa() del navegador. btoa trata cada carácter como un byte, así que btoa("Ñ") devuelve 8Q== —el byte F1 de Latin-1, silenciosamente distinto del resultado correcto en UTF-8, que es w5E=— y con cualquier carácter por encima de U+00FF, como un emoji, directamente lanza el error InvalidCharacterError. Lo peligroso es la primera mitad: no falla, solo te devuelve algo distinto. Esta herramienta pasa el texto por TextEncoder antes de codificar, así que los bytes ya son UTF-8 de verdad.
El tamaño es predecible: 4 × techo(n/3) caracteres para n bytes. Así, 100 bytes se vuelven 136 caracteres (136%), 1 KiB se vuelve 1 368 (133,6%) y la proporción se estabiliza en 133,33% cuando la entrada crece. Ese sobrecosto explica por qué incrustar una imagen grande como data URL pesa más que enlazarla, y por qué un adjunto de correo ocupa notablemente más que el archivo original.
| Variante | Caracteres 62 y 63 | Relleno |
|---|---|---|
| Estándar (RFC 4648 §4) | + y / | Obligatorio salvo que otro estándar diga lo contrario |
| Seguro para URLs (§5) | - y _ | Suele omitirse; sirve en query strings y nombres de archivo |
| Segmentos de JWT (RFC 7515) | - y _ | Siempre se quita, y sin saltos de línea |
| Cuerpo MIME de correo (RFC 2045) | + y / | Obligatorio, cortado a 76 caracteres por línea |
Decodificar es más tolerante que codificar: la herramienta convierte - y _ de vuelta a + y / antes de decodificar, y vuelve a añadir el relleno que falte, así que un segmento de JWT sin padding se pega tal cual. Lo que no hace es devolver un archivo binario —la salida siempre es texto— ni unir un Base64 que ya venga partido en varias líneas: quita los saltos del cuerpo de un PEM antes de pegarlo.
Preguntas frecuentes
¿Por qué se rompen los acentos en otras herramientas de Base64?
Muchas usan las funciones antiguas btoa/atob del navegador, que solo manejan Latin-1. Esta herramienta codifica primero a bytes UTF-8, así que cualquier carácter funciona.
¿Qué es Base64 seguro para URLs?
Una variante que reemplaza + por - y / por _ para poder usar el resultado en URLs y nombres de archivo sin escapar caracteres. Activa el interruptor para usarla.
¿Base64 es cifrado?
No. Es una codificación, no un cifrado: cualquiera puede decodificarlo. Nunca lo uses para proteger secretos.