Guía del codificador y decodificador Base64: UTF-8, Base64url y errores

Cómo codificar o decodificar texto

Abre el codificador y decodificador Base64 y pega texto o una cadena codificada. Deja desactivada la opción de Base64 seguro para URL si necesitas el alfabeto estándar, o actívala cuando el formato de destino exija Base64url. Codificar convierte toda la entrada a Base64; Decodificar la convierte de nuevo en texto UTF-8. Escribir por sí solo no inicia una conversión.

Lee el resultado antes de pulsar Copiar resultado o Descargar. Usar resultado como entrada sustituye el contenido del editor por un resultado que respete el límite de entrada; después puedes elegir la acción opuesta para comprobar la ida y vuelta. Editar la entrada o cambiar las opciones de conversión invalida el resultado anterior. Ajustar líneas cambia la distribución visual, no los caracteres codificados ni los saltos de línea del contenido.

• Empieza con un ejemplo conocido, como foo y Zm9v, antes de investigar un valor de tu aplicación.
• Elige el alfabeto que necesita tu aplicación; solo las letras y los dígitos comunes pueden no revelar qué variante usa una cadena.
• Conserva el original si necesitas preservar cada byte. Importar texto, cambiar su codificación o añadir saltos de línea puede alterar lo que codificas.

Qué hace Base64 con los bytes

Base64 divide cada grupo de tres bytes en cuatro valores de seis bits y los asigna a caracteres de su alfabeto. El último grupo, si está incompleto, requiere un tratamiento especial y puede llevar relleno. Las letras visibles representan los bytes de entrada; no constituyen un idioma nuevo ni una clave secreta.

Estos ejemplos con el alfabeto estándar incluyen la cadena vacía y terminaciones ASCII de uno, dos y tres bytes. Los espacios y los saltos de línea del texto que codificas son bytes reales y cambian el resultado. Decodificar la misma representación canónica restaura el texto UTF-8 original, incluidos esos caracteres.

RFC 4648: Base64, Base64url, relleno y codificación canónica

Base64 estándar frente a Base64url

Ambas variantes usan letras y dígitos. Base64 estándar utiliza + y / como los dos últimos símbolos del alfabeto; Base64url utiliza - y _. ToolMellow añade los signos = finales que sean necesarios en el modo estándar y los omite en el modo seguro para URL. Por ejemplo, el emoji anterior se convierte en 8J-YgA en ese modo.

El decodificador solo acepta el alfabeto seleccionado. Los dos modos admiten entradas sin relleno o con relleno opcional colocado correctamente. Base64url no prohíbe el relleno de forma universal: el protocolo que lo utiliza determina si es obligatorio, permitido u omitido. Elige el formato necesario en lugar de suponer que todas las URL o los tokens siguen la misma convención.

RFC 4648: Base64, Base64url, relleno y codificación canónica

Unicode, emojis y decodificación UTF-8

El texto se convierte a través de UTF-8, por lo que los acentos, el chino, el árabe y los emojis pueden conservarse en una conversión de ida y vuelta si la entrada es Unicode bien formado. La longitud de una cadena de JavaScript cuenta unidades de código UTF-16; la longitud en bytes UTF-8 es distinta. El emoji 😀 ocupa dos unidades UTF-16, pero cuatro bytes UTF-8, que generan ocho caracteres Base64 con relleno.

La codificación rechaza un sustituto Unicode sin pareja. La decodificación rechaza UTF-8 no válido en lugar de sustituir silenciosamente los bytes incorrectos. Un BOM UTF-8 codificado al principio se conserva como U+FEFF en la cadena decodificada y puede ser invisible en el editor. Un texto válido también puede contener caracteres de control o distintas formas de normalización Unicode. Base64 no normaliza el texto ni hace que sea seguro ejecutarlo.

RFC 3629: codificación de caracteres UTF-8WHATWG Encoding: TextEncoder, TextDecoder y tratamiento del BOMECMAScript: longitud de cadenas e isWellFormed

Relleno, espacios en blanco y bits sin usar

El relleno consta de un máximo de dos caracteres = al final, y la longitud con relleno debe ser divisible entre cuatro. El decodificador también permite entradas sin relleno con una terminación válida, pero una longitud restante de uno no puede representar un byte completo. Tanto Zg== como Zg se decodifican como f; Zg= está mal formado. Una entrada vacía produce un resultado vacío válido.

Antes de decodificar, ToolMellow elimina únicamente TAB, LF, CR y SPACE. Rechaza el salto de página, la tabulación vertical, el espacio de no separación y otros espacios en blanco Unicode. El límite de la entrada original se comprueba antes de eliminarlos. Por tanto, su comportamiento es más restringido que una promesa general de ignorar todos los espacios en blanco.

En esta herramienta, los bits sin usar del último símbolo del alfabeto deben ser cero. Se comprueba que volver a codificar los bytes decodificados coincida con la entrada normalizada sin relleno. Zh== se rechaza, aunque un decodificador permisivo podría obtener el mismo byte que con la forma canónica Zg==. RFC 4648 permite este rechazo más estricto; que otro decodificador acepte la entrada no demuestra que sea canónica.

