Developer tools How-to guides
How to decode a JWT—and why decoding does not verify it
Inspect a JWT header and payload, understand common claims, and distinguish readable token data from signature verification and authorization.
When an API rejects a request, looking inside its token can reveal the intended audience or an expired timestamp. That is a debugging step, not an authorization decision. Keep the two operations separate so useful inspection does not turn into misplaced trust.
Recognize the token format
A common signed JWT in compact form has three dot-separated parts: a header, a payload and a signature. The first two encode JSON using Base64url. JWTs can also use encrypted forms; do not assume every token is a readable three-part signed token. RFC 7519 defines JWT claims and their representation.
header.payload.signature
Example decoded payload, using fictional values:
{
"sub": "demo-user",
"aud": "example-api",
"exp": 2000000000
}Inspect only what you need
Open ToolBarKit’s JWT decoder and paste a token or Bearer token value. Decoding happens in your browser; the decoder does not verify the signature. For a tutorial or screenshot, use a synthetic sample rather than a production access token.
Keep real tokens out of public tickets, chat transcripts and shared screenshots. If you need to record a debugging finding, write down the relevant claim and redact identifiers instead of saving the entire credential. A token’s readable appearance does not make sharing it harmless.
Read the claims as untrusted debugging information
Common claims include iss for issuer, aud for audience, exp for expiration and nbf for the earliest acceptance time. JWT time claims use seconds since the Unix epoch, not milliseconds. Their presence and required validation depend on the application.
Auth0’s API documentation illustrates checking audience, issuer and expiration alongside token validation. Your backend should use an appropriate maintained verification library and its configured trust rules. Do not choose a trusted key or algorithm solely because an unverified header requests it.
Sources: RFC 7519: JSON Web Token claims and formats · Auth0: API token validation and troubleshooting
Turn the inspection into a concrete debugging check
Compare the decoded audience with the API configuration, then inspect the time-related claims and issuer. Confirm you are sending the intended token type and the expected Authorization header. A mismatch is a useful lead; fixing it still requires obtaining a valid token through the application’s normal authentication flow.
If the decoder reports malformed data, check for copy-paste truncation or accidental spaces. An opaque access token or encrypted token may simply be unsuitable for this decoder. Never repair a credential by editing its payload and assuming the modified token should work.
Common questions
Does decoding prove the signature is valid?
No. ToolBarKit only reads the token’s header and payload. Signature verification and application-specific claim checks must happen in the system deciding whether to trust it.
Are signed JWT payloads secret?
A signed token’s payload is normally readable by whoever holds the token. Signing and encryption serve different purposes; JWT also supports encrypted forms.
Sources and further reading
This guide combines the linked references with examples and the current behavior of ToolBarKit’s tools. Published by the ToolBarKit team; external guidance and tool behavior can change.