API Error Response Formatter

Parse JSON API errors or raw HTTP responses into readable fields, validation details, and shareable summaries.

API Error Response

Paste a raw HTTP error response or JSON error body copied from logs, API clients, browser DevTools, support tickets, or backend debugging.

Formatting Options

Input Type

Output Type

Mask trace identifiersReplace request, trace, and correlation ID fields in generated output. Other secrets are not automatically removed.Compact clean JSONUse compact JSON output instead of indented clean JSON.

Output

Formatted API error output will appear here.

Parsing happens in this browser session. The page does not send the pasted response to an API, but copied logs can still contain credentials, personal data, internal URLs, or other sensitive values.

Read the Error Shape Before Chasing the Stack Trace

APIs do not share one universal error schema. Some return a flat object with message and code; others nest an error object or attach field-level validation arrays. The formatter looks for those common shapes and labels what it finds, but the extraction is heuristic rather than schema validation.

A field called code is not automatically treated as an HTTP status. HTTP status extraction accepts only numeric 100–599 values from status-oriented fields, which avoids turning application codes such asVALIDATION_FAILED into a fake HTTP status.

Raw HTTP Response or JSON Body?

Raw HTTP mode expects a status line, header lines, a blank line, then a JSON body. JSON mode expects only the body. Header names and values are shown separately so transport metadata is not confused with fields inside the JSON.

The raw parser is intentionally a textual debugging parser, not a packet decoder. It does not decode chunked transfer coding, decompress content encodings, follow redirects, or reconstruct binary bodies.

RFC 9457 Problem Details

When an object contains the standard Problem Details members such as type, title,status, detail, and instance, the formatter identifies that shape separately. RFC 9457 defines application/problem+json for interoperable HTTP API errors and allows extension members for application-specific information.

See the RFC 9457 specificationfor the Problem Details model and RFC 9110for HTTP status and field semantics.

Validation Arrays and Trace Identifiers

Validation details are discovered from familiar keys such as errors, details,violations, and validationErrors. A custom API can use completely different names, so a zero count means “not recognized by these heuristics,” not “the response contains no validation information.”

Request IDs, trace IDs, and correlation IDs can be masked in generated output. That masking is deliberately narrow: it does not promise to detect access tokens, cookies, email addresses, database values, or secrets hidden under custom keys.

Before Sharing an Error Response

Keep the HTTP status and application error code; they answer different questions.
Preserve a trace ID when the recipient needs to correlate the failure with backend logs.
Remove credentials, cookies, personal data, private URLs, and production identifiers before posting publicly.
Do not treat a formatted response as proof of the root cause; server logs and API documentation still decide semantics.