RFC 4648: Base64, Base64url, relleno y codificación canónicaWHATWG Infra: decodificación Base64 permisivaWHATWG HTML: atob y btoa

Cuánto aumenta el tamaño con Base64 y qué cabe

Para n bytes de entrada, la longitud de Base64 con relleno es de 4 × ceil(n / 3) caracteres. Cero bytes producen cero caracteres; un byte produce cuatro, dos producen cuatro y tres producen cuatro. El aumento se aproxima a un tercio con entradas grandes, pero no es exactamente del 33% para todos los valores. La salida segura para URL sin relleno elimina el último o los dos últimos caracteres de relleno cuando corresponde.

Cuenta bytes UTF-8 para la fórmula de tamaño y unidades de código UTF-16 para el límite del editor. La herramienta permite hasta 1,000,000 unidades de código de entrada, antes de eliminar los espacios en blanco al decodificar. No aplica el mismo máximo a la salida: un millón de bytes ASCII producen 1,333,336 caracteres con relleno. Copiar y Descargar siguen disponibles, pero Usar resultado como entrada no puede cargar un resultado que supere el límite de entrada.

RFC 4648: Base64, Base64url, relleno y codificación canónicaWHATWG Encoding: TextEncoder, TextDecoder y tratamiento del BOMECMAScript: longitud de cadenas e isWellFormed

Abrir un archivo de texto no equivale a codificar un archivo binario

El control de archivos lee un archivo local como texto UTF-8 mediante File.text(). Se rechaza cualquier archivo de 4,000,000 bytes o más; también se rechaza el texto que, una vez leído, supere 1,000,000 unidades UTF-16. La aplicación no sube el archivo para realizar esta conversión. La extensión del nombre no demuestra que los bytes sean texto UTF-8.

La lectura normal de un archivo como texto elimina un BOM UTF-8 inicial y sustituye las secuencias UTF-8 mal formadas. Esto puede cambiar los bytes originales antes de codificarlos. Es distinto del decodificador Base64, que rechaza UTF-8 mal formado y conserva U+FEFF al decodificar. Para imágenes, PDF, bytes arbitrarios o recuperación exacta de los bytes de un archivo, utiliza la herramienta independiente Base64 a archivo cuando corresponda; este espacio de texto no es un codificador de archivos binarios en bruto.

API de archivos de W3C: lectura de Blob como textoWHATWG Encoding: TextEncoder, TextDecoder y tratamiento del BOM

Por qué mi Base64 no es válido

Primero identifica el formato esperado y si el valor debe decodificarse como texto. Retira deliberadamente la sintaxis de la aplicación que rodea al valor, en lugar de borrar caracteres desconocidos hasta que funcione. Este decodificador no extrae automáticamente cargas de URL de datos, segmentos de tokens, cadenas JSON entre comillas ni HTML. Esos formatos envolventes tienen sus propias reglas de análisis y validación.

Si el alfabeto y la estructura son válidos, pero los bytes decodificados no son UTF-8, los datos pueden corresponder a un archivo binario o a otra codificación de caracteres. Es un error por el alcance textual de la herramienta, no una prueba de que los bytes Base64 estén dañados. Si no puedes acceder al portapapeles, selecciona el resultado y cópialo manualmente. Un navegador no compatible o un worker bloqueado también pueden impedir la conversión; utiliza un navegador actual compatible y lee el error que aparece.

RFC 4648: Base64, Base64url, relleno y codificación canónicaRFC 3629: codificación de caracteres UTF-8

Base64url, codificación porcentual y URL de datos

Base64url y la codificación porcentual resuelven problemas distintos. La codificación porcentual representa determinados bytes de una URL mediante secuencias con %; Base64url representa una secuencia completa de bytes con su propio alfabeto. Un signo de más se convierte en un espacio específicamente al analizar application/x-www-form-urlencoded, no en todas las URL. Utiliza el codificador y decodificador de URL para esa tarea aparte.

Una URL de datos lleva el esquema data:, un tipo de medio opcional y una coma antes de la carga, con un indicador Base64 cuando corresponde. Pegar la estructura completa en este decodificador de texto hace que falle la comprobación del alfabeto. Extrae la carga prevista con la herramienta adecuada y determina si se trata de texto o de datos binarios. Base64 no hace que un script, documento o archivo descargado sea de confianza.

WHATWG URL: análisis de formularios codificados para URLRFC 2397: esquema de URL de datos

Los segmentos JWT y HTTP Basic son datos de protocolo

JWS compacto utiliza tres segmentos separados por puntos; JWE compacto utiliza cinco. Decodificar un segmento textual de un JWT puede revelar JSON, pero no verifica una firma, no descifra contenido cifrado, no valida la caducidad y no establece una autorización. Un segmento de firma puede contener bytes arbitrarios y no tiene por qué decodificarse como UTF-8. Sigue el protocolo real del token y utiliza una biblioteca de verificación mantenida en tu aplicación.

