Herramienta online de codificación y decodificación Base64

1. 1

   Elige una dirección

   Selecciona Codificar para convertir contenido en Base64, o Decodificar para recuperar el texto o el archivo original a partir de una cadena Base64.

2. 2

   Aporta la entrada

   Escribe o pega en el cuadro, o suelta un archivo. La codificación acepta cualquier archivo; la decodificación acepta archivos de texto con Base64, incluidos certificados PEM con sus líneas BEGIN y END.

3. 3

   Fija el formato

   Elige el alfabeto estándar o el seguro para URL, decide si conservas el relleno, ajusta a 64 o 76 caracteres y activa la opción de URI de datos si el resultado va a HTML o CSS.

4. 4

   Revisa el resultado

   El texto escrito se convierte sobre la marcha. El panel informa del tamaño de entrada, el de salida y la sobrecarga, y al decodificar indica el alfabeto detectado, la codificación de texto usada y el tipo de archivo encontrado.

5. 5

   Copia o descarga

   Copia el resultado al portapapeles, descárgalo con un nombre acorde a lo que realmente es, o descarga un lote completo en un solo ZIP. Nada sale de tu dispositivo en ningún momento.

Nueve ajustes, y todos existen porque algún formato real los necesita. Esto es lo que cambia cada uno y cuándo importa.

Alfabetos estándar y seguro para URL

Base64 necesita sesenta y cuatro caracteres imprimibles. Cincuenta y dos letras y diez dígitos llegan a sesenta y dos, y los dos últimos son en los que discrepan las dos variantes. El alfabeto estándar del RFC 4648 sección 4 usa el signo más y la barra, lo correcto para cuerpos de correo y campos de API. La variante segura para URL de la sección 5 usa guion y guion bajo, porque una barra divide una ruta y un más significa espacio en una cadena de consulta. Todo lo demás es idéntico, y por eso una carga formada solo por letras y dígitos se decodifica igual con cualquiera de los dos.

El relleno y cuándo quitarlo

Base64 trabaja en grupos de tres bytes, así que una carga cuya longitud no sea múltiplo de tres termina con un grupo incompleto. Los signos igual indican cuánto le falta. El Base64 estándar los conserva; el seguro para URL normalmente no, porque un JSON Web Token pone tres segmentos Base64 seguidos separados por puntos y el relleno estorbaría. Quitar el relleno no pierde nada: el decodificador puede deducir cuántos bytes lleva el último grupo solo por su longitud, y por eso esta herramienta te restaura el relleno cuando pegas una cadena sin él.

Ajuste de línea para PEM y MIME

Dos formatos exigen saltos de línea dentro de la carga. PEM, definido por el RFC 7468, ajusta a sesenta y cuatro caracteres, y OpenSSL rechazará un certificado que llegue en una sola línea larga. MIME, definido por el RFC 2045 sección 6.8, exige líneas de no más de setenta y seis caracteres en un cuerpo de correo, en parte porque los transportes antiguos insertaban sus propios saltos y corrompían la carga al hacerlo. Aquí, por defecto, no hay ajuste, porque los otros dos grandes consumidores de Base64 —un URI de datos y un campo JSON— necesitan una sola línea continua, y un salto de línea dentro de un URI de datos impide que cargue.

Codificar cada línea por separado

A veces lo que tienes no es una carga sino una lista: una columna de valores, un conjunto de credenciales, un registro por línea. Codificar el bloque entero te da una única cadena que hay que decodificar y volver a dividir. Codificar cada línea por separado te da un valor Base64 por línea, listo para pegar en una columna. Los finales de línea de Windows están contemplados: el retorno de carro se trata como parte del salto y no como el último carácter de la línea, una diferencia que solo notarías más tarde, como un carácter invisible al final de cada valor decodificado.

Validación estricta

