Los eslóganes no se comprueban. El tráfico, sí.
Mucha gente juzga una página de «cifrado en línea» por una frase: cálculo local, cero subidas, extremo a extremo. Esas palabras pueden estar en cualquier sitio, también en uno que hace POST del archivo al servidor y lo cifra allí. No son evidencia.
Lo que sí puedes ver es qué peticiones envía esta pestaña. El panel Network lista método, URL, consulta, cuerpo y parte de analytics. Si aparece el nombre del archivo que acabas de elegir, la contraseña o un canario que solo tú conoces, el cifrado local ya ha fallado.
Al revés el alcance es menor. Un panel Red limpio solo indica que esta ejecución no envió esos campos. No demuestra que la memoria no tenga el original, que una extensión no haya leído el portapapeles ni que la próxima versión se comporte igual. El valor está en convertir un texto no verificable en una observación repetible.
Qué significa de verdad «local»
«Local en el navegador» no es «este dominio parece de fiar». Significa que cifrar y descifrar ocurre en la pestaña que estás viendo. Para AES-256-GCM, el camino correcto suele ser la Web Crypto API: derivación de clave, cifrado y etiqueta de autenticación se ejecutan en la interfaz criptográfica del navegador, no entregando el texto en claro a una API remota.
Un flujo típico de archivo: eliges un archivo local, el script lo lee en bloques binarios en memoria, cifra cada bloque y el navegador descarga el cifrado. El archivo .lock o .enc es el resultado, no un recibo de subida. Un tope de 5 GB por archivo describe la capacidad de streaming local, no un servidor que haya aceptado 5 GB de texto en claro.
Separa también «subida de negocio» de «peticiones que la página siempre hace». Un sitio de herramientas listo al abrir sigue cargando CSS y scripts, y puede enviar analytics sin cuerpo de mensaje. Esas peticiones no demuestran que se subió un archivo. Si una consulta o un cuerpo de analytics contiene la contraseña que acabas de escribir, eso es otro hallazgo.
Una frase comprobable vale más que adjetivos: el texto en claro y las claves de generación de contraseñas, comprobación, limpieza de privacidad y cifrado de archivos se quedan en el navegador por defecto; el enlace de un solo uso solo puede enviar cifrado, con la clave de descifrado en el fragmento # de la URL. MakePwd implementa las herramientas en ese límite, todas listas al abrir y sin cuentas. Una promesa sigue siendo una promesa. Network la convierte en una lista de comprobación.
No pruebes con claves reales, documentos de identidad ni hojas sin enmascarar. Usa un archivo pequeño desechable y una frase larga de un solo uso. Estás comprobando tráfico, no volviendo a exponer privacidad.
Una comprobación repetible con Network
Primero elige una marca que no aparezca en el trabajo real. Nombra el archivo canary-local-2026.xlsx, usa una frase larga aleatoria y pon en el cuerpo una frase que exista solo en esta prueba. El canario sirve para buscar: pégalo en el filtro de Network. Un acierto es un fallo.
Abre las herramientas de desarrollo, ve a Network, activa Preserve log y filtra XHR / Fetch. No mires solo las peticiones correctas: las canceladas o con 4xx pueden haber llevado ya texto en claro.
Luego haz una acción completa: elige un archivo, introduce la contraseña, pulsa cifrar o generar. Deja el panel abierto y revisa los tres puntos de abajo.
- Pega primero el canario en el filtro y busca un acierto en rojo. Si aparece, para y lee esa petición. No sigas juzgando por si «parece local».
- Si no hay acierto, abre cada XHR / Fetch y compara la línea de petición, la consulta y el cuerpo. Los estáticos, fuentes y scripts se pueden ignorar.
- Filtra aparte las rutas de analytics y abre consulta y cuerpo. Pueden aparecer título y ruta de la página. No deben aparecer la contraseña que acabas de escribir, la contraseña a comprobar, el texto sin limpiar ni el contenido del archivo.
Lee la línea de petición
Lee carácter a carácter la ruta y la consulta después de ?. Pueden aparecer campos de localización como id. No deben aparecer nombres de archivo, contraseñas, la contraseña a comprobar ni la clave detrás de #. Compara la barra de direcciones completa con la línea de petición: si la parte posterior a la almohadilla entró en la línea, la implementación trató el fragmento como consulta, o un script lo leyó y lo escribió en una petición.
Lee el cuerpo de la petición
Los payloads POST / PUT son el segundo sitio. Si el cifrado de archivos dice que termina en local, el cuerpo no debe contener los bytes del archivo original ni la contraseña. El enlace de un solo uso puede incluir un campo de cifrado —es el dato saliente esperado; confirma que no parece el texto que acabas de escribir. Si una página de comprobación de contraseñas hace POST de la contraseña, da igual que el motivo diga «consulta de filtraciones» o «puntuación de fortaleza»: ya ha salido del dispositivo.
Revisa analytics por separado
Es fácil saltarse analytics. Una API de producto limpia con un hit de analytics que lleva la entrada completa sigue fallando «el texto en claro se quedó en el navegador». Al filtrar rutas de analytics, no asumas que «el script de analytics es inofensivo». Es otra petición saliente, y se comprueba igual que una API de producto.
Activa Preserve log. Tras cifrar, una navegación o recarga puede borrar la primera petición que llevaba texto en claro si la casilla está desmarcada, y tendrás un panel vacío falso.
Las consultas van por HTTP. Los fragmentos, por lo general, no.
Una URL tiene dos partes que la gente mezcla. La consulta detrás del interrogante entra en la línea de petición HTTP. Servidores, proxies inversos y registros de acceso pueden verla. El fragmento detrás de la almohadilla se queda en el navegador por defecto para los scripts de la página actual y no se envía con esa petición del documento.
Por eso, si un enlace de cifrado de un solo uso pone la clave en #, al abrir s.html?id=...#clave el servidor, por diseño, solo ve id, no la clave. No es un protocolo criptográfico extra. Es el comportamiento por defecto del fragmento. Tiene límites: pega la dirección completa en un ticket, un chat de grupo o una redirección que quite el hash, y la clave pasa de «no está en HTTP» a «en la pantalla y los registros de otra persona».
La comprobación es igual de concreta: crea un enlace de un solo uso de prueba y confirma que el cuerpo de la petición de creación solo tiene cifrado; abre la página de lectura y confirma que la petición del documento y las APIs posteriores solo contienen id. La parte después de # en la barra de direcciones no debe aparecer en esas peticiones. La página de lectura es pública para el destinatario y no pide inicio de sesión.
| Dónde mirar | ¿Viaja por HTTP? | Qué cuenta como aprobado |
|---|---|---|
| Eslogan de la página | No interviene | No es evidencia: úsalo solo como contraste |
| Línea de petición / consulta | Sí | Sin canario, sin contraseña, sin clave del fragmento |
| Cuerpo POST | Sí | Sin texto en claro; el enlace de un solo uso solo puede enviar cifrado |
Fragmento # de la URL |
Por lo general, no | Presente en la barra de direcciones, ausente en la línea de petición |
| Analytics | Depende de la implementación | Sin texto crudo del cuadro de entrada |
Qué puedes demostrar y qué no
La conclusión que sostiene esta comprobación es estrecha. Escribir ese límite sirve más que estirarlo.
Puede sostener: en este navegador, esta versión y esta acción, el texto en claro, la contraseña y la clave del fragmento no salieron de la pestaña como datos HTTP de negocio observados ni como texto fuente de analytics.
No puede sostener: que ninguna otra pestaña o extensión lea el portapapeles; que la carpeta de descargas sea segura; que el destinatario no haga captura del cifrado tras descifrar; que la comprobación de contraseñas cubra todos los corpus de filtraciones. Si el comprobador solo hace entropía local más una lista pública de contraseñas débiles, responde a «¿parece una contraseña débil habitual?», no a «nunca apareció en una filtración». No es una consulta HIBP a escala web.
Tampoco lo trates como un test de penetración. No inspeccionaste WebSockets ni cachés de Service Worker, ni revertiste scripts ofuscados. El objetivo es poder decirle a un compañero: abrí Network, busqué el canario y la línea de petición y el cuerpo estaban limpios. Eso se acerca más a una conversación de ingeniería que reenviar «el sitio dice que no se sube nada».
Usa los mismos pasos en herramientas listas al abrir
Si quieres una página que escriba con claridad el límite de cálculo, empieza por Cifrar archivo de MakePwd. Se abre sin registro. Elige un archivo pequeño sin privacidad real, usa una contraseña canario, cifra y descarga un .lock. Mira Red (Network): deberías ver estáticos y quizá analytics, no el archivo original ni la contraseña. El sitio documenta AES-256-GCM en Web Crypto, un archivo de hasta 5 GB.
El enlace de un solo uso es el segundo ejercicio: crea un texto de prueba inofensivo y confirma que lo saliente es cifrado. La página de lectura es pública para el destinatario; la forma del enlace es s.html?id={id}#{key}. La comprobación de contraseñas es el ejercicio de «¿entra el cuadro de entrada en analytics?»: la contraseña a comprobar no se sube y la coincidencia es contra una lista local.
Estos ejercicios no demuestran que un sitio sea «absolutamente seguro». Familiarizan la misma lista. En cualquier página que afirme cifrado local, los pasos se mantienen: canario, Preserve log, línea de petición, cuerpo, analytics.
Tres cosas para recordar la próxima vez
Primero, mira el tráfico, no los eslóganes. Segundo, el cifrado saliente puede ser aceptable; las claves y el texto en claro, no. Tercero, vuelve a buscar el canario si cambias de navegador, versión o función. Solo una observación repetible merece entrar en tus propias notas de seguridad.
Si la siguiente pregunta es por qué una clave puede ir detrás de la almohadilla, lee Por qué el fragmento # de una URL encaja para una clave y cuándo esa protección falla. Este texto solo convierte «¿salió el texto en claro de esta pestaña?» en una comprobación que puedes terminar al momento.