Before you paste that HAR file into ChatGPT: three leaks, and the local tool I built instead

Every developer has done this: an API call fails, you copy the request from DevTools, decode the token somewhere, convert a timestamp somewhere else, and finally paste the whole thing — headers, cookies, token and all — into ChatGPT, a GitHub issue or a support ticket.

That last step is where things can go wrong.

Three public reminders

1. Code formatters that saved everything.

In November 2025, watchTowr Labs reported that the “save/share” features of JSONFormatter and CodeBeautify had exposed 80,000+ saved snippets, including Active Directory credentials, cloud keys, JWTs, private keys and CI secrets.

2. HAR files sent to support.

In 2023, attackers who gained access to Okta's support system accessed session tokens contained in HAR files that customers had uploaded for troubleshooting. Cloudflare subsequently open-sourced a HAR sanitizer.

3. Secrets printed into CI logs.

In March 2025, the tj-actions/changed-files GitHub Action was compromised and exposed secrets through build logs across 23,000+ repositories.

The broader problem isn't limited to source code. Debugging data also ends up in tickets, chat, support systems and other collaboration tools.

The workflow I wanted

I wanted one step that does three things:

1. Explain the likely cause with evidence — not a guess.
2. Redact secrets while keeping the data debuggable.
3. Package it for whoever helps me: an AI chat, a GitHub issue, or a vendor's support desk.

So I built Debug Report.

It takes a cURL/HTTP request and response, HAR file, JWT or log and produces a deterministic debugging report directly in the browser.

What it checks

There is no AI involved in the analysis.

The current rules cover things like:

• JWTs: expired or not-yet-valid tokens, server Date headers for clock-skew checks, alg: none, missing exp. Signatures are never claimed as verified.
• HTTP: 401 authentication problems, WWW-Authenticate, 403 CSRF hints, 405 Allow, 415, 429 Retry-After, and 5xx request IDs.
• CORS: missing or mismatched Access-Control-Allow-Origin, wildcard origins combined with credentials, and preflight method/header mismatches.
• Cookies & URLs: SameSite=None without Secure, session cookies without HttpOnly, credentials in query strings, and credentials over plain HTTP.
• Logs: large logs grouped into distinct messages, Java Caused by: chains, and the final line of Python tracebacks.

Each finding tells you what was detected, why it matters, what to do, the supporting evidence, and whether it was Detected or Not verified.

That last distinction matters.

If the tool sees an expired JWT, it can say that the JWT is expired based on the available timestamps.

It does not pretend that it verified the JWT's cryptographic signature.

Redaction happens locally

Before you share the result, Debug Report can redact things such as:

• JWTs
• API keys and secrets
• email addresses
• IP addresses

The original input stays in the browser while you work with it. The hosted version uses anonymous usage counters, but the page's Content Security Policy prevents the application from making arbitrary network requests.

The goal isn't to replace your existing debugging tools.

It's to put a safer step between “this request is broken” and “here is the raw request I'm about to send somewhere else.”

Try it

Debug Report: https://json-workbench.netlify.app/#debug

Source code: https://github.com/Nikhil03-hub/dev-tools-hub

It's free, open source, and MIT licensed.

I'm testing it for three weeks before deciding what to build next.

If you debug APIs regularly, I'd genuinely like to know:

What would make a tool like this useful enough that you'd actually keep it in your workflow?