Casi todo el Base64 que llega a una persona ha pasado por algo: un cliente de chat que añadió una comilla, un documento que convirtió un guion en una raya, un terminal que ajustó una línea. La decodificación indulgente ignora lo que no pertenece al alfabeto y repara el relleno que falta, que es lo que quieres la mayoría de las veces. La validación estricta es para cuando necesitas saber que la carga es exactamente la que se produjo: rechaza caracteres desconocidos, rechaza relleno en mitad de la cadena y rechaza un carácter final cuyos bits sobrantes no sean cero, el único fallo que de otro modo es completamente invisible porque esos bits se descartan de todas formas.

Codificaciones de texto a la salida

Decodificar te da bytes, y convertir bytes en texto legible es una segunda decisión que la herramienta tiene que acertar. Lee una carga Windows-1252 como UTF-8 y cada comilla tipográfica se convierte en un carácter de reemplazo; lee UTF-16 como UTF-8 y obtienes un NUL entre cada letra. Se ofrecen siete codificaciones junto con una detección automática que primero lee una marca de orden de bytes, luego comprueba los bytes contra las reglas de UTF-8, después busca el patrón denso y unilateral de NUL que solo produce UTF-16, y solo entonces recurre a Windows-1252, que va la última porque es la única de las ocho capaz de decodificar cualquier secuencia de bytes, así que cualquier cosa anterior no llegaría nunca a su turno.

Base64 te permite mover cargas binarias por sistemas que solo toleran texto plano, mantiene la configuración portátil y encaja bien con APIs y marcado que incrustan recursos pequeños. Codifica texto a Base64 o decodifícalo, desde texto o desde archivos, con conversión en vivo mientras escribes.

Para qué sirve Base64

• Transporte: Mueve bytes con seguridad por correo, JSON, XML o registros sin corromper los finales de línea.
• Incrustación: Inserta imágenes o fuentes diminutas como URI de datos cuando un archivo aparte resulta incómodo.
• Interoperabilidad: Comparte la misma representación segura en ASCII entre Windows, macOS, Linux y la web.
• Almacenamiento: Guarda blobs opacos en almacenes orientados a texto cuando no hay columnas binarias.
• Depuración: Inspecciona respuestas de API o certificados como cadenas legibles durante el desarrollo.
• Tokens: Lee la cabecera y la carga de un JSON Web Token, que son Base64 seguro para URL sin relleno.

Tus bytes se dividen en grupos de seis bits; cada grupo se asigna a un carácter del alfabeto y el relleno mantiene la longitud como múltiplo de cuatro caracteres.

Cadena de codificación

• Entrada: El texto se convierte en bytes con la codificación que elijas; los archivos ya son bytes y se leen directamente.
• Agrupación de bits: El flujo de bytes se trocea para que cada índice seleccione uno de sesenta y cuatro símbolos.
• Relleno: Los símbolos = finales marcan cuándo el último trozo necesitó bits de relleno.
• Formato: El resultado se deja en una línea, se ajusta a 64 o 76 caracteres, o se envuelve como URI de datos.
• Salida: Obtienes texto listo para pegar en código, un archivo de configuración, una hoja de estilos o una petición de API.
• Decodificación: Los pasos se recorren al revés para recuperar la secuencia de bytes original, que después se lee como texto o se devuelve como archivo.

Un URI de datos transporta un archivo entero dentro de una sola cadena, así que una imagen, un icono o una fuente pequeños pueden vivir en el HTML o en la hoja de estilos que los usa en vez de en una petición aparte. Es la razón más común por la que alguien abre un codificador Base64.

La forma de un URI de datos

La gramática es data:, luego un tipo de medio opcional, luego parámetros opcionales, luego una coma y luego la carga. Cuando la carga es Base64, la palabra base64 aparece justo antes de la coma. El tipo de medio importa más de lo que parece: un URI de datos sin él se toma como texto plano, así que un PNG escrito sin tipo se muestra como una imagen rota en una etiqueta img y como nada en CSS. Esta herramienta siempre escribe el tipo de medio, deduciéndolo de los bytes mágicos del propio archivo cuando el archivo no lo declara.

Cuándo incrustar y cuándo no

