What a JWT contains
A JSON Web Token is a compact representation of claims. In the familiar signed compact form it has three segments separated by periods:
header.payload.signature
The header and payload are JSON encoded with Base64URL. The final segment contains a digital signature or message authentication code for signed JWTs. Decoding the first two segments reveals their text; it does not establish that the text came from a trusted issuer.
JWT is a format, not an authentication system by itself. Security depends on how an application creates, validates, transports, stores, and revokes tokens.
Base64URL is readable encoding
Base64URL represents bytes using text characters that are convenient inside URLs. It replaces plus and slash from standard Base64 with minus and underscore and commonly omits equals-sign padding.
Encoding is reversible and has no secret key. Anyone who receives a compact JWT can decode its header and payload. A signed token protects against undetected modification when verification is correct, but it does not hide the claims.
Do not put passwords, private keys, or unnecessary personal data in a signed JWT payload. Encryption is a separate JOSE construction called JWE, and even encrypted tokens require careful validation.
The protected header
The header describes how the token is secured. Common parameters include alg for algorithm, typ for media type, and kid for a key identifier.
{
"alg": "RS256",
"typ": "JWT",
"kid": "key-2026-08"
}
These values are controlled by whoever produced or altered the token until the signature is verified. A verifier must not accept any algorithm merely because the header requests it. Allowed algorithms belong in trusted application configuration.
The key identifier helps select a candidate verification key. It is not proof that the key is trusted and must not be used unsafely in a file path, database query, or remote request.
The claims payload
The payload is a JSON object containing claims. Registered claims defined by RFC 7519 include issuer (iss), subject (sub), audience (aud), expiration (exp), not-before time (nbf), issued-at time (iat), and token identifier (jti).
Applications can define private claims, but names should avoid collisions. A claim’s meaning comes from the issuer and application agreement, not from the decoder.
Seeing admin: true in a payload proves nothing before verification. An attacker can create a new payload containing that text. Authorization code must validate the token and then apply current server-side policy.
NumericDate time claims
JWT time claims use NumericDate: seconds since 1970-01-01T00:00:00Z, ignoring leap seconds. They are not milliseconds. Treating seconds as milliseconds produces a date near January 1970; treating milliseconds as seconds produces a date far in the future.
exp marks the time on or after which a token must not be accepted. nbf marks the time before which it must not be accepted. iat records when the token was issued but does not by itself impose an expiry.
Implementations often allow a small clock-skew tolerance because servers are not perfectly synchronized. The allowed leeway should be limited and configured by the verifier, not read from an untrusted claim.
Decoding versus verification
Decoding answers: “What bytes and JSON are present?” Verification answers: “Was this token protected by a trusted key under an allowed algorithm, and does it satisfy policy?”
A proper verifier normally checks all of the following:
- The cryptographic signature or authentication tag is valid.
- The algorithm is explicitly allowed for this token type.
- The key is trusted for the claimed issuer and use.
- The issuer matches the expected issuer.
- The audience includes the receiving service.
- Required time claims are present and acceptable.
- The token type and application-specific claims match the context.
This browser tool has no trusted application key or expected policy, so it deliberately does not claim verification.
Signature algorithms
HS256 uses HMAC with SHA-256 and a shared secret. Every party able to verify with that secret can also create tokens, so secret distribution matters.
RS256 uses RSA with SHA-256. An issuer signs with a private key and verifiers use the public key. ES256 uses ECDSA on the P-256 curve, and EdDSA may use Edwards-curve signatures when supported.
Algorithm names do not make a token secure automatically. Key size, library behavior, key origin, algorithm confusion, and policy configuration matter. RFC 8725 documents common JWT failure modes and current best practices.
The alg none problem
JWT supports an unsecured form using alg: none in narrowly defined circumstances. Historically, vulnerable libraries accepted a token after an attacker changed a signed algorithm to none and removed the signature.
The general lesson is broader: the token must not choose its own trust policy. A service expecting RS256 should configure RS256 and reject HS256, none, or any other unexpected algorithm before using claims.
A decoder can display the algorithm header to help debugging, but that display is not approval. Even a familiar algorithm label is untrusted until cryptographic verification completes.
Issuer and audience
The issuer identifies the authority that created the token. A verifier should compare it with an exact expected value and use keys belonging to that issuer.
The audience identifies intended recipients. A token issued for one API should not automatically work at another. Accepting a valid signature without checking audience can allow a token from one context to be replayed in a more privileged context.
String comparison and normalization rules should follow the application and relevant specifications. Loose substring matching can accept unintended values.
Token storage and transport
JWT bearer tokens act like credentials: possession may be enough to call an API. They should travel over HTTPS and should not appear in public logs, analytics, screenshots, support tickets, or source control.
Putting tokens in URLs is particularly risky because URLs can enter browser history, referrer data, proxy logs, and copied links. Authorization headers or appropriately protected cookies are normally safer transport mechanisms depending on the application architecture.
Browser storage involves tradeoffs. JavaScript-readable storage is exposed to successful cross-site scripting. Cookies can reduce that exposure when configured with HttpOnly but require cross-site request protections and careful SameSite settings.
Expiration and revocation
Short expiration limits how long a stolen access token remains useful, but expiry is not immediate revocation. A token can remain cryptographically valid after a user signs out, changes a password, or loses a device.
Systems that need faster revocation can maintain server-side state, use short-lived access tokens with controlled refresh tokens, rotate keys, or check token identifiers against a revocation record. Each design changes availability and complexity.
A decoder showing “active by time claims” means only that the local clock is between optional nbf and exp values. It cannot know whether the token was revoked, whether the signature is valid, or whether the issuer and audience are correct.
JWT and JWE
A signed JWT commonly uses JWS compact serialization and has three segments. A JWE compact message has five segments representing protected header, encrypted key, initialization vector, ciphertext, and authentication tag.
Encryption hides claims from parties without the decryption key. It does not remove the need to validate algorithms, issuer, audience, time, and application semantics after decryption.
Some systems nest a signed JWT inside encryption. The order and validation policy must be explicit. This tool accepts only the common three-segment JWT form and does not decrypt JWE.
Debugging malformed tokens
A compact JWT must contain exactly two periods, creating three segments. The first two must be valid Base64URL and decode to valid UTF-8 JSON objects. Copying whitespace, truncating a segment, or using standard Base64 incorrectly can cause decoding errors.
Missing Base64 padding is normal in Base64URL and the decoder restores it. A signature segment is not decoded as JSON because it contains cryptographic bytes.
If the token decodes but an application rejects it, inspect the server’s validation error rather than assuming the payload is correct. Common causes include expired time, wrong audience, unexpected issuer, unknown key identifier, clock skew, or an algorithm mismatch.
A safe debugging workflow
Use a fabricated or redacted token whenever possible. Reproduce the header and non-sensitive claim shape without copying a live bearer credential. Keep real tokens out of chat, issue trackers, recordings, and shared screenshots.
Decode to inspect structure. Verify using the same maintained library and trusted configuration as the receiving application. Test negative cases: changed payload, wrong audience, expired token, future not-before time, wrong key, and disallowed algorithm.
Log a request correlation identifier rather than the full token. If limited claims must be logged, minimize and redact them according to the system’s data policy.
Limits of this decoder
The tool decodes three-segment compact JWTs whose header and payload are UTF-8 JSON. It displays algorithm and type claims and interprets numeric exp and nbf values against the browser clock.
It does not verify signatures, fetch keys, validate issuer or audience, decrypt JWE, determine revocation, or decide authorization. Its time-status label is informational and based on untrusted claims.
Use it to inspect a safe sample or debug token structure. Use a reviewed JOSE library with explicit trusted configuration for every security decision.