Carga una captura HAR, ejecuta las reglas por nombre de campo y revisa la salida antes de compartirla: cubre cabeceras, cookies, cadenas de consulta, formularios y cuerpos JSON, y los cuerpos de respuesta si marcas la casilla; lo que no tiene un nombre reconocible se queda como se capturó.
Se ejecuta localmente en tu navegadorPega una captura HAR o suelta el archivo .har: la página lee log.entries, sustituye por [REDACTED] los valores que coinciden con sus reglas y reescribe la captura como JSON indentado en esta misma pestaña. Una captura de prueba con tres entradas informó de 22 valores sustituidos sin tocar los cuerpos de respuesta y 24 al incluirlos; una captura compacta de 3.9 KB volvió como 6.4 KB porque la salida va formateada.
Las reglas funcionan por nombre de campo —Authorization, X-Api-Key, Cookie, Set-Cookie, api_key, access_token, refresh_token, id_token, token, password, secret, session, jwt, csrf, signature y sus variantes— en cabeceras y cookies de solicitud, cadenas de consulta, parámetros de URL, campos de formulario, cuerpos JSON, cabeceras y cookies de respuesta, URL de redirección y campos propios del HAR. Los valores también se reconocen por su forma: credenciales Bearer y Basic y un JWT que empieza por eyJ se sustituyen allí donde aparezcan.
Una cabecera, una cookie o un campo de formulario se reescriben cuando su nombre coincide con la lista, sea cual sea el valor. Un parámetro de consulta se reescribe cuando su nombre coincide, incluido un token= suelto y el code= de OAuth de una redirección; el resto de la URL conserva su orden, sus otros parámetros y su #fragment, y la sustitución se escribe tal cual como [REDACTED], sin codificar. Una cabecera Location que contiene una URL sigue las mismas reglas de consulta.
Los cuerpos JSON se recorren clave a clave, así que los objetos y arrays anidados también quedan cubiertos: en la captura de prueba password, un api_key anidado, un token suelto y un secret dentro de un array volvieron como [REDACTED], mientras que valores sin relación como una dirección de correo y una nota quedaron legibles. Los campos propios del HAR que empiezan por guion bajo se recorren con las mismas reglas, así que un token guardado junto a la captura también se oculta.
El contenido de respuesta solo se toca cuando marcas la casilla. Al marcarla, un cuerpo base64 se descodifica primero, se oculta y se vuelve a codificar en base64 con su campo encoding intacto: un access_token dentro de un cuerpo JSON en base64 pasó a [REDACTED] y el cuerpo siguió descodificándose como JSON válido. Un cuerpo sin coincidencias se devuelve byte a byte como se capturó, incluidos sus saltos de línea originales en base64.
Todo lo demás viaja sin cambios: número de entradas, títulos y tiempos de página, estados HTTP, tamaños de cabecera y cuerpo, direcciones IP del servidor y horas de inicio. Pasar la salida otra vez por la herramienta informa de 0 sustituciones, así que una captura ya saneada se puede revisar de nuevo sin más cambios.
Las reglas coinciden con nombres de campo y formas de credencial, no con valores que parezcan sospechosos. Un secreto sin ningún nombre —en la ruta de una URL, en un campo de comentario del HAR o como valor de un campo corriente como note— se deja tal cual, igual que un cuerpo de respuesta mientras su casilla esté sin marcar. La línea de hallazgos dice cuántos valores se sustituyeron; nunca afirma que el archivo sea anónimo, así que conviene revisar la salida antes de adjuntarla a un ticket.
Una entrada vacía, un JSON mal formado y un JSON sin el array log.entries terminan cada uno con su propia frase y sin descarga: un documento truncado se informa con la línea y la columna donde se detuvo el análisis, y un JSON que no es una captura HAR se nombra como tal en lugar de producir un archivo vacío. Todo el proceso ocurre en el navegador: la página no envía la captura en ninguna petición.