API Error & Problem Details Inspector
Decode raw API JSON error responses, identify standard error schemas (RFC 9457, RFC 7807, OAuth 2.0, Stripe, FastAPI/Pydantic), extract culprit fields, and convert custom errors into normalized Problem Details.
RFC 9457 & Modern API Error Design Standards
In modern HTTP API design, unstandardized error formats (such as arbitrary { "err": "msg" } dictionaries or raw stack traces) lead to fragile client implementations and painful debugging. RFC 9457 (which obsoletes RFC 7807) defines a standardized, machine-readable format for conveying problem details using the application/problem+json media type.
1. RFC 9457 Core Problem Fields
A standard problem object provides five core members:
type: A URI reference identifying the problem type.title: A short, human-readable summary of the problem type (static).status: The HTTP status code generated by the origin server.detail: A human-readable explanation specific to this occurrence.instance: A URI reference identifying the specific occurrence of the problem.
2. OAuth 2.0 Error Format (RFC 6749)
Authorization and Token endpoints return specific error parameters defined in RFC 6749 §5.2:
error: ASCII error code (e.g.,invalid_request,invalid_client,invalid_grant).error_description: Human-readable UTF-8 diagnostic text.error_uri: URI identifying a human-readable web page with error information.
3. Validation & Extension Members
APIs may extend the problem object with custom members (e.g., invalid-params in RFC 9457 or loc in FastAPI/Pydantic). These members communicate pinpoint field paths and validation constraints directly to frontend client forms.
4. Security: Safe Error Handling
Never leak raw database stack traces, SQL syntax strings, internal IP addresses, or framework exceptions in production error payloads. All production errors should conform to a strict public schema with sensitive debug metadata stripped out.
Frequently Asked Questions
What is the difference between RFC 7807 and RFC 9457?
RFC 9457 (published in 2023) is the direct successor and standard replacement for RFC 7807. It clarifies URI resolution rules for the type and instance members, clarifies registry usage, and emphasizes best practices for client parsing and extension members without breaking backwards compatibility.
Why should my API use application/problem+json instead of application/json?
Using Content-Type: application/problem+json allows API gateways, reverse proxies, and client SDKs to immediately recognize and deserialize standard error payloads predictably across all endpoints, eliminating custom error-handling wrappers.
Is my payload data kept private when using this tool?
Yes, 100%. HTTPLens executes all parsing and validation entirely inside your browser's JavaScript runtime memory. No payload text, error details, internal paths, or API parameters are ever logged, tracked, or transmitted over the network.