Generador de Hash MD5, SHA-1, SHA-256 y SHA-512 Online: Calcular y Verificar Integridad de Textos con Codificador Base64 para Desarrolladores en México, Colombia y América Latina
Genera hashes MD5, SHA-1, SHA-256 y SHA-512 de cualquier texto directamente en tu navegador sin enviar datos a ningún servidor. Verifica la integridad de textos comparando hashes. Codifica y decodifica Base64 con soporte UTF-8 para español (tildes, ñ). Todo el procesamiento ocurre localmente en tu dispositivo.
Base64 codifica texto u datos binarios en caracteres ASCII seguros. No es cifrado: cualquiera puede decodificar Base64 fácilmente.
Ingresa el texto y presiona Generar para calcular los hashes MD5, SHA-1, SHA-256 y SHA-512
Hashing criptográfico para desarrolladores latinoamericanos: la diferencia entre hash, cifrado y codificación, por qué MD5 y SHA-1 ya no son seguros para criptografía en 2025, y cómo SHA-256 se convierte en el estándar mínimo recomendado por OWASP para firmas digitales, integridad de archivos y tokens en México, Colombia y Argentina
Uno de los errores conceptuales más comunes en el desarrollo de software en América Latina es usar los términos “encriptar” y “hashear” como sinónimos. Son procesos fundamentalmente diferentes. El cifrado (encriptación) es un proceso reversible: los datos cifrados con AES o RSA pueden descifrarse con la clave correcta. El hashing es irreversible: no existe ninguna clave ni proceso que permita obtener el texto original a partir de su hash. Esta distincción tiene consecuencias prácticas enormes. Si un desarrollador de una empresa en Ciudad de México o Bogotá “encripta” las contraseñas de sus usuarios con MD5 (creyendo que son equivalentes), está en realidad hasheandolas sin salt. Cuando alguien roba la base de datos, los hashes MD5 sin salt son descifrábles en segundos con rainbow tables disponibles gratuitamente en internet. La guía de almacenamiento de contraseñas de OWASP es la referencia estándar para desarrolladores en LatAm y en todo el mundo.
Por qué MD5 está roto como algoritmo de seguridad pero sigue siendo útil como checksum: la diferencia entre una colisión criptográfica (dos archivos diferentes con el mismo hash MD5, demostrada en 2004 por Wang y Yu con 2^39 operaciones) y un checksum de integridad donde el adversario no puede manipular el archivo
MD5 fue diseñado por Ron Rivest en 1991 y durante 13 años se consideró seguro. En 2004, Xiaoyun Wang y Hongbo Yu demostraron que era posible encontrar colisiones en MD5 con 2^39 operaciones, y en 2009 se demostró la creación de un certificado SSL malicioso usando colisiones MD5. Esto significó el fin de MD5 para aplicaciones de seguridad. Sin embargo, MD5 sigue siendo ampliamente usado y perfectamente válido para verificaciones de integridad no-adversariales: comprobar que un archivo descargado no se corrompió durante la transferencia (donde no hay adversario intentando manipular activamente el hash), generar identificadores únicos de caché internos, checksums rápidos de archivos de configuración. La clave es: MD5 es inseguro cuando existe un adversario que puede manipular activamente los datos. Es aún válido cuando el único riesgo es corrupción accidental (error de transmisión, fallo de disco).
SHA-256 en la infraestructura digital de América Latina: cómo los certificados SSL/TLS de todos los sitios HTTPS de México, Colombia y Argentina usan SHA-256 para la firma de certificados, cómo Bitcoin usa SHA-256 en su mecanismo de prueba de trabajo, y por qué la migración de SHA-1 a SHA-256 fue una de las mayores operaciones de seguridad en la historia de internet
En 2017, Google anunció el proyecto SHAttered: la primera colisión práctica de SHA-1, donde dos archivos PDF completamente diferentes tenían exactamente el mismo hash SHA-1. Esto requirió 9,223,372,036,854,775,808 (9 quintillones) operaciones de SHA-1 y costó aproximadamente 110,000 USD en recursos de computación en la nube. Esta demostración aceleró la deprecación definitiva de SHA-1 en certificados SSL. Todos los certificados SSL/TLS modernos (los que hacen posible el HTTPS en sitios mexicanos, colombianos y argentinos) usan SHA-256 para su firma digital. El SAT de México, la DIAN de Colombia, la AFIP de Argentina y todos los organismos de facturación electrónica de la región requieren SHA-256 en sus implementaciones. Bitcoin, cuya popularidad en América Latina ha crecido exponencialmente desde 2020, usa SHA-256 como núcleo de su mecanismo de prueba de trabajo (Proof of Work) y en la derivación de direcciones.
¿Cómo funciona este generador de hash MD5, SHA-256 y Base64?
Tres módulos para calcular, verificar y codificar en el navegador sin enviar datos a servidores externos.
Modo 1: Generador de Hash
Ingresa cualquier texto y presiona Generar. La herramienta calcula simultáneamente: MD5 (implementación JavaScript pura, 32 chars hex), SHA-1 (Web Crypto API nativa del navegador, 40 chars hex), SHA-256 (Web Crypto API, 64 chars hex), SHA-512 (Web Crypto API, 128 chars hex). Cada hash tiene su botón de copiar individual. El gráfico de barras compara la longitud en caracteres de cada algoritmo. Se muestra la advertencia de seguridad sobre MD5 y SHA-1 para aplicaciones de seguridad.
Modo 2: Verificador de Integridad
Ingresa el texto a verificar, selecciona el algoritmo (MD5/SHA-1/SHA-256/SHA-512), pega el hash esperado (por ejemplo, el publicado en el sitio oficial de un software). La herramienta calcula el hash del texto y lo compara con el esperado. Muestra “HASH COINCIDE” (verde) o “HASH NO COINCIDE” (rojo) con explicación de posibles causas. El gráfico donut muestra la proporción de caracteres coincidentes vs diferentes.
Modo 3: Codificador/Decodificador Base64
Ingresa texto y presiona “Codificar a Base64” para obtener la representación Base64. O pega un texto Base64 y presiona “Decodificar de Base64” para obtener el texto original. Soporte completo UTF-8 para caracteres del español (tildes, ñ). Muestra estadísticas de expansión (el texto en Base64 es ~33% más largo) y la representación hexadecimal del texto original.
3 Ejemplos Reales de Uso de Hashing en Proyectos de Software en México, Colombia y Argentina
Cómo equipos de desarrollo, auditores de seguridad y arquitectos de software de América Latina aplican MD5, SHA-256 y Base64 en proyectos reales de facturación electrónica, APIs REST y sistemas de integración
Empresa de software de facturación en CDMX que usa SHA-256 y Base64 para generar el sello digital de CFDIs: cómo el flujo de firmado criptográfico del SAT combina hashing y codificación para la integridad legal de las facturas electrónicas mexicanas
El equipo de desarrollo de una empresa de facturación en Ciudad de México trabaja con CFDIs (Comprobantes Fiscales Digitales por Internet). El proceso de sellado digital del SAT combina SHA-256 y Base64: primero se genera la cadena original del CFDI (una representación del documento en formato específico). Luego se calcula el SHA-256 de esa cadena. Ese hash se firma con la llave privada del contribuyente (cifrado asimétrico RSA o ECDSA). La firma resultante se codifica en Base64. Ese Base64 es el “Sello Digital” que aparece en la factura. Si alguien modifica cualquier dato de la factura (monto, RFC, concepto), la cadena original cambia, el SHA-256 cambia, y el sello digital ya no coincide. El SAT valida la integridad de cada CFDI verificando que el sello corresponda a la cadena original. Esta herramienta permite verificar y entender cada paso del proceso en contexto educativo.
CFDI: cadena original → SHA-256 → firma RSA → Base64 = Sello Digital | Modificar cualquier dato invalida el sello | SAT verifica integridad en tiempo realStartup fintech en Bogotá que implementa HMAC-SHA256 para autenticar las llamadas a su API de pagos: cómo el hashing con clave secreta previene que terceros falsifiquen peticiones de pago y cómo depuraron un error de encoding que causaba que los hashes no coincidieran
El equipo de Daniel en Bogotá construye una API de pagos. Para autenticar las peticiones usan HMAC-SHA256 (Hash-based Message Authentication Code): el cliente genera un hash SHA-256 del cuerpo de la petición JSON + timestamp + clave secreta compartida. El hash resultante (en Base64) se envía como header HTTP. El servidor recalcula el hash con la misma clave secreta y verifica que coincida. Si alguien intercepta la petición y modifica el monto del pago, el hash ya no coincide y el servidor rechaza la petición. Problema que encontraron: los hashes del cliente (Python) y el servidor (Node.js) no coincidían para montos con decimales (100.50 COP). Causa: Python serializaba el JSON con espacio tras la coma ({“monto”: 100.50}) y Node.js sin espacio ({“monto”:100.50}). SHA-256 del mismo dato pero con formato diferente produce hashes completamente distintos. Solución: estandarizar la serialización JSON en ambos lados. Este tipo de error de encoding se detecta fácilmente con el Verificador de esta herramienta.
HMAC-SHA256 en API de pagos | Bug: espacio en JSON → hash diferente | {monto: 100.50} vs {monto:100.50} | SHA-256 detecta diferencia de 1 char | Solución: JSON.stringify() estándarAuditor de seguridad en Buenos Aires que descubrió que una aplicación de RR.HH. almacenaba contraseñas en MD5 sin salt: cómo el análisis de los hashes almacenados confirmó el problema y cómo se planteó la migración a bcrypt sin afectar a los usuarios
Matias realizó una auditoría de seguridad para una empresa de 500 empleados en Buenos Aires. Al revisar la base de datos de la aplicación de RR.HH., encontró la columna de contraseñas con valores como “5f4dcc3b5aa765d61d8327deb882cf99”. Usando el Generador de esta herramienta, calculó el MD5 de “password” (la contraseña más común): resultó en “5f4dcc3b5aa765d61d8327deb882cf99”. ¡Coincidencia exacta! Confirmó que el sistema usaba MD5 sin salt. El 34% de los empleados tenía esa contraseña. El plan de migración sin afectar usuarios: al próximo login, verificar la contraseña contra el hash MD5 antiguo (para compatibilidad temporal), si coincide, generar el hash bcrypt y reemplazar en la base de datos, marcar el usuario como “migrado”. Después de 90 días, los usuarios no migrados reciben un email para restablecer su contraseña. Esta migración progresiva garantizó que ningún usuario perdiera acceso durante el proceso.
MD5 sin salt en BD | md5(‘password’) = 5f4dcc… | 34% de usuarios con contraseña obvia | Migración progresiva a bcrypt en login | 90 días sin afectar usuariosAdministrador de sistemas en Santiago que usa SHA-256 para verificar que los instaladores de software descargados para 200 computadoras corporativas son auténticos: cómo el proceso de verificación previene instalar software comprometido en la infraestructura empresarial
Carlos gestiona la infraestructura IT de una empresa con 200 computadoras en Santiago. Antes de distribuir cualquier instalador de software (Java, Chrome Enterprise, Adobe Reader), verifica la integridad. Para el instalador de Node.js v20.11.0 para Windows: la página oficial de Node.js publica el hash SHA-256 de cada instalador. Carlos descarga el instalador (node-v20.11.0-x64.msi, 29.7 MB) en un servidor centralizado. Usa el hash SHA-256 publicado en nodejs.org. Para verificar el contenido del instalador como texto (el hash del archivo binario se verifica con sha256sum en terminal). Usó el Verificador de esta herramienta para entender el proceso conceptualmente y para verificar scripts de configuración y archivos de texto de configuración que distribuye en los equipos. El proceso de verificación de integridad preventó dos incidentes donde instaladores descargados de mirrors no oficiales tenían hashes diferentes al oficial.
200 PCs: verificar SHA-256 de instaladores antes de distribuir | 2 incidentes prevenidos: mirrors no oficiales con hashes diferentes | Política: solo instalar si hash coincide con nodejs.org/python.org/etc.Desarrollador backend en Lima que usa Base64 para entender y depurar tokens JWT en su API de una app de delivery: cómo el codificador Base64 permite inspeccionar el payload del token sin necesidad de herramientas externas
Carlos desarrolla la API backend de una app de delivery en Lima. Usa JWT (JSON Web Tokens) para autenticación. Un JWT tiene 3 partes separadas por puntos, cada una en Base64: header.payload.signature. Ejemplo: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMzQ1fQ.abc123. Cuando el equipo de iOS reporta un error de autenticación, Carlos usa el Decodificador Base64 de esta herramienta para inspeccionar el payload del token: pega eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 y decodifica a {“alg”:”HS256”,”typ”:”JWT”}. Pega la segunda parte eyJ1c2VySWQiOjEyMzQ1fQ y decodifica a {“userId”:12345}. Descubre que el token no incluye la fecha de expiración (campo “exp”), lo que causaba que el middleware de validación rechazara el token. El Codificador Base64 de esta herramienta se usa como herramienta de diagnóstico rápido sin necesidad de instalar jwt.io ni herramientas adicionales.
JWT debugging: Base64 decode del header y payload | Falta campo ‘exp’ en token → middleware rechaza | Herramienta: decodificar sin jwt.io ni dependencias | Diagnóstico en 60 segundosDesarrollador de e-commerce en Monterrey que usa MD5 del email para integrar avatares de Gravatar en la plataforma de clientes: cómo el u00fanico uso moderno de MD5 en producción donde sigue siendo el estándar requerido por la API del servicio
El equipo de Gabriel en Monterrey integra Gravatar (el servicio global de avatares de usuario) en su plataforma de e-commerce. El sistema de Gravatar requiere el MD5 del email del usuario (en minúsculas) para mostrar su avatar: https://www.gravatar.com/avatar/[MD5-del-email]. Para el usuario con email “carlos@empresa.com.mx”: calculan el MD5 del string “carlos@empresa.com.mx” con el Generador de esta herramienta. El MD5 resultante (32 caracteres hex) es el identificador único del perfil de Gravatar. Este es uno de los pocos casos donde MD5 sigue siendo la tecnología requerida en 2025 (Gravatar no ha migrado a SHA-256 por compatibilidad con millones de integraciones existentes). En este contexto de uso, la debilidad criptogrógica de MD5 no es relevante: no se está usando para seguridad sino como identificador único no-adversarial para un servicio de avatares públicos.
Gravatar: md5(‘carlos@empresa.com.mx’) = URL del avatar | Único caso de MD5 en producción en 2025 | No es para seguridad: es un identificador público de avatar3 Consejos de Expertos en Criptografía para Desarrolladores de América Latina
Lo que los arquitectos de seguridad y desarrolladores backend de México, Colombia y Argentina aplican en sus proyectos para usar correctamente los algoritmos de hashing en 2025
Nunca uses SHA-256 directamente para almacenar contraseñas de usuarios: aunque SHA-256 es criptográficamente fuerte, es demasiado rápido para este uso específico; una GPU moderna puede calcular 3,000 millones de SHA-256 por segundo, haciendo viable un ataque de fuerza bruta; usa bcrypt (costo 12+), Argon2id o scrypt que son intencionalmente lentos
La paradoja del hashing de contraseñas: la virtud de SHA-256 (ser extremadamente rápido y eficiente) es exactamente su defecto para almacenar contraseñas. Un atacante con una GPU NVIDIA RTX 4090 puede calcular aproximadamente 3 mil millones de hashes SHA-256 por segundo. Una contraseña de 8 caracteres (letras minúsculas) tiene 26^8 = 208 mil millones de combinaciones posibles. Ese espacio de búsqueda se agota en menos de 70 segundos. bcrypt con factor de costo 12 es 100,000 veces más lento que SHA-256: la misma GPU puede calcular solo ~30,000 bcrypt por segundo. Eso convierte las 70 segundos en 80 días. En PHP: password_hash($password, PASSWORD_BCRYPT, [‘cost’ => 12]). En Node.js: bcrypt.hash(password, 12). En Python: bcrypt.hashpw(password, bcrypt.gensalt(rounds=12)). Para nuevas aplicaciones en LatAm en 2025: Argon2id con los parámetros recomendados por OWASP es la primera elección.
Usa SHA-256 (no MD5 ni SHA-1) para todos los checksums de integridad que publiques: aunque MD5 puede ser aceptable para verificar integridad en contextos sin adversario, publicar checksums MD5 es una mala práctica de comunicación de seguridad que da señales incorrectas a los usuarios sobre el nivel de protección
Si eres desarrollador de software en México, Colombia o Argentina y distribuyes instaladores o archivos de configuración, publica siempre checksums SHA-256 (no MD5). Aunque en el contexto de una descarga oficial donde tú controlas el servidor y no hay adversario activo, MD5 podría ser técnicamente suficiente para detectar corrupción accidental, publicar MD5 envía una señal incorrecta al mercado: indica que el desarrollador no está al tanto de las mejores prácticas actuales de seguridad. Publicar SHA-256 o SHA-512 no tiene ningún costo adicional y comunica que el equipo sigue las estándares actuales. En GitHub: las releases de GitHub calculan SHA-256 automáticamente. En tus propios servidores: sha256sum archivo > archivo.sha256 en Linux/Mac. CertUtil -hashfile archivo SHA256 en Windows.
Recuerda que Base64 no es cifrado y nunca debe usarse como mecanismo de seguridad: muchos sistemas en América Latina “ocultan” datos sensibles en Base64 pensando que están protegidos; cualquier persona puede decodificar Base64 en segundos usando esta herramienta o cualquier otro decodificador en línea
En auditorías de seguridad de aplicaciones en México y Colombia es sorprendentemente común encontrar “protección” de datos sensibles usando Base64. Ejemplos reales: tokens de API guardados en cookies como Base64 sin cifrado adicional, datos de tarjetas de crédito “ofuscados” en Base64 en la URL, contraseñas de configuración en archivos .env como Base64 “para que no se vean a simple vista”. Ninguno de estos enfoques aporta seguridad real. Decodificar Base64 es trivial: esta misma herramienta lo hace en un segundo. Para proteger datos realmente sensibles: ciframiento simétrico (AES-256-GCM) para datos en reposo, TLS/HTTPS para datos en tránsito, HSM (Hardware Security Module) o KMS (Key Management Service) para claves criptográficas. Base64 tiene muchos usos legítimos (JWT, emails MIME, data URLs), pero la seguridad no está entre ellos.
16 Preguntas Frecuentes sobre Hash MD5, SHA-256 y Base64
Criptografía, integridad de archivos y codificación para desarrolladores en México, Colombia, Argentina, Chile y toda América Latina
¿Qué es un hash criptográfico?
Algoritmo que transforma datos en una cadena de longitud fija, irreversible. Propiedades: determinismo (mismo input = mismo hash), efecto avalancha (cambiar 1 char cambia todo el hash), uni-direccionalidad (imposible obtener el original desde el hash), resistencia a colisiones.
¿Cuál es la diferencia entre MD5, SHA-1, SHA-256 y SHA-512?
MD5 (128 bits, 32 chars hex): roto criptográficamente desde 2004. SHA-1 (160 bits, 40 chars): primera colisión demostrada en 2017. SHA-256 (256 bits, 64 chars): seguro, estándar actual recomendado. SHA-512 (512 bits, 128 chars): mayor seguridad por tamaño.
¿Por qué no usar MD5 para contraseñas?
MD5 es demasiado rápido: una GPU moderna calcula 3,000 millones de hashes MD5/segundo, haciendo viable la fuerza bruta. Existen rainbow tables de contraseñas comunes en MD5. Usa bcrypt (factor 12+) o Argon2id para contraseñas, nunca SHA directo.
¿Los datos introducidos se envían a algún servidor?
No. Todo procesa en tu navegador usando JavaScript local y la Web Crypto API nativa. Ningún dato sale de tu dispositivo. Puedes desconectar Internet y la herramienta sigue funcionando si la página ya está cargada.
¿Qué es la Web Crypto API?
API nativa de navegadores modernos para operaciones criptográficas. Soporta SHA-1/256/384/512 para hashing. No soporta MD5 (intencionalmente, por ser inseguro). Compatible con Chrome 37+, Firefox 34+, Safari 7+, Edge 12+.
¿Qué es Base64 y para qué sirve?
Codificación (no cifrado) que convierte datos binarios en texto ASCII usando 64 caracteres seguros. El texto en Base64 es ~33% más largo. Usos: JWT, emails MIME, data URLs en HTML/CSS, autenticación HTTP Basic. NO es cifrado: cualquiera puede decodificarlo.
¿Cómo usar SHA-256 en JavaScript?
Con la Web Crypto API: async function sha256(text) {‘{ ‘}const buf = await crypto.subtle.digest(‘SHA-256′, new TextEncoder().encode(text)); return Array.from(new Uint8Array(buf)).map(b => b.toString(16).padStart(2,’0’)).join(»);{‘ }’}. Es asíncrono (Promise/async-await).
¿Qué son las rainbow tables?
Bases de datos pre-calculadas de millones de contraseñas comunes mapeadas a sus hashes (MD5/SHA-1). Si un atacante roba tu BD con hashes sin salt, puede buscar el hash y encontrar la contraseña en segundos. La solución: salt + bcrypt/Argon2 hace inviables las rainbow tables.
¿Cómo verifica el SAT la integridad de los CFDIs?
El SAT usa SHA-256 + firma RSA. La cadena original del CFDI se hashea con SHA-256. El hash se firma con la llave privada del contribuyente. La firma se codifica en Base64 y es el “sello digital”. El SAT verifica que el sello corresponda a la cadena original usando la llave pública del contribuyente.
¿Qué es HMAC-SHA256?
Hash-based Message Authentication Code con SHA-256. Combina una clave secreta con el mensaje para producir un hash que solo puede verificar quien tiene la clave. Se usa para autenticar peticiones a APIs (como las APIs de pago en LatAm). Verifica integridad Y autenticidad del mensaje.
¿Hashing es lo mismo que cifrado (encriptación)?
No. Hashing es irreversible (una dirección): no hay clave para recuperar el original. Cifrado es reversible con una clave. El término “encriptador MD5” es un coloquialismo incorrecto: MD5 genera hashes, no cifra. Para cifrar: usa AES-256-GCM. Para hashear: usa SHA-256.
¿Cómo se usa SHA-256 en Bitcoin?
En el mecanismo Proof of Work (los mineros buscan un nonce tal que SHA-256(SHA-256(bloque)) comience con N ceros) y en la derivación de direcciones Bitcoin (clave pública → SHA-256 → RIPEMD-160 → dirección). Bitcoin depende de la resistencia a colisiones de SHA-256.
¿Cómo verificar la integridad de un archivo descargado?
Windows: CertUtil -hashfile archivo.exe SHA256. Linux/Mac: sha256sum archivo.exe. El hash resultante debe coincidir exactamente con el hash SHA-256 publicado en el sitio oficial de descarga. Si no coincide, el archivo está corrupto o fue modificado.
¿Qué es el efecto avalancha?
Cambiar un solo carácter en el input cambia completamente el hash output. Ejemplo: SHA-256 de “Hola” y “hola” son completamente diferentes. Esto hace imposible “adivinar” el hash de un texto conociendo el hash de un texto similar.
¿Cómo se usa Base64 en JWT?
Un JWT tiene 3 partes en Base64 separadas por puntos: header.payload.signature. Header y payload son Base64 del JSON correspondiente (decodificable por cualquiera). Solo la signature verifica la autenticidad. Base64 en JWT es para transporte, no seguridad.
¿Por qué el proyecto Gravatar usa MD5?
Gravatar (avatares de usuario en WordPress, GitHub, etc.) usa MD5 del email como identificador de perfil por razones históricas (creado en 2007). No es para seguridad sino como identificador único público. Gravatar no ha migrado a SHA-256 por compatibilidad con millones de integraciones existentes. El único uso moderno legítimo de MD5 en producción requerido por un servicio externo.
Herramientas Relacionadas de Seguridad y Desarrollo Web
Aviso Legal y Transparencia Editorial
Esta herramienta genera hashes criptográficos y codificaciones Base64 con fines educativos y de desarrollo. Ningún dato introducido se envía a servidores externos. Los algoritmos MD5 y SHA-1 se incluyen con fines educativos y de compatibilidad con sistemas heredados; no se recomienda su uso para aplicaciones de seguridad en 2025. Para el almacenamiento de contraseñas en aplicaciones de producción, sigue las recomendaciones de OWASP. Las advertencias de seguridad incluidas en esta herramienta reflejan el consenso actual de la comunidad de seguridad informática. Última actualización: julio 2026.