Herramienta decodificadora Base64 en línea

1. 1

   Pega el Base64

   Suelta la cadena en el cuadro de entrada. Los saltos de línea, el relleno ausente y los caracteres base64url se gestionan solos, y puedes pegar un data URI, un bloque PEM o un JWT enteros: la envoltura se detecta y se retira por ti.

2. 2

   Lee el resultado

   La salida aparece mientras escribes hasta 256 KB; por encima de eso se decodifica al pulsar Decodificar. El panel indica el formato encontrado, el tipo de archivo reconocido en los bytes y el conjunto de caracteres usado para mostrar texto.

3. 3

   Ajusta si la detección falló

   Cambia la vista entre texto, hexadecimal y ASCII imprimible, elige un conjunto de caracteres concreto si el detectado produjo caracteres de reemplazo, o activa el modo estricto para que la entrada mal formada se rechace en vez de repararse.

4. 4

   Copia o descarga

   Copia el texto, o descarga los datos con la extensión que sus propios bytes indican: un PNG decodificado se guarda como .png, no como .bin. Todo se procesa en tu dispositivo y nada se sube.

Cinco ajustes, y cada uno existe porque una carga real lo necesitaba. Ninguno está detrás de un plan de pago: un decodificador que retiene la decodificación no está limitado, está roto.

Formato de entrada

Déjalo en Auto y pega lo que sea. La herramienta comprueba, por orden, un prefijo data URI, un bloque de armadura OpenPGP, una cabecera PEM y un JWT de tres partes, y si no encuentra ninguno trata la entrada como una carga simple. Elegir un formato explícitamente lo convierte en una afirmación: si eliges PEM y la entrada no tiene línea BEGIN, se te dice, en vez de decodificar otra cosa. Elegir Estándar o Seguro para URL además fija el alfabeto, de modo que con el modo estricto activo una carga que use el otro se rechaza exactamente en el carácter donde diverge.

Modo estricto

Desactivado por defecto, porque la tarea cotidiana es leer una cadena que alguien te ha enviado, y rechazarla por un = ausente no ayuda a nadie. Activado, cuatro cosas pasan a ser errores en vez de reparaciones: espacios fuera de un formato con saltos, relleno ausente o incorrecto, un alfabeto mezclado y un grupo final cuyos bits sin usar no son cero. Esto último merece conocerse: tiene su propia sección más abajo y ningún otro decodificador de la web lo informa.

Dividir la entrada

Un mecanismo, dos usos. «Cada línea» decodifica por separado una lista de cargas independientes y las muestra como resultados distintos, que es lo que quieres cuando un archivo de registro o una columna de base de datos tiene un valor Base64 por línea. «Segmentos JWT» divide por los puntos, de modo que la cabecera y la carga de un token se decodifican cada una por su cuenta y una firma que no es texto legible no estropea el resto. Auto elige lo segundo cuando la entrada es un JWT y deja el resto en paz.

Mostrar resultado como

Auto muestra texto para una carga de texto y un volcado hexadecimal para todo lo demás, según lo que son realmente los bytes y no según si un decodificador de texto produjo algo. Puedes anularlo: el hexadecimal es la vista correcta para una carga binaria que estás inspeccionando, el ASCII imprimible sirve para detectar cadenas incrustadas dentro de un binario, y forzar Texto es como se comprueba una carga que el detector clasificó mal. Cambiar de vista es instantáneo porque se vuelven a representar bytes ya decodificados.

Conjunto de caracteres

Auto lee primero una marca de orden de bytes, después cualquier conjunto declarado por un data URI, después comprueba si los bytes son UTF-8 válido, y si no recurre a Windows-1252 como conjetura declarada. Si el resultado tiene caracteres de reemplazo, el panel dice cuántos, y elegir el conjunto correcto de la lista lo arregla sin volver a decodificar el Base64.

Base64 es una sola codificación, pero llega envuelta en al menos siete cosas distintas. Un decodificador que solo acepta una carga simple rechaza la mayor parte de lo que la gente tiene realmente en el portapapeles.

