Base64 vs Hex: El intercambio fundamental
La elección entre base64 vs hex se reduce a una pregunta: ¿necesitas compacidad o legibilidad? La codificación hex convierte cada byte en dos caracteres hexadecimales (00-FF), produciendo una salida que es exactamente 2× el tamaño de la entrada. Base64 convierte cada 3 bytes en 4 caracteres, produciendo una salida que es 1.33× el tamaño de la entrada. Para un archivo de 1 MB: hex te da 2 MB, Base64 te da 1.33 MB. Base64 gana en tamaño; hex gana en simplicidad.
Hex es más fácil de leer y depurar. Cada byte se mapea a exactamente dos caracteres, así que puedes parsear visualmente los datos byte por byte. El string hex "48656c6c6f" son claramente 5 bytes, y puedes buscar cada par en una tabla ASCII (48=H, 65=e, 6c=l, 6c=l, 6f=o). El "SGVsbG8=" de Base64 es más compacto pero no puedes ver bytes individuales a simple vista — la agrupación de 6 bits cruza los límites de bytes.
Ambos son codificaciones seguras para texto — convierten datos binarios arbitrarios en caracteres ASCII imprimibles. La diferencia es el conjunto de caracteres: hex usa 16 caracteres (0-9, a-f), Base64 usa 64 caracteres (A-Z, a-z, 0-9, +, /). Más caracteres por símbolo significa más información por carácter, que es por qué Base64 es más compacto. Es el mismo principio por el que los números en base 10 son más cortos que los números binarios.
Cuándo usar codificación Hex
Salidas de hash: SHA-256 produce 32 bytes. Como hex, son 64 caracteres: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855". Cada herramienta de hash, cada documentación, cada API usa hex para valores de hash. Es la convención universal. Nuestra herramienta hash-generator produce hex por defecto porque es lo que los desarrolladores esperan ver y comparar.
Depuración de protocolos binarios: Cuando estás viendo paquetes de red, encabezados de archivo o volcados de memoria, hex es la representación estándar. Wireshark muestra hex. Los editores hex muestran hex. Los primeros bytes de un archivo PNG son "89504e47" — puedes memorizar estos números mágicos. En Base64, los mismos bytes serían "iVBORw==" que es menos reconocible y más difícil de buscar en documentación.
Códigos de color: Los colores CSS (#FF6B35), direcciones MAC (00:1A:2B:3C:4D:5E) y UUIDs (550e8400-e29b-41d4-a716-446655440000) todos usan hex porque cada componente se mapea limpiamente a bytes. Un color son 3 bytes (RGB), una dirección MAC son 6 bytes, un UUID son 16 bytes. Hex preserva esta estructura a nivel de byte visualmente.
Valores binarios pequeños: Para datos menores a ~100 bytes (claves criptográficas, identificadores binarios cortos, encabezados de protocolo), el overhead de 2× de hex es aceptable y la ventaja de legibilidad lo vale. Para una clave de cifrado de 32 bytes, hex te da 64 caracteres vs los 44 de Base64. La diferencia de 20 caracteres rara vez importa, pero poder verificar visualmente "sí, son 32 bytes" contando 64 caracteres hex es útil durante el desarrollo.
Cuándo usar codificación Base64
Adjuntos de email (MIME): El caso de uso original. SMTP es ASCII de 7 bits, así que los adjuntos binarios deben codificarse como texto. El overhead del 33% de Base64 supera significativamente el 100% de hex para archivos de varios megabytes. Cada adjunto de email que has enviado usa Base64. El estándar MIME (RFC 2045) especifica Base64 con saltos de línea cada 76 caracteres.
Incrustar binario en JSON/XML: Cuando una API necesita incluir una imagen, archivo o blob binario en un formato basado en texto, Base64 es el estándar. Las políticas de POST presignado de AWS S3 usan JSON codificado en Base64. Los JWTs codifican su payload como Base64url. Los Data URIs en HTML (data:image/png;base64,...) incrustan imágenes directamente en el markup. El overhead del 33% es el costo de la seguridad de texto.
Datos binarios grandes en contextos de texto: Para cualquier cosa mayor a unos cientos de bytes donde el tamaño importa, Base64 gana. Una imagen de 100 KB como hex son 200 KB; como Base64 son 133 KB. A través de una conexión de red, esa diferencia de 67 KB se acumula. Nuestra herramienta base64-encoder maneja archivos hasta 50 MB y muestra el tamaño codificado para que puedas evaluar el overhead.
Tokens de autenticación y cookies: Los tokens OAuth, IDs de sesión y claves de API frecuentemente usan codificación Base64 o Base64url. La representación compacta cabe mejor en encabezados HTTP (que tienen límites prácticos de tamaño alrededor de 8 KB) y cookies (límite de 4 KB por cookie). Base64url (usando - y _ en vez de + y /) está diseñado específicamente para contextos seguros en URL sin codificación porcentual adicional.
URL Encoding: El caso especial
URL encoding (codificación porcentual) no es realmente una codificación binario-a-texto — es una codificación texto-a-texto que hace strings seguros para URLs. Cada byte inseguro se convierte en %XX (signo de porcentaje + dos dígitos hex). Un espacio se convierte en %20, un ampersand en %26, un carácter chino (3 bytes UTF-8) en %E4%B8%AD. El overhead varía enormemente: las letras ASCII tienen 0% de overhead, pero un string de puros caracteres especiales triplica su tamaño.
URL encoding es específico del contexto. En un path de URL, / es estructural (no lo codifiques). En un valor de parámetro de query, / es dato (codifícalo). En un fragmento, casi nada necesita codificación. Esta dependencia del contexto hace que URL encoding sea fundamentalmente diferente de Base64 o hex, que codifican todo uniformemente sin importar el contexto. Ve nuestra herramienta url-encoder para codificación interactiva con selección de contexto.
Cuando URL encoding se encuentra con Base64: si necesitas poner datos Base64 en una URL, los caracteres + y / del Base64 estándar necesitan codificación porcentual (%2B y %2F). Por eso existe Base64url — reemplaza + con - y / con _ para evitar esta doble codificación. Los JWTs usan Base64url específicamente porque aparecen en URLs y encabezados HTTP. Siempre usa Base64url (no Base64 estándar) para datos que viajarán en URLs.
Comparación de tamaño para un caso de uso típico: codificar el string binario "Hello, World! 你好" (19 bytes UTF-8). Hex: 38 caracteres. Base64: 28 caracteres. URL-encoding: "Hello%2C%20World%21%20%E4%BD%A0%E5%A5%BD" = 41 caracteres. URL encoding es el peor para datos binarios porque codifica cada byte como 3 caracteres (%XX) mientras deja las letras ASCII sin codificar — el overhead depende completamente del contenido de entrada.
Binario crudo: Cuando la codificación de texto está mal
A veces la respuesta es "no codifiques nada." Si tanto el emisor como el receptor pueden manejar datos binarios, la codificación de texto agrega overhead y tiempo de procesamiento innecesarios. Las respuestas HTTP con Content-Type: application/octet-stream envían bytes crudos. Los frames binarios de WebSocket envían bytes crudos. Las subidas de archivos con multipart/form-data envían bytes crudos. Protocol Buffers y MessagePack son formatos de serialización binaria que son más pequeños y rápidos que JSON+Base64.
La regla: usa codificación de texto (Base64, hex) solo cuando el canal de transporte requiere texto. Email (SMTP) requiere texto → usa Base64. Payloads JSON requieren texto → usa Base64 para campos binarios. Parámetros de URL requieren texto → usa URL-encoding o Base64url. Pero cuerpos HTTP, mensajes WebSocket, llamadas gRPC y I/O de archivos todos soportan binario nativamente — codificar datos binarios para estos canales desperdicia ancho de banda y CPU.
Comparación de rendimiento: codificar 1 MB de datos binarios. Codificación Base64 toma ~2ms y produce 1.33 MB. Codificación hex toma ~3ms y produce 2 MB. Enviar binario crudo toma 0ms de tiempo de codificación y produce 1 MB. Para una API REST que devuelve una imagen de 5 MB, codificarla en Base64 dentro de JSON cuesta 6.67 MB de transferencia + tiempo de CPU de codificación/decodificación. Servirla como una respuesta binaria separada cuesta 5 MB de transferencia + cero overhead de codificación. La elección es obvia para payloads grandes.
Enfoque híbrido: usa JSON para metadatos y binario para payloads. Un patrón común: la API devuelve JSON con una URL apuntando al recurso binario, que el cliente obtiene por separado. Esto te da metadatos estructurados (título, tamaño, content-type) en un formato amigable con texto más transferencia binaria eficiente para los datos reales. Cada CDN, servicio de almacenamiento de objetos y plataforma de medios usa este patrón.
Tabla comparativa y guía de decisión
Overhead de tamaño: Binario crudo = 0%. Base64 = 33%. Hex = 100%. URL-encoding = 0-200% (depende del contenido). Para aplicaciones sensibles al tamaño (APIs móviles, sistemas embebidos, servicios de alto throughput), minimiza el overhead de codificación usando transporte binario cuando sea posible y Base64 cuando se requiera codificación de texto.
Legibilidad: Hex es lo más legible para desarrolladores (alineado a bytes, familiar de herramientas de depuración). Base64 es compacto pero opaco (no puedes parsear visualmente bytes individuales). URL-encoding es legible para texto ASCII pero feo para binario. Binario crudo es ilegible sin un visor hex. Elige basándote en si los humanos necesitan inspeccionar los datos durante desarrollo y depuración.
Compatibilidad: URL-encoding funciona en URLs (por definición). Base64 funciona en JSON, XML, email y la mayoría de contextos de texto. Hex funciona en cualquier lugar donde funcione texto pero rara vez es la elección estándar para datos grandes. Binario crudo funciona en cuerpos HTTP, WebSocket, archivos y protocolos binarios pero no en JSON o URLs. Haz coincidir la codificación con los requisitos de tu canal de transporte.
Mi árbol de decisión: ¿El transporte es capaz de binario? → Usa binario crudo. ¿Es una URL? → Usa URL-encoding para valores de texto, Base64url para valores binarios. ¿Es JSON/XML? → Usa Base64 para campos binarios. ¿Es para depuración/visualización? → Usa hex. ¿Es un hash o valor criptográfico? → Usa hex (convención). ¿Es un adjunto de email? → Usa Base64 (estándar MIME). En caso de duda, Base64 es el default más seguro para escenarios de binario-en-texto.
Encoding comparison for 16 bytes of binary data (a UUID):
Raw binary: 16 bytes (not displayable as text)
Hex: "550e8400e29b41d4a716446655440000" (32 chars)
Base64: "VQ6EAOKbQdSnFkRmVUQAAA==" (24 chars)
Base64url: "VQ6EAOKbQdSnFkRmVUQAAA" (22 chars, no padding)
Encoding comparison for 1 KB of binary data:
Raw binary: 1,024 bytes
Hex: 2,048 characters (+100%)
Base64: 1,368 characters (+33%)
URL-encoded: ~3,072 characters (+200%, worst case)
Speed (encoding 10 MB, Node.js on M1 Mac):
Buffer.toString('hex'): ~8ms
Buffer.toString('base64'): ~5ms
No encoding (raw): ~0msErrores comunes al elegir formatos de codificación
Error 1: Codificar en Base64 datos que ya son texto. Si tienes un string JSON y lo codificas en Base64 antes de ponerlo en otro campo JSON, has agregado 33% de overhead sin beneficio. JSON puede contener JSON (como un string escapado u objeto anidado). Solo codifica en Base64 datos binarios reales (imágenes, archivos, material criptográfico). Los datos de texto deberían quedarse como texto.
Error 2: Usar hex para payloads binarios grandes. Un archivo de 10 MB como hex son 20 MB — eso es 10 MB de desperdicio puro comparado con Base64 (13.3 MB) o binario crudo (10 MB). Hex es para visualización y depuración, no para transferencia de datos. Si estás enviando archivos codificados en hex a través de una API, cambia a Base64 o binario y ahorra 33-50% de ancho de banda inmediatamente.
Error 3: Mezclar formatos de codificación en el mismo sistema. He visto APIs que devuelven algunos campos binarios como hex y otros como Base64, sin documentación sobre cuál es cuál. Elige un formato para todos los datos binarios en tu API y documéntalo claramente. La consistencia previene bugs donde un consumidor decodifica hex como Base64 (o viceversa) y obtiene basura.
Error 4: No considerar el costo de decodificación. Codificar y decodificar no son gratis — consumen CPU y memoria. Para un servicio de alto throughput procesando millones de requests, el costo acumulativo de codificación/decodificación Base64 puede ser significativo. Si estás codificando datos solo para ponerlos en JSON y luego inmediatamente decodificándolos del otro lado, considera si un protocolo binario (gRPC, MessagePack, Protocol Buffers) eliminaría este overhead por completo.