Skip to content

DPoP Proof JWT Inspector

Decode and verify DPoP proof JWTs, compare HTTP method, target URI, nonce, access-token hash, and embedded public-key binding without contacting a server.

Local input limit: 1 MB · Processing timeout: 8 s
How can I verify this?

Open your browser DevTools and the Network panel, optionally clear existing requests, then run the tool. Page assets or consent-based analytics may still load, but tool payloads, files, keys, and results are not sent for processing.

Inspect a DPoP proof

The proof and optional request context are processed in a disposable browser worker. Access tokens are used only to calculate ath and optional cnf.jkt comparisons and are not included in the result.

Request context (optional)

Add only the values available from the request. Empty context fields remain not compared rather than being treated as matches.

DPoP proof analysis

Signature verification, public-key thumbprint, decoded claims, and independent request-context comparisons will appear here.

Debug proof-of-possession checks separately

DecodeLens verifies the compact JWS with its embedded public JWK, calculates the RFC 7638 thumbprint and access-token hash, and keeps every supplied comparison as an independent result.

DPoP verification boundaries

  • ES256, RS256, and PS256 verification is supported with the public JWK embedded in the proof. none, MAC algorithms, private JWK parameters, and unsupported algorithms are never accepted as verified.
  • htu comparison removes query and fragment from the supplied request URL and applies URI syntax/scheme normalization. HTTP method comparison remains case-sensitive.
  • The five-minute iat window is a local debugging policy, not a statement about a particular server's acceptance policy.
  • The access token stays in memory and is used only for SHA-256 ath and an available JWT cnf.jkt comparison. Its claims, signature, expiry, issuer, audience, and authorization are not validated.
  • No endpoint, jwk URL, issuer, token, or nonce service is requested. Replay detection requires server-side jti state and is not performed here.

Related tools for this workflow

Continue with tools that decode, convert, inspect, or verify the same data.

Inspect a protected-resource DPoP request

Load the RFC example to verify its ES256 signature, compare GET and the query-free target URI, reproduce ath from the opaque access token, and review why the historical iat is outside today's local window.

DPoP request context

DPoP: eyJ0eXAiOiJkcG9wK2p3dC…
Authorization: DPoP Kz~8mXK1…

Independent proof checks

signature: verified · htm: match · htu: match · ath: match · replay: not checked

DPoP Proof Inspector FAQ

Does a verified DPoP signature mean the request is accepted?

No. It proves only that the compact JWS matches the embedded public key. The receiving server still applies time, replay, nonce, token-binding, token-validity, and authorization policy.

Why is the URL query ignored for htu?

RFC 9449 defines htu as the HTTP target URI without query and fragment. The supplied request URL is normalized to that comparison form.

Is my access token decoded or stored?

It is held only in the current page and worker memory. DecodeLens calculates ath and, if it is JWT-shaped, reads only cnf.jkt for the optional key-binding comparison; the token is not returned or persisted.