SSOGEN / Free tools / HAR File Analyzer: Redact a Sign-In Capture and Read What Failed

Free tool

HAR File Analyzer: Redact a Sign-In Capture and Read What Failed

A HAR file analyzer reads a browser's network capture and shows what happened request by request. This free one masks cookies, tokens and SAML messages first, then lays out the redirects, the OAuth, OpenID Connect and SAML steps and the errors, all in your browser.

Try SSOGEN

Analyze a HAR file here

Drop a .har file on the box, or paste its contents.

To see the output before using your own file, load one of the two Acme samples:

OpenID Connect sample. A code flow that fails on a redirect address.
SAML sample. A sign-in that succeeds.

Both use made-up values on the reserved acme.example domain.

Drop a .har file, or paste its contents

A HAR file is a JSON record of every request a browser made. Capture one with the steps further down this page. The redacted copy appears first; nothing leaves this page.

Drop a .har file here, or press Enter to choose one

Private by design. The file is read in this page and nothing is sent anywhere or saved. A HAR file can hold session cookies and tokens that sign in as the person who captured it: share only the redacted copy, and read it before you send it.

Free, in your browser. There is no sign-up and no limit. The page makes no network request during analysis and saves the file nowhere. The redacted copy is built in the page, and you decide whether to download it.

What a HAR file holds

A HAR file (HTTP Archive) is a JSON record of every request a browser made while you reproduced a problem.

The exchange. For a failed sign-in it holds the full exchange: each redirect, status code and error.
The secrets. It also holds your session cookies and often the authorization code, the tokens and the SAML message, so do not send one to anyone straight out of the browser.

This HAR file analyzer works in two steps.

It produces a redacted copy you can share.
It reads the sign-in.

If the capture ends on AADSTS50011, compare the two URIs with the AADSTS50011 checker.

How to capture a HAR file

The procedure is the same in every browser: open the developer tools, turn on the setting that keeps the log across page loads, reproduce the sign-in from the start, then export.

Turn the log on before you start. A sign-in is a chain of redirects, and each one would otherwise clear the list.

Chrome
Open DevTools and select the Network panel. The Chrome DevTools Network reference (read 2026-10-09) gives the sequence: select Preserve log, reproduce the problem, then use Export HAR (sanitized) in the action bar at the top of the panel. That export leaves out the Cookie, Set-Cookie and Authorization headers. Including them requires Allow to generate HAR with sensitive data under Settings, Preferences, Network. Leave that setting off for any file you intend to share.
Edge
Open DevTools and the Network tool. Microsoft’s Network features reference (read 2026-10-09) describes the same two choices. Export HAR (sanitized) is the default. Export HAR (with sensitive data) appears only after you select Allow to generate HAR with sensitive data in Settings, Preferences, Network.
Firefox
Open the Network Monitor. The Firefox Source Docs (read 2026-10-09) state that the log clears on each navigation by default, and Persist Logs prevents that. In the menu of additional actions on the toolbar, Save All As HAR opens a file dialog and saves a .har file; the same menu has Copy All As HAR. The documentation does not say that Firefox removes any headers, so assume the file contains everything.
Safari
Turn on Safari’s developer features first. Apple’s Develop menu guide (read 2026-10-09) says to choose Safari, Settings, Advanced, then select Show features for web developers. Next, open Web Inspector from the Develop menu and select the Network tab. The WebKit Network tab documentation (read 2026-10-09) describes a Preserve Log checkbox there. To save an HTTP Archive file, click Export or press Command and S.

Record only what you need. Start on the application’s sign-in address, use a test account where you can, and stop as soon as the error appears. A short capture is faster to read and exposes less.

What a HAR file holds that is sensitive

Every request and response is stored with its headers, its address and often its body. A HAR file is therefore a copy of a signed-in session. The sensitive parts are these:

