HTTP
RFC 9457 Problem Details Validator
Validate syntax and standard member types, compare the advisory body status with an optional HTTP status, and identify extension members.
How this tool works
Problem Details provides a standard container for machine-readable HTTP API error information. The standard members describe a problem type, human summary, advisory status, occurrence detail, and instance reference.
The HTTP response status remains authoritative to generic HTTP software. When the optional body status is present, producers should keep it consistent with the actual response.
Examples
- Validate an about:blank 404 response.
- Warn when body status differs from the supplied HTTP status.
- List an application extension such as balance or errors.
Common use cases
Privacy and error design
Problem details should help a client correct the request without disclosing stack traces, SQL, filesystem paths, internal hostnames, or secrets. Structured extensions are more dependable than parsing human detail text.
Validator limits
- No network request is made to type or instance URIs.
- Registered and application-specific problem types are not fetched.
- Extension members are listed but not semantically validated.
- The surrounding Content-Type and real HTTP status must be checked separately.
Failure case: Problem Details
Invalid/failure example
List an application extension such as balance or errors.
Expected: The HTTP response status remains authoritative to generic HTTP software. When the optional body status is present, producers should keep it consistent with the actual response.
Related guides
Official references
FAQ
Does this tool send the pasted data or execute an API request?
No. Analysis runs in this browser tab. The tool does not call pasted URLs, resolve remote references, or submit the input to a DevPouch processing endpoint.
Are type, title, status, detail, and instance all required?
No. RFC 9457 defines their semantics when present. The type defaults to about:blank when absent; applications can impose stronger profiles.
Does this validate my application error contract?
Only the basic Problem Details shape. Extension semantics, problem-type documentation, localization, authorization, and application-specific requirements need separate tests.