Saltar al contenido principal
ToolsByUs

Base64 a hexadecimal

Este convertidor decodifica Base64 según RFC 4648 y vuelve a codificar los mismos bytes como hexadecimal en minúsculas en tu navegador. Se maneja el relleno, se acepta el alfabeto seguro para URL y cada byte se mapea exactamente a dos dígitos hexadecimales en el orden de salida: sin prefijos, sin separadores, sin subir nada.

Solo local

Base64 a hexadecimal: explicación

Base64 y hex son dos maneras de escribir los mismos bytes, y este convertidor te cambia de uno a otro: decodifica el Base64 exactamente como prescribe RFC 4648, luego imprime cada byte decodificado como dos dígitos hexadecimales en minúsculas. Nada se reinterpreta en el proceso — lo que obtienes es la secuencia de bytes que te mostraría un editor hexadecimal, carácter por carácter.

Las partes interesantes son las que otros convertidores suelen omitir. Relleno: los caracteres = al final se manejan, y también se acepta entrada cuyo relleno una pipeline haya eliminado. Alfabetos: se decodifica el conjunto estándar A–Z a–z 0–9 + /, y la variante URL-safe con -_ definida en el mismo RFC se normaliza antes de decodificar. Orden de bytes: se conserva — un byte se convierte en dos dígitos hexadecimales, con el nibble alto primero, siempre.

Como todas las herramientas de este sitio, la conversión se ejecuta en esta pestaña del navegador: tu texto nunca sale de tu máquina, no se realiza ninguna petición y el Content-Security-Policy prohíbe que la página se conecte a ningún sitio. El panel Network de DevTools se quede vacío mientras conviertes es la prueba, no la promesa.

El viaje inverso — bytes mostrados como hex, destinados a una cabecera o un campo de token — es lo que la herramienta hermana convertidor de Hex a Base64 realiza, con el mismo alfabeto RFC 4648 y el mismo procesamiento local.

Si las reglas de agrupación y relleno te parecen arbitrarias, la guía sobre cómo funciona realmente Base64 construye todo el mecanismo desde los primeros principios en tres párrafos cortos.

Cómo funciona realmente la conversión

La conversión tiene dos etapas bien definidas sin nada oculto entre ellas, y cada etapa tiene una política que puedes exigirle:

  • Normalizar: se eliminan los espacios en blanco, saltos de línea (entrada con formato MIME) y un ? inicial; los caracteres URL-safe - y _ se mapean a + y / según el segundo alfabeto de RFC 4648.
  • Decodificar: los caracteres restantes se mapean a través del alfabeto RFC 4648 — 4 caracteres a 3 bytes — consumiendo el relleno = en el último quantum.
  • Validar: cualquier carácter fuera del alfabeto es un error con nombre y su posición; se rechaza de plano una longitud de igual a un múltiplo de 4 más 1, porque un carácter sobrante no puede formar un byte por sí solo.
  • Emitir: cada byte se convierte en dos dígitos hexadecimales en minúsculas, con el nibble alto primero, concatenados sin separadores ni prefijo 0x.

Relleno y alfabetos, con precisión

El alfabeto estándar de RFC 4648 es A–Z, a–z, 0–9, + y /, con = como relleno en el último quantum cuando el recuento de bytes no es múltiplo de 3. El relleno tiene significado — desambigua un último quantum de un byte frente a dos — pero el decodificador también acepta entrada sin relleno cuando la longitud hace que el quantum no sea ambiguo (longitudes de 2 o 3 mod 4). Una longitud de 1 mod 4 es inválida con o sin relleno — un único carácter Base64 no puede producir un byte completo — y se rechaza en lugar de rellenarse con ceros.

La variante URL-safe definida en el mismo RFC — guion y guion bajo en lugar de más y barra diagonal — se acepta y normaliza, lo que es relevante en la práctica porque los JWT y los parámetros de URL suelen emitirse sin relleno y en formato URL-safe. Se rechaza mezclar ambos alfabetos en una entrada: una cadena que contiene tanto + como - no tiene una interpretación coherente.

Cómo es la salida

