Codificación, hash y cifrado son tres cosas distintas
Casi todos los malentendidos sobre esta página vienen de tratarlos como intercambiables, así que vale la pena separarlos bien.
La codificación es reversible y no tiene ningún secreto. Base64 existe para transportar datos binarios por canales que solo aceptan texto (adjuntos de correo, data URI, cadenas JSON) representando cada tres bytes con cuatro caracteres, y por eso el resultado siempre es alrededor de un tercio más grande. No hay clave. Cualquiera que vea la cadena puede decodificarla en un paso, también en este sitio. Base64 no es seguridad, ni una ofuscación digna de ese nombre, ni una forma de esconder nada de quien lo mire. La codificación por porcentaje es lo mismo para las URL, y ahí vive el otro error frecuente: codificar un valor que va en una cadena de consulta es una operación distinta de limpiar una URL completa ya armada, porque solo la primera escapa los &, =, ? y / que le dan su estructura a una URL. Si te equivocas, “Smith & Sons” llega al servidor como dos parámetros en lugar de un solo valor.
El hash es de un solo sentido y tampoco tiene clave. Un hash toma cualquier entrada y produce una huella de longitud fija, y no se puede deshacer; no porque esté cifrado, sino porque la información ya no está. Lo que sí se puede hacer es adivinar entradas y comparar, y justamente por eso MD5, SHA-1 y SHA-256 no sirven para guardar contraseñas: son rápidos, una tarjeta gráfica calcula miles de millones por segundo y una tabla robada de ellos se descifra a esa velocidad. Las contraseñas necesitan una función con sal y lenta a propósito: bcrypt, scrypt o Argon2. Aparte de eso, MD5 y SHA-1 están rotos por otro motivo: hoy se pueden fabricar a propósito dos archivos distintos con el mismo hash, así que ninguno de los dos puede demostrar que un archivo es el que esperabas, aunque ambos siguen sirviendo para detectar una descarga dañada por accidente.
El cifrado es el que tiene clave, y ninguna de estas herramientas lo hace. No es un descuido. Cifrar bien exige gestionar claves, y una página web no es el lugar para una clave.
Un JWT está firmado, no cifrado, y esto confunde a la gente constantemente. El encabezado y el payload de un token están en Base64URL: cualquiera que tenga el token puede leerlos, sin necesidad de clave. La firma impide que alguien modifique el token, pero no hace nada para impedir que lo lea, así que en un payload no debe ir nada confidencial. De ahí se deduce que decodificar un token no demuestra absolutamente nada sobre él: cualquiera puede escribir los claims que quiera y pasarlos a Base64. Verificar significa volver a calcular la firma con la clave del emisor, algo que hace tu servidor y que un sitio web nunca debe pedirte. Por eso nuestro decodificador se niega a dar a entender que verifica nada, y señala los casos que indican un problema: un token vencido, un token sin ninguna fecha de vencimiento y un algoritmo “none”, que es una forma documentada de saltarse la autenticación, no una curiosidad.
JSON tiene un límite de precisión numérica con el que la mayoría de los formateadores tropiezan sin avisar. JSON en sí no pone límite al tamaño de un número, pero un número de JavaScript es un float de 64 bits, así que los enteros solo se mantienen exactos hasta 9,007,199,254,740,991. El ID de una publicación de Twitter, un snowflake de Discord, una clave de base de datos de 64 bits o un número de cuenta bancaria son más grandes, y al pasarlos por el formateador habitual de una línea (parse y luego stringify) cambian sus últimos dígitos. El resultado sigue pareciendo un número verosímil, y eso es lo que lo hace peligroso: 7205759403792793600 se convierte sin avisar en 7205759403792793000. Nuestras herramientas de JSON vuelven a serializar exactamente los dígitos que pegaste y te dicen cuántos números tuvieron que proteger.
La versión de un UUID describe cómo se creó, no lo que garantiza. Nada registra un UUID ni impone que sea único; la unicidad es probabilística, y la versión te dice de dónde salieron los bits. La versión 4 son 122 bits aleatorios del generador criptográfico del navegador, lo que la hace imposible de adivinar y por tanto adecuada para enlaces de restablecimiento, códigos de invitación y cualquier cosa secreta, pero inadecuada como clave de base de datos, porque las claves aleatorias se dispersan por un índice ordenado y lo fragmentan. La versión 7 pone primero una marca de tiempo de 48 bits en milisegundos, así que las claves se agregan al final del índice como un entero autoincremental sin dejar de ser únicas a nivel global. La contrapartida es que un UUID v7 revela claramente cuándo se creó, al milisegundo, a cualquiera que lo tenga.
Cuándo un navegador realmente no es la herramienta adecuada
Ninguna de estas trece envía nada a ningún lado. No se hace ninguna solicitud, no se registra nada y las páginas siguen funcionando sin conexión a la red, y precisamente por eso se pueden usar con la respuesta de una API llena de datos de clientes o con un token que no le enviarías por correo a nadie. Ese es el argumento honesto a su favor. Este es el argumento honesto en contra.
Pegar un secreto de producción activo en una página web es un hábito que conviene no tener, y eso incluye esta. Lo que decimos sobre privacidad es cierto, pero no es una afirmación lo que te protege, sino el comportamiento del código, y la única postura sensata ante cualquier página web es comprobar en lugar de confiar. Comprobarlo no cuesta nada: desconéctate de internet después de que cargue la página y verás que estas herramientas siguen funcionando. Una herramienta que necesitara un servidor dejaría de hacerlo. Y si una credencial sigue siendo válida y ya la pegaste en algún lugar que no puedes auditar, lo correcto es rotarla, no ponerse a razonar sobre el riesgo. Para un token que está activo ahora mismo, decodificarlo localmente (con la función Base64 de tu propio lenguaje o con dos líneas en una terminal) es mejor práctica que cualquier sitio web, incluido el nuestro.
Validación con esquema. Nuestras herramientas de JSON y XML comprueban que un documento esté bien formado, que es una pregunta distinta de si cumple un esquema. Validar contra JSON Schema o un XSD implica descargar y aplicar un archivo de esquema, que es una solicitud de red que estas páginas no hacen nunca, a propósito. Usa ajv para JSON Schema y xmllint para XSD y DTD; los dos son gratuitos y los dos lo hacen mejor de lo que podría hacerlo una página web.
Cualquier cosa realmente grande o en streaming. Los documentos se mantienen enteros en memoria, a veces dos veces mientras se formatean, así que el límite es la pestaña. Unos pocos megabytes van al instante y unos cientos no. jq procesa en streaming un archivo JSON de varios gigabytes que ningún navegador abrirá, y ripgrep busca en un repositorio entero más rápido de lo que tardas en pegar un archivo. El hash tiene una versión más estricta del mismo límite: la criptografía del navegador no calcula resúmenes de forma incremental, así que todo el archivo tiene que caber en memoria a la vez; una imagen de DVD fallará, mientras que sha256sum, shasum o certutil la procesan en streaming sin inmutarse.
Automatización e integración continua. Estas herramientas funcionan cuando una persona hace clic. Formatear todos los archivos de un repositorio, generar diez mil UUID para un fixture o revisar JSON en un pipeline es trabajo para un script: jq, xmllint, uuidgen, openssl y el comando base64 ya vienen instalados en la mayoría de las máquinas.
Verificar cualquier cosa firmada. La verificación de firmas, las cadenas de certificados y cualquier cosa que requiera una clave privada deben hacerse en tu servidor con una biblioteca que tenga mantenimiento. Esta página te dirá lo que un token afirma; nunca te dirá que un token es auténtico, y deberías desconfiar de cualquier sitio que diga que puede hacerlo sin tu clave.
Cómo elegir entre herramientas que suenan parecido
Formatear JSON vs. Validar JSON. El mismo analizador, una pregunta distinta. El formateador sirve para leer y reorganizar un documento que ya se puede analizar: aplicarle sangría, minificarlo, mantener intactos los números grandes. El validador es para un documento que no se puede analizar, y lo que devuelve es la línea, la columna, el carácter problemático con un acento circunflejo debajo y cuál de las cuatro causas habituales fue. Si estás mirando un “Unexpected token”, lo que necesitas es el validador. La misma división vale para Formatear XML y Validar XML.
Decodificar Base64 vs. Decodificar JWT. Un JWT son tres secciones en Base64URL, así que el decodificador general te mostrará las partes. La página de JWT las separa por ti, formatea el JSON, convierte los claims de vencimiento, emisión y “no antes de” de marcas de tiempo Unix a fechas reales en tu zona horaria, etiqueta los claims registrados y te avisa del vencimiento y de un algoritmo “none”. Usa el decodificador general para un bloque de Base64 y la página de JWT para un token.
Codificar Base64 vs. Codificar URL. Tareas distintas que producen texto “seguro”. Base64 convierte bytes arbitrarios en texto a costa de un 33 por ciento más de tamaño, y el Base64 estándar no es seguro en absoluto dentro de una URL: sus +, / y = significan algo ahí, y por eso existe Base64URL. La codificación por porcentaje deja legible el texto legible y solo escapa lo que rompería la URL, que es lo que quieres para un término de búsqueda, una dirección de correo o un destino de redirección. Codificar un archivo entero para una cadena de consulta suele ser señal de que debería haber ido en el cuerpo de la solicitud.
Generador de hash vs. Generador de UUID. Un hash se deriva de su entrada, así que la misma entrada siempre da el mismo valor; eso lo convierte en una huella, útil para verificar una descarga o eliminar contenido idéntico duplicado. Un UUID es aleatoriedad nueva sin relación con nada, así que nunca se repite. Si quieres el mismo identificador para el mismo contenido, calcula su hash. Si quieres un identificador nuevo, genera un UUID.
Generador de códigos QR vs. Generador de códigos de barras. Un QR es una cuadrícula bidimensional que guarda cualquier texto (una URL, los datos de una red Wi-Fi, un número de teléfono) y se lee con la cámara de un celular. La página de códigos de barras crea los códigos unidimensionales de comercio y logística: EAN-13, EAN-8, UPC-A, ITF-14, Code 128 y Code 39, con el dígito de control comercial calculado y rechazando un número incorrecto o incompleto en lugar de rellenarlo sin avisar hasta formar un código de barras válido de otro producto.