• Estándar — el alfabeto del RFC 4648: A–Z, a–z, 0–9, + y /, con relleno =. Lo que emite la mayoría de codificadores.
• Seguro para URL (base64url) — lo mismo, con - y _ en lugar de + y /, para que la cadena sobreviva dentro de una URL o un nombre de archivo. Normalmente sin relleno. Se detecta y decodifica sin ninguna opción.
• MIME — Base64 estándar cortado a 76 columnas, como usan los cuerpos de correo. Los saltos de línea se eliminan; en modo estricto son el único espacio que sigue siendo legal, porque el formato se define por ellos.
• PEM — una carga entre líneas -----BEGIN X----- y -----END X-----, como usan los certificados, las claves privadas y los CSR. Las etiquetas deben coincidir en ambos extremos, y un bloque cuyo BEGIN y END discrepan se informa como dañado en lugar de decodificarse en silencio.
• ASCII-Armor de OpenPGP — el primo de PEM, con cabeceras de armadura opcionales y una línea de suma =CRC24. La suma se verifica: es la única comprobación de integridad que trae variante alguna de Base64, y una herramienta que la retira sin mirarla ha tirado la única prueba que ofrece el formato.
• Data URI — data:image/png;base64,…, que es lo que obtienes al copiar una imagen incrustada desde CSS o las herramientas de desarrollo. El prefijo se retira y se usan el tipo de medio y el conjunto de caracteres que declara, en lugar de adivinarlos.
• JWT — tres segmentos base64url separados por puntos. Se divide por los puntos para que la cabecera y la carga se decodifiquen como el JSON que son, incluidos los tokens con segmento de firma vacío, que produce alg:none y que una división más estricta rechazaría.

Esta es la parte que la mayoría de decodificadores Base64 se salta, y saltársela es la razón de que tantos te entreguen una pantalla de signos de interrogación. Base64 no dice nada sobre su contenido. Sin embargo, una vez que los bytes existen, suelen decirlo ellos mismos: casi todo formato binario empieza con una firma, y leerla es barato.

Se comprueban unas cuarenta firmas, que cubren imágenes (PNG, JPEG, GIF, WebP, BMP, ICO, TIFF, AVIF, HEIC), documentos (PDF, RTF), archivos comprimidos (ZIP, gzip, bzip2, xz, zstd, 7z, RAR), audio y vídeo (MP3, FLAC, Ogg, WAV, MP4, WebM, AVI), fuentes (TTF, OTF, WOFF, WOFF2) y ejecutables. Los formatos basados en ZIP se afinan un paso más leyendo el nombre de la primera entrada dentro del archivo, de modo que un .docx decodificado se ofrece como .docx y no como .zip, y un archivo OpenDocument se identifica por el tipo de medio que lleva su propia entrada mimetype. Cuando nada coincide, se comprueba si los bytes son texto siquiera —un byte NUL es la señal, con una excepción para UTF-16, que por construcción es medio bytes NUL— y el texto que empieza por una llave solo se etiqueta como JSON si de verdad se analiza.

De esto se siguen dos cosas visibles en la interfaz. El botón de descarga ofrece el archivo con la extensión que sus propios bytes justifican, así que un PNG decodificado se guarda como .png y se abre con doble clic. Y una carga binaria nunca pasa por un decodificador de texto para producir una página de caracteres de reemplazo U+FFFD: va directa a la vista hexadecimal, y el panel dice qué se encontró.

Esta es la razón más común de que una decodificación «parezca mal», y no es un fallo del decodificador. Base64 codifica bytes. No tiene campo para una codificación, ni cabecera, ni convención para ello. Cualquier herramienta que te muestre texto ha elegido una codificación por ti, y la mayoría no dice cuál.

• Una marca de orden de bytes es una afirmación — si los bytes decodificados empiezan con una BOM, el productor ha dicho cuál es la codificación, y esa se usa. Se reconocen UTF-8, UTF-16 en ambos órdenes y UTF-32 en ambos.
• Un data URI puede declarar una — data:text/plain;charset=windows-1251;base64,… nombra su propio conjunto, y se respeta, pero va por debajo de una BOM, porque una BOM está en los datos y el parámetro solo es una afirmación sobre ellos.
• UTF-8 válido es casi una prueba — UTF-8 tiene suficiente estructura como para que un documento de cualquier longitud sea válido por casualidad con muy poca probabilidad. Si los bytes se decodifican estrictamente como UTF-8, eso es lo que son.
• El ASCII puro no prueba nada — ASCII es UTF-8 válido y válido en todos los conjuntos de un byte, así que la pregunta no tiene respuesta. La herramienta dice «ambiguo» en vez de afirmar una detección segura que los datos no sostienen.
• Si no, es una conjetura, y se etiqueta como tal — una carga que no es UTF-8 válido está en alguna codificación de un byte, y los bytes no pueden decir cuál. Windows-1252 es con diferencia la más común, así que es el recurso final, mostrado como conjetura y con la lista completa a un clic.