Incrustar elimina una petición, lo que merece la pena para algo diminuto que se necesita de inmediato: un logotipo en una plantilla de correo, un icono en una hoja de estilos, un marcador de posición en una prueba. Deja de merecer la pena enseguida. Base64 añade en torno a un tercio del tamaño, un recurso incrustado no se puede cachear por separado del documento que lo lleva, y un URI de datos grande hace que el propio documento tarde más en analizarse. Como regla práctica, incrusta lo que se mide en kilobytes y aloja lo que se mide en cientos de kilobytes.

En cuanto una cadena Base64 tiene que viajar dentro de una URL, el alfabeto estándar se convierte en un problema, y la solución es una variante que está en el estándar desde 2006.

Por qué el más y la barra fallan en una URL

Una barra separa segmentos de ruta, así que una carga que contenga una se lee como dos segmentos. Un más se decodifica como espacio en una cadena de consulta por convención de siempre, así que una carga que contenga uno vuelve alterada. Un signo igual separa un parámetro de su valor. Los tres aparecen en la salida Base64 corriente, y por eso el RFC 4648 sección 5 define la variante segura para URL: guion por más, guion bajo por barra, y relleno que puedes omitir.

Leer un JSON Web Token

Un JWT son tres segmentos Base64 seguros para URL separados por puntos, sin relleno. Pega un segmento aquí y se decodifica sin cambiar ningún ajuste, porque el alfabeto se detecta a partir de la cadena y el relleno que falta se suple. La cabecera y la carga son JSON legible. La firma no está pensada para leerse y volverá como bytes: decodifícala a un archivo en vez de a texto, o parecerá un fallo de decodificación cuando no lo es en absoluto. Base64 no es cifrado y la carga de un JWT no es secreta: cualquiera que tenga el token puede leerla exactamente igual que acabas de hacerlo tú.

La mayoría de los problemas que se reportan con Base64 no son problemas de Base64. Son una cadena que ha pasado por algo por el camino, y lo útil que puede hacer una herramienta es decir por qué algo.

Los fallos que conviene conocer

Una longitud que deja un carácter suelto no puede ser Base64 en absoluto —ninguna secuencia de bytes se codifica así—, así que casi siempre es un carácter perdido al copiar. El relleno en mitad de la cadena suele significar que se pegaron dos cargas seguidas. Los caracteres fuera del alfabeto suelen ser puntuación que introdujo un cliente de chat o un procesador de textos, y el espacio duro es el cruel porque es invisible. Una mezcla de más-barra y guion-guion bajo significa que un buscar y reemplazar pasó por media cadena. Un carácter final cuyos bits sobrantes no son cero significa que la cadena se alteró después de codificarse, y es el único de estos que no produce ningún síntoma visible, porque esos bits se descartan al decodificar de todos modos.

Hábitos que evitan todo esto

Copia desde una vista de texto plano y no desde una renderizada. Decide una vez si tu API espera Base64 estándar o seguro para URL y déjalo escrito donde lo vea quien la llame. Cuando una carga tenga que sobrevivir a un cuerpo de correo o a un archivo de certificado, ajústala como ese formato exige en vez de confiar en que nada rompa la línea por ti. Y cuando algo falle, mira primero la longitud: es una comprobación de un segundo que descarta la mitad de las posibilidades.

Conocer la sobrecarga de tamaño y la diferencia con el cifrado evita expectativas equivocadas en sistemas en producción.

Referencia rápida

• Espera un aumento de tamaño de alrededor del treinta y tres por ciento frente al binario original de la misma carga.
• El alfabeto MIME usa A–Z, a–z, 0–9, más + y /; las variantes seguras para URL cambian los símbolos pero siguen la misma idea.
• Los caracteres de relleno mantienen alineados a los decodificadores cuando el número de bytes no es divisible entre tres.
• Base64 es reversible y determinista para los alfabetos estándar, y por eso nunca debe sustituir al cifrado.
• Los archivos muy grandes se convierten en cadenas muy largas; los navegadores pueden ir más lentos simplemente porque la cadena es enorme.
• Cuatro caracteres Base64 siempre llevan exactamente tres bytes, así que puedes calcular el tamaño decodificado antes de decodificar nada.