Las credenciales HTTP Basic utilizan una representación Base64 de una secuencia de nombre de usuario y contraseña, con reglas de codificación de caracteres propias del protocolo. Base64 no aporta confidencialidad. Esta herramienta de texto UTF-8 no demuestra que unas credenciales coincidan con la interpretación de todos los servidores. No publiques credenciales reales en los ejemplos y utiliza el transporte seguro y el procedimiento de autenticación requeridos.

RFC 7515: serialización compacta de JSON Web SignatureRFC 7516: serialización compacta de JSON Web EncryptionRFC 7617: autenticación HTTP Basic

Base64 no es cifrado, hash ni compresión

Cualquiera que disponga de un valor Base64 puede invertir la representación sin una clave secreta. El cifrado requiere una construcción criptográfica y gestión de claves; un hash genera un resumen con finalidades y propiedades diferentes. Convertir una contraseña a Base64 no es una forma adecuada de almacenarla. La herramienta independiente de hash genera resúmenes, no un sistema de almacenamiento de contraseñas ni un sustituto del cifrado.

Base64 también aumenta el tamaño de los bytes en lugar de comprimirlos. Puede transportar bytes cifrados, comprimidos o firmados, pero no crea esas protecciones por sí mismo. Decide qué necesita tu aplicación antes de añadir una capa de codificación y evita incluir secretos en ejemplos compartidos, capturas de pantalla y resultados descargados.

RFC 4648: Base64, Base64url, relleno y codificación canónica

Copiar, descargar, comprobar y vaciar

Descargar guarda el resultado como texto UTF-8 en toolmellow-result.txt. No es una reconstrucción binaria ni un informe de conversión. Un resultado vacío válido también habilita Copiar resultado y Descargar. Para una comprobación sencilla, codifica un texto conocido, usa el resultado como entrada si cabe, decodifícalo con el alfabeto correspondiente y compáralo con el texto original.

Vaciar elimina la entrada, el resultado, los errores, el contenido de búsqueda y sustitución y el historial del editor; conserva las opciones de Base64 seguro para URL y Ajustar líneas. Actualizar o cerrar el espacio de trabajo descarta los datos de trabajo que mantiene en memoria; los archivos ya descargados permanecen en tu dispositivo. Vaciar no garantiza un borrado forense de la memoria del navegador o del sistema operativo.

Qué significa el procesamiento local y cuáles son sus límites

La conversión se ejecuta en un worker del navegador. La aplicación no envía a un servidor de conversión el texto pegado, el contenido de los archivos seleccionados ni los resultados. La entrada de trabajo se mantiene en la página actual, en lugar de guardarse en el historial de una cuenta. Consulta la página de privacidad del sitio para obtener la explicación completa del almacenamiento y de las transferencias temporales.

Cargar el sitio web sí genera solicitudes de red. La infraestructura de alojamiento recibe metadatos habituales de conexión y solicitudes, y el sitio público utiliza Google Analytics para las visitas, con cookies e información del navegador y del dispositivo. La conversión local no implica anonimato ni una promesa de ausencia de tráfico de red o de registros de infraestructura. Los archivos descargados y los resultados copiados manualmente pueden salir del espacio de trabajo por tus propias acciones.

Integra la herramienta Base64 con su enlace de atribución

Abre la sección de integración situada debajo del espacio de trabajo, elige el idioma de la página y copia o descarga el fragmento HTML proporcionado. Pégalo en un área HTML que permita iframes y scripts externos. El fragmento incluye el iframe del espacio de ToolMellow, su script de ajuste de tamaño y un enlace visible de vuelta a la página de la herramienta ToolMellow en el idioma correspondiente. Conserva ese enlace de atribución.

Previsualiza la integración y comprueba las pantallas estrechas. Conserva el mismo alcance de texto y los límites de entrada; no es una API remota de conversión ni un codificador de archivos binarios. El acceso al portapapeles depende de los permisos del navegador, y tu plataforma debe permitir los recursos externos. El enlace proporcionado utiliza nofollow y noopener; su presencia no garantiza mejoras en el posicionamiento en buscadores.

Preguntas frecuentes

Fuentes y lecturas adicionales

• RFC 4648: Base64, Base64url, relleno y codificación canónica
• RFC 3629: codificación de caracteres UTF-8
• WHATWG Encoding: TextEncoder, TextDecoder y tratamiento del BOM
• ECMAScript: longitud de cadenas e isWellFormed
• WHATWG Infra: decodificación Base64 permisiva
• WHATWG HTML: atob y btoa
• API de archivos de W3C: lectura de Blob como texto
• WHATWG URL: análisis de formularios codificados para URL
• RFC 2397: esquema de URL de datos
• RFC 7515: serialización compacta de JSON Web Signature
• RFC 7516: serialización compacta de JSON Web Encryption
• RFC 7617: autenticación HTTP Basic