Where it sits	What it can contain	Why it matters
`Cookie` and `Set-Cookie` headers	Session cookies for the application and the identity provider	Anyone holding the file may be able to replay the session until it expires or is ended
`Authorization` header	Bearer tokens, basic credentials	The same: it is the key to an API
Address query string	`code`, `state`, `nonce`, sometimes `id_token` or `access_token`	An authorization code or token in the address ends up in the file
Form body of a POST	`password`, `client_secret`, `code_verifier`, `SAMLResponse`	A password typed into a form is stored in clear text
Response body	ID tokens and access tokens in JSON, SAML messages inside auto-submitting HTML forms	Tokens come back in bodies, not only in headers
Header and address detail	Internal host names, user names, email addresses	Not a credential, but it describes your estate

The browsers’ sanitized exports cover only the first two rows. The Chrome and Edge pages name the Cookie, Set-Cookie and Authorization headers as the ones removed and say nothing about addresses or bodies.

A sign-in capture keeps its codes and SAML messages in exactly those places. Run even a sanitized file through a redactor, and read it before it leaves your hands.

Support teams and vendors ask for HAR files because they show a failure fastest. Masking the secrets first takes about a minute.

What the redactor masks

The redacted copy comes first by design. The tool replaces each value with [REDACTED] and keeps the name, so you can still see that a parameter was present. It masks:

Cookie, Set-Cookie, Authorization, Proxy-Authorization and CSRF token headers, and the cookie lists.
Query, fragment, form and JSON values named code, access_token, id_token, refresh_token, client_secret, client_assertion, password, SAMLResponse, SAMLRequest, RelayState, state, nonce, code_verifier, assertion, username, login_hint and a few similar names.
Hidden form fields with those names in HTML responses, which is how a SAML response arrives by POST.
Anything shaped like a JWT, anywhere, including inside a header or a JSON body.
Response bodies sent as base64, which are replaced by a short note.

It does not mask host names, paths, other user names in free text, or a secret stored under a name it does not recognize.

Before you send the file, search the redacted text for your account name, your internal domain and any customer data. The tool is a first pass, and you remain responsible for what you share.

Work down the timeline in order. The failure is the first request that does not do what the previous one set up.

Find where the application sends the browser away. The first redirect (a 302 with a Location) usually points at the identity provider. Its address should carry the protocol parameters.
Check the request that goes to the identity provider. For OpenID Connect, check client_id, redirect_uri, scope and response_type. For SAML, look for SAMLRequest.
Follow the identity provider’s own pages: a login form, a multi-factor prompt, a consent page. A 4xx or 5xx here, or an error parameter, is the failure.
Find the way back. The identity provider sends the browser to the application with a code (OpenID Connect) or posts a SAMLResponse to the assertion consumer address.
Check what the application does with it. In the code flow, the application’s server calls the token endpoint. A browser capture does not show that call unless it goes through the browser. For SAML, the application answers the POST with a redirect and sets a session cookie.
Check that the session cookie is sent back. A cookie that is set but never returned causes a loop: the application redirects to sign-in again and again.

What to look for in each protocol

Protocol	Healthy	Common failure and how it shows
OpenID Connect, code flow	Authorization request with `response_type=code`, `state`, `nonce`; a redirect back with `code` and the same `state`; a token request that returns tokens	The identity provider answers `400` with an `error`; the token call returns `invalid_grant`, often because the `redirect_uri` is not the one used in the first request
OpenID Connect, PKCE	`code_challenge` and its method in the first request, `code_verifier` in the token request	A token request with no `code_verifier` when the first request had a challenge
SAML, redirect then POST	A `SAMLRequest` in the address, a `SAMLResponse` posted to the application, a redirect that sets a session cookie	The response has a status other than Success, or an issuer, destination or audience that the application does not expect
Any redirect-based sign-in	Each address requested once	The same address requested three or more times: a loop, usually a cookie that is dropped
Microsoft Entra sign-in	A code that begins `AADSTS` appears in the page	Look the code up in Microsoft’s error code reference (read 2026-10-09). For example, AADSTS50011 is listed there as InvalidReplyTo, meaning the reply address is missing, misconfigured or not among those registered for the app