Se ofrecen treinta y un conjuntos de caracteres, y la lista se construye preguntando al navegador cuáles admite realmente en vez de enumerar los que debería admitir. UTF-32 es la excepción: ningún navegador lo implementa en su decodificador de texto, así que aquí se decodifica directamente, y por eso aparece en la lista.

Base64 empaqueta tres bytes en cuatro caracteres. Cuando la longitud de la entrada no es múltiplo de tres, el grupo final queda corto, y algunos bits de su último carácter no pertenecen a ningún byte.

En un grupo final de dos caracteres sobran los últimos cuatro bits. En uno de tres, los últimos dos. Un codificador conforme escribe ceros ahí. Nada obliga a un decodificador a mirar, y prácticamente ninguno lo hace: QQ== y QR== se decodifican ambos al único byte 0x41, en silencio, en todos los navegadores, en todas las herramientas de línea de comandos y en todos los sitios web que probamos. Una de esas cadenas salió de un codificador y la otra estaba corrupta o editada a mano, y ninguna herramienta las distingue.

El modo estricto lo comprueba. Se informa como error con el modo estricto activo y como aviso cuando está desactivado, así que los bytes siguen ahí para mirarlos: la idea no es rechazar los datos, sino que sepas que la cadena no se produjo como dice haberse producido. Lo mismo vale para una carga que mezcla los dos alfabetos: - y _ nunca chocan con + y /, así que se decodifica sin ambigüedad, pero uno de los dos está fuera de lugar y probablemente alguien debería saberlo.

Cada rechazo indica el índice del carácter, la línea y la columna del problema, y cuál era el carácter. Ninguna de las dos funciones Base64 del navegador informa de una posición, ni lo hace ninguna herramienta competidora: en una carga de cuatro megabytes con un carácter suelto, «no válido» no es un diagnóstico.

• Base64 no válido — un carácter fuera del alfabeto. En modo indulgente esto solo se informa para caracteres verdaderamente ajenos: los espacios y saltos de línea se eliminan antes. Un espacio de no separación, que es lo que suele producir copiar de una página web renderizada, cuenta como ajeno, y la posición te dice exactamente dónde cayó.
• Truncada — la carga tiene un grupo final de un carácter, algo que ninguna entrada puede producir. Es la única señal inequívoca de «la cadena se cortó» que tiene Base64.
• Datos después del relleno — hay caracteres después de los signos =. Casi siempre dos cadenas Base64 unidas, que cualquier decodificador indulgente convertirá alegremente en basura plausible.
• Relleno ausente o inesperado — solo en modo estricto. Los caracteres = faltan, sobran, o no tienen la longitud que exige la propia longitud de la carga.
• Espacios no permitidos — solo en modo estricto, y solo fuera de los formatos con saltos. Los saltos de línea dentro de MIME, PEM y PGP son parte de esos formatos y siguen siendo legales.
• Alfabeto incorrecto o mezclado — solo en modo estricto. La carga usa caracteres del alfabeto que no seleccionaste, o de ambos.

Base64 es una codificación, no un cifrado ni una frontera de seguridad. Sirve para mover bytes por canales que solo aceptan texto, y los bytes del otro lado son los que alguien puso ahí.

• La salida decodificada es entrada no fiable — una carga puede decodificarse en un script, un ejecutable o marcado diseñado para ejecutarse en otro sitio. Haber sido Base64 no lo vuelve seguro, y que llegara codificado es a veces justamente el objetivo.
• No pegues secretos que no pegarías en otro sitio — esta página se ejecuta íntegramente en tu dispositivo y no envía nada, lo que puedes verificar con las herramientas de red de tu navegador, pero conviene no adquirir el hábito de pegar credenciales en formularios web, porque la mayoría de páginas que se parecen a esta sí suben los datos.
• La carga de un JWT no se verifica — dividir un token y decodificar sus segmentos te muestra lo que afirma. No comprueba la firma, y cualquiera puede producir un token que diga cualquier cosa. Léelo como una afirmación, nunca como un hecho.
• Una suma de armadura no es una firma — el CRC-24 de un bloque PGP detecta corrupción accidental. No es una comprobación criptográfica y no te dice quién produjo el bloque.

