Hexadecimal a Base64
Este conversor vuelve a codificar una cadena hexadecimal como Base64 estándar en tu navegador. La entrada no distingue entre mayúsculas y minúsculas, se eliminan los prefijos 0x y los espacios sueltos, y la salida sigue RFC 4648 con relleno. Las entradas de longitud impar se rechazan directamente: nunca se adivina un nibble faltante. No se sube nada.
Hexadecimal a Base64: explicación
Hex es la forma en que los programadores escriben bytes; Base64 es la forma en que se envían por la red. Este conversor lee una cadena hexadecimal de dos en dos y vuelve a codificar los mismos bytes con el alfabeto estándar RFC 4648, incluido el relleno — la cadena exacta que un codificador correcto emitiría para los datos subyacentes, lista para un encabezado, un archivo de configuración o un campo de token.
El hexadecimal del mundo real es desordenado, y el conversor se adapta: los dígitos en mayúsculas y minúsculas son iguales, se eliminan los prefijos 0x donde aparezcan y se limpian los espacios sueltos — volcados en columnas, pares espaciados, saltos de línea — antes de analizar. Lo que no hará es adivinar. Un número impar de dígitos hexadecimales significa que falta un nibble en algún lugar, y el conversor se niega a inventar dónde.
La conversión es enteramente local, como en todas partes de este sitio: tu cadena se analiza y codifica en esta pestaña del navegador, no se realiza ninguna petición, y la política de seguridad de contenido de la página prohíbe las conexiones salientes. El panel de Red quedando vacío mientras conviertes es la prueba, verificable en segundos.
Comprobar el resultado a mano es fácil en la dirección opuesta: introduce el resultado en el hermano Conversor de Base64 a Hex y deberías obtener tu cadena hexadecimal original, byte por byte.
Elegir entre las dos codificaciones desde el principio es el tema del Comparación Base64 vs hex del sitio, que compara tamaño, legibilidad y compatibilidad con protocolos sin el folclore tribal.
Cómo funciona realmente la conversión
La regla de agrupación de Base64 hace todo el trabajo real, y vale la pena verla una vez, porque explica tanto la longitud como el relleno de todo lo que emite esta herramienta:
- Limpieza: se eliminan los prefijos 0x y 0X, se quita todo el espacio en blanco, y los caracteres restantes deben ser 0–9, a–f o A–F; cualquier otra cosa es un error con nombre y su posición.
- Pares: cada dos dígitos hexadecimales se convierten en un byte — 48 es el byte 0x48, la letra H.
- Agrupar: los bytes se toman de tres en tres; los 24 bits de cada triple se dividen en cuatro valores de 6 bits, y cada valor se mapea a un carácter del alfabeto RFC 4648 A–Z a–z 0–9 + /.
- Relleno: un grupo final de 1 o 2 bytes se completa con caracteres = para que la longitud de salida siempre sea múltiplo de 4.
La entrada se limpia, no se juzga
El hexadecimal en el mundo real llega con adornos. Los resúmenes de hash vienen con prefijo 0x de algunas bibliotecas; los volcados de paquetes llegan como columnas de pares espaciados; la documentación escribe 48 65 6C con mayúsculas mientras un registro imprimió 48656c en minúsculas. Todo eso son los mismos bytes, así que el conversor los trata igual: los prefijos y el espacio en blanco se van, deja de importar el caso, y solo después de limpiar el analista insiste en dígitos hexadecimales. El caso mixto dentro de una misma cadena — 6C junto a 6c — está bien, porque las dos formas escriben un valor de nibble.
Entrada de longitud impar: la política explícita
Una cadena hexadecimal de longitud impar no se puede analizar sin adivinar, porque falta un dígito y cualquier extremo es un lugar plausible para la pérdida. Anteponer un cero y añadir un cero producen bytes diferentes — 0x48 frente a 0x84 —, así que arreglar silenciosamente la entrada elegiría un significado al azar y te daría datos que parecen correctos. La política de este conversor es rechazar: una entrada de longitud impar devuelve un error con nombre que indica la longitud, y la corrección corresponde a quien sabe dónde realmente se perdió el dígito. Es la misma regla de rechazar en lugar de manipular que aplican el resto de conversores de este sitio.
Cómo es la salida
El ejemplo resuelto abajo es el par exacto que produce el botón Cargar ejemplo: una cadena hexadecimal adornada — prefijo 0x, espacios, caso mixto — que llega como cinco bytes que deletrean «Hello» y sale como Base64 estándar SGVsbG8=, con un = porque el grupo final lleva dos bytes en lugar de tres. La salida usa el alfabeto estándar, con más y barra incluidos, no la variante segura para URL; si tu destino altera esos dos caracteres, el alfabeto seguro para URL de RFC 4648 es la sustitución documentada que aplicar después.
Preguntas frecuentes
¿Al convertir de hex a Base64 se sube mi entrada a algún sitio?
No. El análisis y la codificación se ejecutan dentro de esta pestaña del navegador, en código que se envió con la página. La página no define ningún punto de subida, y su política de seguridad de contenido bloquea las conexiones salientes, por lo que la exfiltración es estructuralmente imposible, no solo prometida. DevTools hace la comprobable: abre el panel de Red, convierte una cadena y observa que no registra absolutamente nada.
¿Por qué se rechaza el hexadecimal de longitud impar en lugar de arreglarse?
Porque cada arreglo es una adivinanza con consecuencias reales. Un recuento impar de dígitos significa que falta un nibble, y rellenar con un cero al principio o al final da bytes diferentes — 48 frente a 84 —, así que un arreglo silencioso inventaría datos que parecen plausibles. El conversor devuelve un error con nombre que indica la longitud, y tú corriges la fuente donde realmente se perdió el dígito.
¿Se aceptan realmente letras mayúsculas, prefijos 0x y espacios?
Sí. El caso no importa — 4C y 4c son el mismo nibble — se eliminan los prefijos 0x y 0X aunque se repitan antes de cada byte, y todo el espacio en blanco se quita antes de analizar, así que una columna de volcado hexadecimal pegada se convierte sin limpiar primero. Después de limpiar, solo son válidos 0–9 y a–f o A–F; una g suelta o una coma son un error con nombre y su posición.
¿La salida siempre incluye el relleno =?
El relleno solo aparece cuando el recuento de bytes no es múltiplo de tres — un = para un resto de dos bytes, dos para un resto de un byte — y la longitud de salida siempre es múltiplo de 4. Los caracteres = son parte de RFC 4648, no ruido: quitarlos rompe decodificadores que confían en la longitud. Esta herramienta emite la forma estándar con relleno, coincidiendo con lo que producen los codificadores estándar.
¿Por qué la salida Base64 es más corta que la entrada hexadecimal?
Aritmética de sobrecarga de codificación: el hex gasta 2 caracteres por byte, Base64 gasta 4 por cada 3. Para los mismos bytes, hex funciona al 100% de sobrecarga y Base64 al 33%, así que un resumen de 64 bytes pasa de 128 dígitos hexadecimales a 88 caracteres Base64 incluyendo relleno. Los datos son idénticos en todo momento — solo cambió la eficiencia de empaquetado del alfabeto.
¿La codificación Base64 es una forma de cifrar datos?
No, y tratarla como tal es un error de seguridad genuino. Base64 es una codificación reversible sin clave: cualquiera que tenga la cadena puede decodificarla, offline, en milisegundos — esta página lo hace sin red. Existe para mover bytes por canales seguros para texto, no para protegerlos. Si la confidencialidad importa, cifra primero, luego aplica Base64 al texto cifrado para el transporte.
¿Qué herramientas relacionadas debería usar después?
- Base64 a hexadecimalConvertidor que funciona en tu navegadorAbrir
- Codificar y decodificar Base64Decodifica y codifica Base64 estándar y URL-safe, con descarga binariaAbrir
- Base64 vs hexadecimalComparativa directaAbrir
- Cómo funciona Base64Guía en lenguaje sencilloAbrir
- Herramientas de codificaciónBase64, codificación de URL, hashes e inspección de tokens.Abrir
- Codificar y decodificar URLCodifica y decodifica distinguiendo + de %20Abrir