Dos formas de escribir los mismos bytes
Los ordenadores manejan bytes. Los humanos no podemos leer bytes crudos (incluyen caracteres no imprimibles y otros que rompen URLs y JSON). Así que los codificamos: convertimos datos binarios en una cadena de caracteres seguros que pueden viajar por HTTP, JSON, email, terminales.
Base64 y hex son las dos codificaciones que de verdad te encuentras en producción. Hacen el mismo trabajo, solo usan alfabetos distintos. Elegir la correcta no es cuestión de gustos, cambia el tamaño de tu salida y los bugs que puedes pillar por el camino.
De un vistazo
| Característica | Hex (Base16) | Base64 |
|---|---|---|
| Tamaño vs binario | 2x más grande | Aproximadamente 1,33x más grande |
| Alfabeto | 0-9 a-f | A-Z a-z 0-9 + / = |
| Seguro en URLs | Sí, por defecto | No, requiere variante base64url |
| Uso típico | Hashes, huellas, direcciones | Tokens, imágenes en JSON, email |
| Cuándo gana cada uno | Legible, seguro en copy paste | Payloads más pequeños, blobs grandes |
Hex: simple, legible, el doble de largo
Hex (también llamado Base16) escribe cada byte como dos caracteres del alfabeto 0-9 a-f.
Un hash de 32 bytes como SHA-256 se vuelve 64 caracteres:
deadbeef e29b41d4 a716446655440000 ...Las matemáticas son fáciles: cada byte son dos caracteres, sin excepciones. Un blob de 1 KB se vuelve 2 KB de hex. Un archivo de 100 MB se vuelve 200 MB de cadena hex.
Hex es la elección correcta cuando:
- Quieres que humanos lean y comparen valores (hashes, huellas, direcciones).
- Necesitas estabilidad en copy paste (sin caracteres especiales que se mutilen).
- La penalización de tamaño no importa (payloads pequeños, transmisión poco frecuente).
Hex es la elección incorrecta cuando:
- Mueves grandes cantidades de datos (el 100 por cien de overhead es doloroso).
- Tienes un presupuesto ajustado de caracteres (Twitter, SMS, ciertos headers).
Base64: compacto, con padding, casi seguro en URLs
Base64 usa un alfabeto de 64 caracteres (A-Z a-z 0-9 + /) y codifica tres bytes como cuatro caracteres.
El mismo hash de 32 bytes se vuelve 44 caracteres:
3q2+78Lp...Aproximadamente un 33 por ciento de overhead, mucho mejor que el 100 por ciento de hex. La pega es el alfabeto. El + y la / son caracteres normales en base64 pero son reservados en URLs (+ se vuelve un espacio, / separa segmentos de ruta). Base64 estándar en un parámetro de URL es un bug esperando a pasar.
El arreglo es base64url, una variante que cambia + y / por - y _. Mismo tamaño, sin bugs de URL. JWT, tokens OAuth y la mayoría de APIs modernas usan base64url precisamente por esto.
El carácter de padding = al final a veces está, a veces no. Base64 estándar siempre tiene padding. Base64url a menudo lo omite. Algunos parsers se preocupan, otros no. Cuando recibes una cadena base64, prueba con y sin padding antes de declararla rota.
Cuándo elegir cada una
Hashes que muestras a humanos: hex. SHA-256 escrito en hex es reconocible entre lenguajes y herramientas. Los hashes en base64 parecen ruido.
Tokens que viajan en URLs: base64url. Compacto y seguro en URLs.
Firmas de JWT: base64url, no hay elección (la spec lo dice).
Blobs binarios en JSON: base64. JSON no permite bytes crudos, base64 mantiene el tamaño manejable.
Descargas de archivos con checksum: hex. El usuario quiere comparar el hash mostrado con el del archivo, carácter a carácter.
SMS que tienen que entrar en 160 caracteres: base64url. Hex doblaría el coste.
Cuando necesites convertir entre ellos o solo inspeccionar lo que tienes, el codificador Base64 de AldeaCode maneja las variantes estándar, URL safe, con padding y sin padding. El generador de hash saca en cualquier formato. Todo corre en tu navegador, sin subida.
Los bugs que muerden
Algunas cosas que vigilar:
Padding: una cadena base64 con un número incorrecto de = al final no decodifica. Si recibes una cadena y termina en ==, el codificador añadió dos caracteres de padding porque el input no era múltiplo de tres bytes. Quitar el padding está bien, modificarlo no.
Espacios: algunos codificadores insertan saltos de línea cada 76 caracteres (herencia del email). La mayoría de decodificadores los ignoran, algunos no. Si tu cadena no decodifica, quita los espacios primero.
Alfabetos mezclados: si una cadena tiene tanto + (base64 estándar) como - (base64url), está corrupta. Los dos alfabetos no se mezclan. Elige uno y mantente.
Mayúsculas en hex: hex es insensible a mayúsculas en la mayoría de parsers pero por convención se escribe en minúscula. Algunos sistemas insisten en minúscula, otros en mayúscula. Si dudas, minúscula.
El salto de línea final: pegar un hash desde un terminal a menudo incluye un \n final. La mayoría de decodificadores lo quitan, algunos no. Si tus comparaciones de hash fallan, busca saltos de línea invisibles.
Una referencia rápida
// Hex
const buf = new Uint8Array([0xde, 0xad, 0xbe, 0xef]);
const hex = [...buf].map(b => b.toString(16).padStart(2, "0")).join("");
// "deadbeef"
// Base64 estándar
const b64 = btoa(String.fromCharCode(...buf));
// "3q2+7w=="
// Base64url sin padding
const b64url = b64.replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");
// "3q2-7w"Para la inversa, atob() decodifica base64 estándar en el navegador. Para base64url, intercambia los caracteres de vuelta antes de llamar a atob().
El codificador Base64, el generador de hash y el codificador URL de AldeaCode corren en tu navegador, sin subida, sin log. Dos reglas acaban con la mayoría de bugs de codificación: elige base64url para cualquier cosa cercana a una URL, elige hex para cualquier cosa que vayan a leer humanos.