El ejemplo a continuación es el par exacto que produce el botón Cargar ejemplo: el Base64 de «Hello world» convertido en 22 dígitos hexadecimales en minúsculas — dos por byte, once bytes. La salida es una cadena continua — sin prefijo 0x, sin espacios, sin saltos de línea — porque los editores hexadecimales, dissectores y código prefieren la forma plana. La aritmética de longitudes: Base64 usa 4 caracteres por cada 3 bytes, mientras que hex usa 2 por cada byte, por lo que hex resulta unas 1.5 veces más largo que el Base64 sin relleno — una propiedad de las codificaciones, no de tus datos.

Orden de bytes, una vez por todas

La endianidad nunca entra en juego, y conviene decir por qué. Base64 se decodifica a una secuencia de bytes, y una secuencia tiene un orden natural: el primer byte decodificado primero. La salida hexadecimal refleja ese orden exactamente — el byte n se convierte en los caracteres hexadecimales en las posiciones 2n y 2n+1 — así que el resultado es la misma cadena que mostraría un editor hexadecimal sin desplazamientos. No hay intercambio de palabras, ni reinterpretación little-endian, ni sorpresas cuando lo comparas con xxd.

Preguntas frecuentes

¿Convertir Base64 a hex sube mis datos a algún sitio?

No. La decodificación y recodificación ocurren dentro de esta pestaña del navegador, en JavaScript que se cargó con la página. No hay una ruta de subida en el código de la página, y el Content-Security-Policy del sitio prohíbe las conexiones salientes. Para comprobarlo tú mismo: abre DevTools, limpia o observa el panel Network, convierte y comprueba que no aparece ninguna petición — la herramienta funciona sin conexión a red.

¿La salida hexadecimal está en mayúsculas o minúsculas?

Siempre en minúsculas — la misma convención que usa xxd y la mayoría de editores hexadecimales. Las mayúsculas y minúsculas en hexadecimal denotan bytes idénticos, y un paso de conversión a mayúsculas no implica pérdidas si un sistema las exige. La salida no lleva prefijo 0x, separadores ni saltos de línea, por lo que se pega tal cual en código, dissectores y fixtures de prueba.

¿Por qué la cadena hexadecimal es más larga que la entrada Base64?

Es aritmética de las dos codificaciones: Base64 empaqueta 3 bytes en 4 caracteres (unos 33% de sobrecarga), mientras que hex usa 2 caracteres por cada byte (100% de sobrecarga). Dividiendo las dos, hex resulta unas 1.5 veces más largo que Base64 sin relleno para los mismos bytes. Ninguna codificación comprime nada — ambas son solo alfabetos sobre la misma secuencia de bytes.

¿La entrada necesita su relleno =?

No. La entrada con relleno se decodifica tal cual, y el relleno que alguna pipeline haya eliminado se reconstruye a partir de la longitud — una longitud de 2 o 3 mod 4 identifica el último quantum sin ambigüedad. La única longitud que siempre es inválida es 1 mod 4, con o sin relleno, porque un único carácter Base64 no puede producir un byte completo; esa entrada se rechaza con un error claro, nunca se adivina.

¿Es la conversión de Base64 a hexadecimal una forma de descifrado?

No, y la diferencia importa. Tanto Base64 como hex son codificaciones: maneras reversibles de escribir los mismos bytes sin clave alguna en el proceso. Cualquiera puede decodificar cualquiera de los dos, incluyendo esta página, sin conexión. Si tu Base64 contenía texto cifrado, convertirlo a hexadecimal solo cambia la representación — los datos son exactamente tan legibles, o tan protegidos, como antes.

¿Y el Base64 seguro para URL con caracteres - y _?

Se acepta y maneja. RFC 4648 define el alfabeto seguro para URL — guion para más, guion bajo para barra diagonal — para contextos donde + y / se corromperían, como en JWT y segmentos de ruta de URL. El convertidor normaliza esos caracteres al alfabeto estándar antes de decodificar, por lo que un token copiado directamente de una cabecera Authorization funciona sin modificaciones. Solo se rechaza una mezcla de ambos alfabetos.

Equipo de ToolsByUs · Cómo comprobamos nuestras herramientas