Buenas prácticas

Usa la herramienta adecuada: Base64 para transporte e incrustación, cifrado para confidencialidad, compresión antes de codificar cuando el ancho de banda importa.

• Valida la salida decodificada en un entorno de pruebas antes de fiarte de procesos automáticos.
• Quita el espacio en blanco de las cadenas pegadas si copiaste desde documentos con formato.
• Prefiere alojamiento de recursos dedicado para medios grandes en vez de URI de datos gigantescos.
• Documenta si tu API espera Base64 estándar o seguro para URL, para evitar errores sutiles.
• Nunca guardes contraseñas o secretos solo tras un Base64: se decodifican al instante.
• Comprime antes de codificar, nunca después: la salida Base64 es texto y comprime mucho peor que los bytes de los que salió.

Casos de uso habituales

• Desarrollo web: Experimenta con URI de datos o simula respuestas de API que llevan muestras binarias.
• Automatización: Prepara cargas para scripts que solo aceptan entrada de texto.
• Correo y MIME: Entiende adjuntos que históricamente se codificaban para rutas SMTP de siete bits.
• Configuración: Serializa claves cortas o sumas de verificación en archivos tipo .env.
• Educación: Demuestra cómo se apilan las capas de representación sobre los bits en bruto.
• Certificados: Lee un bloque PEM sin línea de comandos: pégalo con sus líneas BEGIN y END incluidas.

Ambas direcciones aceptan archivos, lo cual es poco común: la mayoría de las herramientas Base64 codifican un archivo y luego te obligan a pegar texto para volver.

Qué archivos acepta cada dirección

La codificación acepta cualquier cosa, porque Base64 está definido sobre bytes arbitrarios y no hay archivo que no pueda representar. La decodificación acepta archivos cuyo contenido sea texto Base64 —.txt, .b64, .pem, .crt, .key y las demás extensiones de texto plano— y rechaza el resto en el momento en que lo eliges, con un enlace para cambiar de dirección, en vez de aceptarlo y fallar después. Una vez decodificados, los bytes se identifican por sus propios números mágicos, así que un PNG decodificado se devuelve como .png y un PDF decodificado como .pdf.

Qué incluye el plan gratuito y qué añade Pro

El plan gratuito convierte un archivo cada vez, hasta 25 MB. Es una decisión de plan y no un límite del dispositivo: aquí un archivo de 25 MB se codifica en unas centésimas de segundo, y el trabajo nunca toca la página que estás mirando. Pro pone en cola hasta cien archivos, los convierte uno tras otro y te los devuelve en un único ZIP con los nombres duplicados diferenciados, lo cual importa más de lo que parece, porque dos archivos llamados foto.png de carpetas distintas se convertirían en una sola entrada y el ZIP contendría en silencio menos archivos de los que convertiste.

Base64 es una representación, no una compresión ni una protección. Agranda los datos, cualquiera puede revertirlo trivialmente, y nunca debería ser lo único que separa un secreto de quien lea tu archivo de configuración. Tampoco puede reparar datos que ya estaban mal antes de codificarse.

Todo se ejecuta en tu dispositivo. La conversión ocurre fuera de la página, así que escribir sigue siendo fluido por grande que sea la carga, y un archivo de 25 MB se convierte en unas quince milésimas de segundo en un navegador de escritorio actual. No se sube nada, y la herramienta sigue funcionando con la red desconectada una vez cargada la página.

• Codificador Base64
• Decodificador Base64
• Codificador/decodificador de URL
• Todos los conversores
• Generador de hash
• Generador de UUID
• Formateador JSON
• Generador de códigos QR
• Lector de códigos QR
• Conversor de color
• Comprimir una imagen antes
• Generador de favicon
• Escapar JSON
• Minificador JSON
• Recortador de texto
• Todas las herramientas de texto