Base64 frente a hexadecimal

El hexadecimal («hex») expande cada nibble (4 bits) en uno de dieciséis símbolos ASCII 0–9A–F. Base64 empaqueta más bits por carácter de salida — seis en lugar de cuatro — así que los payloads son más cortos en número de caracteres, aunque no siempre en tamaño de bytes tras capas de compresión.

Factores de expansión (intuición)

Codificación	Bits por símbolo de salida	Tamaño del alfabeto
Hex	4	16
Base64	6	64

Ignorando el encuadre, Base64 suele usar ~4 caracteres tipados por 3 bytes crudos. Hex gasta 2 caracteres tipados por byte. Ese ~33 % de overhead de Base64 suena mal hasta que hex duplica la longitud visible sin condiciones.

Sensación concreta: dieciséis bytes crudos ⇒ treinta y dos dígitos hex frente a unos veintidós caracteres Base64 (depende de alineación y padding final).

Cuándo brilla hex

Prefiere hex cuando:

• Los humanos deben comparar a ojo huellas (hashes a menudo en hex)
• Solo emites charset estrecho apto para impresión pero quieres mapeo trivial («cada par de hex = un byte»)
• Depuras scripts rápidos donde Base64 añade carga mental de padding
• Restricciones exigen orden lexicográfico insensible a mayúsculas uniforme (a veces hex en mayúsculas estandariza comparaciones)

Hashes en Git, digests SHA-256 en páginas de descarga — el dominio de hex es ergonomía, no necesidad criptográfica.

Cuándo brilla Base64

Prefiere Base64 cuando:

• Debes incrustar binario en sobres de texto MIME / JSON históricos con rapidez
• El canal prohíbe ambigüedad de parsers insensibles a saltos de línea con anchos raros (sigue cuidando el wrapping)
• Quieres menos caracteres delimitadores frente a blobs hex largos en logs (la legibilidad subjetiva varía)
• El ecosistema de librerías ya estandarizó envoltorios Base64 (JWT, bloques internos PEM)

Ningún formato comprime entropía; elegir es ergonomía de transporte.

Pipelines mixtos

Patrón peligroso: SHA-256 mostrado en hex en UI → el desarrollador codifica en Base64 la cadena ASCII hex, no los bytes crudos del digest → infierno de checksums que no coinciden. Mantén claridad: objeto digest vs representación imprimible vs capas de codificación en wire.

Igualmente, aplicar dos veces (hex luego Base64) rara vez ayuda: cada capa expande o transforma sin añadir seguridad salvo pasos de protocolo deliberados.

Confusión de ejemplo (conceptual)

digest_bytes   = salida criptográfica (32 bytes opacos típicos en SHA-256)
hex_string     = vista humana de digest_bytes ('a3f...')
base64_digest  = otra vista de LOS MISMOS bytes (alfabeto distinto)

Convertir formatos debe desembalar a octetos idénticos.

Nota de rendimiento

El coste computacional es negligible en tamaños típicos (< pocos MB) en CPUs modernas. La elección de serialización debe seguir interoperabilidad + claridad, no micro-benchmarks.

Idea clave

Hex es maravillosamente regular (2 chars / byte); Base64 es más denso entre pilas ASCII imprimibles. Codifica los bytes crudos que prevé tu protocolo — no un intermedio textual accidental — y documenta qué forma canónica esperan los validadores.