If you use Have I Been Pwned for breach checks, API lookups, or password monitoring, errors can interrupt an otherwise simple workflow.
This guide explains how to troubleshoot Have I Been Pwned errors by identifying the root cause, testing likely fixes, and knowing when the issue is on your side versus the service’s.
What Have I Been Pwned errors usually mean?
Have I Been Pwned, often abbreviated as HIBP, is a widely used breach notification and exposure checking service created by security researcher Troy Hunt.
Errors can appear in the website, browser extensions, API integrations, password manager features, or automated scripts that depend on the HIBP API.
Most problems fall into one of four categories: connectivity issues, authentication problems, rate limiting, or format and input mistakes.
Understanding which category applies is the fastest way to restore access.
Check whether the problem is local or service-wide
Before changing settings, confirm whether HIBP itself is available.
If the website loads normally in one browser but not another, the issue is likely local.
If the site or API fails everywhere, the service or a network path may be affected.
- Open the HIBP website in a private or incognito window.
- Try a different browser or device on the same network.
- Switch from Wi-Fi to mobile data to rule out network filtering.
- Check the HIBP status or announcements from official channels if available.
Service-wide outages are rare, but DNS failures, content filters, or corporate firewalls can make HIBP look unavailable even when it is healthy.
How to troubleshoot website access errors
If the HIBP website returns a blank page, endless loading, or a generic error, start with browser-level fixes.
Modern browsers cache scripts aggressively, and a stale cache can break pages that rely on updated front-end code.
- Clear the browser cache for the HIBP domain.
- Disable extensions that block scripts, ads, or privacy trackers.
- Allow JavaScript and cookies for the site.
- Temporarily turn off VPNs, proxy tools, or corporate secure web gateways.
- Flush DNS cache on your device if pages fail to resolve.
If the site loads in one browser but not another, compare extension sets and privacy settings.
Script blockers such as uBlock Origin, NoScript, or enterprise endpoint protection can interfere with search forms and page assets.
How to troubleshoot API errors
Many developers encounter Have I Been Pwned errors through the API rather than the website.
HIBP’s API has strict rules around authentication, request structure, and rate limits, so a small mistake can produce 401, 403, 404, or 429 responses.
Authentication problems
A 401 or 403 response usually indicates a key, header, or authorization problem.
For the API, verify that you are sending the expected API key header exactly as documented and that the key is active.
Check for missing spaces, typos, or copied whitespace that can invalidate a request.
- Confirm the API key has not expired or been revoked.
- Ensure headers match the required name and format.
- Verify your request uses HTTPS.
- Test with a known-good tool such as curl or Postman.
If an integration suddenly stops working, rotate the key and retest.
Keys stored in environment variables can also be overwritten by deployment changes or secret manager updates.
Rate limiting and throttling
A 429 status code means you have exceeded the allowed request rate.
The HIBP API enforces limits to protect service reliability, so fast polling or poorly designed loops can trigger throttling quickly.
- Add exponential backoff between retries.
- Cache responses instead of rechecking the same email repeatedly.
- Batch requests only when the API endpoint supports the pattern you use.
- Log timestamps to identify bursts from cron jobs or parallel workers.
In production systems, a queue or cache layer can dramatically reduce repeat queries.
For example, checking the same user record on every page load is unnecessary if the result has not changed.
Input and endpoint mistakes
Incorrect email formatting, malformed URLs, or wrong endpoint paths often produce confusing failures.
The HIBP API is sensitive to the exact endpoint used for breaches, pastes, passwords, or account-specific lookups.
- Trim leading and trailing spaces from email addresses.
- Validate encoding for special characters in query strings.
- Use the correct endpoint for the data you need.
- Confirm that your HTTP method matches the documentation.
It also helps to test with a single known email address that has a known result.
If one address works and another fails, the issue may be with input sanitization rather than the API itself.
Why password manager integrations fail
Password managers such as 1Password, Bitwarden, Dashlane, and browser-based tools may surface HIBP-related warnings during password audits.
When these checks fail, the cause is often an integration setting, outdated app version, or blocked outbound traffic.
- Update the password manager to the latest version.
- Reauthorize the HIBP feature if the app requires consent or a connected account.
- Check whether your organization blocks external reputation or breach-checking services.
- Review local antivirus or firewall settings that may block API traffic.
Some password managers use k-anonymity style queries or local breach databases rather than direct full-email lookups.
If one feature fails, another may still work because it relies on a different lookup method.
How to read HIBP error messages effectively
Error text is often more useful than the status code alone.
A message about an invalid API key points to authentication, while a timeout suggests network instability or server-side latency.
If the browser shows a generic failure, open developer tools and inspect the network request for details.
- Look at the HTTP status code.
- Check response headers and error body text.
- Record the exact time of the failure.
- Note whether the issue is repeatable or intermittent.
For developers, logs are essential.
A single captured request can reveal whether the request never left the device, whether a proxy altered it, or whether HIBP rejected it after receipt.
Network, DNS, and firewall checks
Network infrastructure is a common but overlooked source of HIBP problems.
DNS resolution failures, TLS inspection, and restrictive outbound rules can all create errors that look like application bugs.
- Run a DNS lookup for the HIBP domain.
- Test the API endpoint with curl from the affected machine.
- Check whether a proxy rewrites certificates or headers.
- Verify outbound HTTPS traffic is permitted on port 443.
In enterprise environments, security appliances may flag breach-checking traffic as privacy-sensitive.
If you manage a corporate network, document the HIBP domain and API usage so it can be allowed explicitly when appropriate.
When the issue is on your code side
If you are building an application around HIBP, compare working and failing requests side by side.
Small implementation issues often cause repeated failures that are easy to miss during development.
- Check for incorrect base URLs in staging versus production.
- Confirm headers are not being stripped by a reverse proxy.
- Ensure retry logic does not create accidental request storms.
- Validate JSON parsing and error handling paths.
Strong logging, request tracing, and environment-specific configuration files make HIBP troubleshooting much easier.
If the same code works in a local test but fails in production, compare outbound firewall rules, secret values, and service accounts.
Best practices to prevent recurring errors
Preventing future problems is usually easier than reacting to them.
A few operational habits can make HIBP usage more stable and predictable.
- Store API keys securely and rotate them on a schedule.
- Use caching to reduce duplicate queries.
- Monitor for 401, 403, 429, and 5xx responses.
- Document the exact endpoint and version your application uses.
- Test integrations after browser, firewall, or dependency updates.
For teams, create a short runbook that lists the most common HIBP errors, the expected status codes, and the first checks to run.
That turns a vague outage into a routine diagnostic process.