The tool runs these checks and grades each finding: green for normal, amber for something to review, red for a problem. It also labels each request that belongs to a sign-in step, so the timeline reads in sequence.

Worked example: a redirect address that does not match

Load the OpenID Connect sample and read three requests.

Request 1. A plain visit to the Acme ERP site. It redirects (302) to login.acme.example/oauth2/authorize with client_id=erp-web and a redirect_uri ending in /callback.
The next request. It succeeds and returns the browser with a code. Up to this point the flow is correct.
Request 4. The token call returns 400 with invalid_grant. Its form body sent a redirect_uri ending in /oauth/callback, so the two addresses differ.
Request 5. A second attempt with the new address, which is not registered at all. It returns a 400 page with an AADSTS50011 code.

In request 4, the code was issued for one address and exchanged with the other, and an identity provider refuses that.

The fix is the same in both cases: make the redirect_uri the application sends match the registered one character for character, including the path and trailing slash.

The tool also notes that this flow skipped PKCE and sent the secret in the token request body. These are observations, not faults.

A server-side application with a client secret can be configured that way on purpose.

Cookies and SameSite hints

The analyzer reads Set-Cookie headers and reports only what their attributes show:

It flags a cookie with SameSite=None and no Secure, since MDN (read 2026-10-09) states that SameSite=None must come with Secure.
It flags a SameSite=None cookie set by a host other than the first one in the capture. A browser’s third-party cookie blocking can drop that kind of cookie.
It lists cookies with no SameSite attribute at all. MDN says some browsers then apply Lax.

A sanitized export contains no cookie headers to read. In that case the tool says so instead of guessing.

Next steps after you find the request

Once the timeline points at one request, decode the message it carries.

A SAML message. Paste a SAML response or request into the SAML tracer and decoder.
A token. Paste an ID or access token into the JWT decoder.
The sequence. See how SSO works, what SAML is and what OpenID Connect is.

Questions about HAR files

What is a HAR file?

A JSON file in the HTTP Archive format. It records the requests a browser made: addresses, headers, status codes, timings and often bodies. The Network tool in every major browser can export one.

Is it safe to share a HAR file?

Not as exported. A HAR file can hold session cookies, tokens, authorization codes and typed passwords. The browsers’ sanitized export removes certain headers, but addresses and bodies can still carry secrets. Share a redacted copy, and read it first.

Does this HAR file analyzer upload my file?

No. The page reads and processes the file itself, makes no network request and keeps no copy. Closing the tab discards it.

How do I sanitize a HAR file?

Drop it into the analyzer above and download the redacted copy. It masks cookies, authorization headers, tokens, codes, passwords, SAML messages, state and nonce values and anything shaped like a JWT. Before you send it, search the result for your own names and data.

Why does my HAR file show no cookies?

Chrome and Edge export a sanitized HAR by default, and that export leaves out the Cookie and Set-Cookie headers. A cookie problem cannot be diagnosed from it. Capture again with sensitive data allowed, and redact that file before you share it.

Is there a free online HAR file viewer?

Yes, this page. Drop a HAR file on it and it lists every request with its status, redirect and timing, then marks the sign-in steps and errors. It runs in your browser, so nothing is uploaded.

Can I edit a HAR file before I send it?

Yes. It is plain JSON, so any text editor works. The faster route is to take the redacted copy from this page, search it for your own names and domains, and delete anything you do not want to share.

Can it read a HAR from any browser?

It reads the standard format, a log with a list of entries, which Chrome, Edge, Firefox and Safari all export. A file in another capture format is rejected with a message.

Browse the other free tools.

Sources, all read 2026-10-09: Chrome DevTools Network reference, Microsoft Edge Network features reference, Firefox Network Monitor toolbar, Apple Safari Develop menu guide, WebKit Network tab, MDN Set-Cookie and Microsoft Entra error codes. Chrome, Edge, Firefox, Safari and Microsoft are trademarks of their owners; SSOGEN is not affiliated with them.