Base64 no llega solo por el portapapeles. Se guarda en archivos .txt y .b64, en certificados .pem y bloques de armadura .asc, y se incrusta en documentos .json, .xml y .eml, así que todos ellos se pueden soltar en la página.

Qué incluye el plan gratuito

Hasta 25 MB de Base64, una entrada cada vez, y todas las capacidades de la herramienta: los siete formatos de entrada, los treinta y un conjuntos de caracteres, el modo estricto, las vistas hexadecimal y ASCII, la detección de tipo de archivo, la descarga con tipo y los modos de división. El límite es de escala, nunca de si la herramienta funciona: 25 MB de Base64 son unos 18,75 MB de datos decodificados, una carga grande según cualquier medida normal.

Qué añade Pro

Hasta veinte entradas a la vez, todas descargables en un único archivo comprimido, y el límite de tamaño sustituido por lo que tu dispositivo pueda manejar de verdad en lugar de por un número fijo mayor. La compresión dentro del archivo se elige por fichero según lo que resultó ser la carga, así que un lote de imágenes decodificadas se almacena en vez de recomprimirse sin sentido, mientras que un lote de JSON decodificado sí se comprime.

Varias codificaciones se parecen lo bastante a Base64 como para confundirse con él, y un decodificador que las acepte igualmente produce disparates convincentes. Si la salida es basura y el conjunto de caracteres no es el problema, comprueba si la entrada es una de estas.

• Codificación por porcentajes — %20 y %E2%9C%93 son codificación de URL, no Base64. Usa el codificador y decodificador de URL.
• Hexadecimal — una cadena solo de 0–9 y a–f, de longitud par, es mucho más probable que sea hexadecimal que Base64, y el hexadecimal también es Base64 válido, que es justo por lo que el error produce una decodificación en vez de un fallo.
• Base32 — mayúsculas A–Z y 2–7, con relleno =. Comparte el carácter de relleno y nada más.
• Un hash — un resumen MD5, SHA-1 o SHA-256 no son datos codificados y no se pueden decodificar de vuelta a nada. Es una huella de un solo sentido; usa el generador de hash para producir una.
• Texto ya decodificado — las palabras corrientes están hechas de caracteres Base64, así que una frase pegada en un decodificador «se decodificará» en bytes. Si el resultado es binario y la entrada era legible, la entrada no estaba codificada.

Recurre al decodificador cuando ya tienes una cadena Base64 y necesitas lo que hay dentro. Usa el codificador para la dirección contraria.

• Inspeccionar un campo Base64 en una respuesta de API, un cuerpo de webhook o una línea de registro.
• Leer la cabecera y la carga de un JWT para ver qué afirma un token.
• Sacar una imagen o una fuente de un data URI incrustado en CSS, HTML o un SVG.
• Comprobar qué contiene realmente un certificado PEM o un bloque de armadura PGP.
• Recuperar texto guardado como Base64 en una columna de base de datos o un archivo .env.
• Confirmar con el modo estricto que un codificador produjo una salida conforme.
• Convertir una carga Base64 de vuelta en un archivo real y abrible con la extensión correcta.

El decodificador usa la vía Base64 que ofrezca tu navegador: los más nuevos traen una nativa y los más antiguos recurren a otra que existe en todas partes y produce una salida idéntica byte a byte. No hay nada que configurar ni que instalar. Los conjuntos de caracteres vienen del navegador, así que la lista exacta varía muy ligeramente entre motores; la herramienta muestra lo que el tuyo admite de verdad, no lo que se supone que admite.

La decodificación se ejecuta fuera del hilo principal, en tu dispositivo, usando la vía Base64 más rápida que ofrece tu navegador. Medido en un equipo de escritorio, una carga de 25 MB se decodifica en unos 170 milisegundos de principio a fin, incluida la identificación de qué son los bytes.

• Codificador Base64
• Codificador/Decodificador Base64
• Codificador/Decodificador de URL
• Generador de hash
• Generador de UUID
• Lector de códigos QR
• Formateador JSON
• Validador JSON
• Minificador JSON
• XML a JSON
• Conversor de mayúsculas
• Recortador de texto
• Conversor de color
• Todos los conversores