What is a JWT?

A JSON Web Token, or JWT, is a compact format for carrying claims between systems. A token can be signed, encrypted, or both, depending on how it is constructed. Many familiar JWTs are signed but not encrypted, which means their contents are readable by anyone who obtains the token. Decoding reveals data; it does not verify who issued it, whether it was altered, or whether an application should trust it.

Read the familiar three-part format

A compact signed JWT commonly appears as three Base64url-encoded segments separated by periods: a header, a payload, and a signature. The header names the token type and an algorithm identifier. The payload contains claims, which are statements such as an issuer, subject, audience, or expiry time. The signature covers the encoded header and payload according to the signing format and key used by the issuer.

Base64url is an encoding, not encryption. It represents bytes with a URL-friendly alphabet; decoding the first two segments usually turns them back into JSON. That is why a signed token can look like a string of gibberish yet reveal an email address, role, or other claim when inspected. Treat a token as potentially readable unless it is explicitly an encrypted JWT and you understand how that encryption is handled.

Separate signed tokens from encrypted tokens

A JSON Web Signature provides integrity protection: a verifier can check whether the signed content matches the key and algorithm it expects. A signature does not hide the payload. A JSON Web Encryption object is a different format for confidentiality, with distinct segments and cryptographic processing. Some systems combine these formats, but the exact construction matters and should be specified by the protocol that issued the token.

Do not infer encryption from the fact that a JWT contains a signature or is sent over HTTPS. HTTPS protects the token while it travels over that connection; after it reaches a system, that system can read it. A signature helps a properly configured verifier detect tampering, but only if it selects an allowed algorithm, obtains the right key, and validates the claims needed for its use. Each step is part of the trust decision.

Understand what the claims say

Common registered claims include iss for issuer, sub for subject, aud for audience, exp for expiration time, nbf for a not-before time, and iat for issued-at time. These names have defined meanings in the JWT standard, but their presence does not make a claim true by itself. An application must decide which claims are required and compare them with expected values, such as the identity provider, service, user, and current time.

A payload can also contain application-specific claims, including permissions or profile details. A readable value such as role equals administrator is not proof that the token came from an administrator. The application must verify the token's cryptographic protection and its policy before using such data to authorize an action. Never let a browser-side display or a decoder's pretty-printed output substitute for backend verification.

Treat decoding and verification as different operations

A decoder splits the text, converts encoded bytes back into JSON, and may display recognizable fields. It generally does not need the signing key. A verifier checks the signature or authenticated encryption and then applies application rules. That distinction matters when reviewing a token: a tool that can decode a payload is useful for inspection, but it cannot establish that the token is genuine or acceptable to a server.

SafeStack's JWT Decoder displays the header and payload and can report an expiry field's time interpretation. It does not verify the signature, issuer, audience, allowed algorithm, or account status. Use it with an expired or fictional sample for learning. Do not paste an active access token into an online decoder; the token may be a bearer credential that grants access to whoever holds it, even if you are only trying to understand its fields.

Verify the algorithm, key, and issuer

A verifier should choose an explicit set of algorithms that it is willing to accept and reject tokens outside that set. It should not blindly trust the algorithm name supplied inside an untrusted header. The signing key must be appropriate for the chosen algorithm and associated with the issuer the application trusts. Key selection and rotation are part of the protocol, so implementers should use a maintained library and follow the identity system's published rules.

RFC 8725's best-current-practice guidance emphasizes algorithm verification and issuer validation. When a token can be presented to more than one application, audience handling matters too: a token intended for one service should not automatically be accepted by another. Applications should reject missing, unexpected, expired, or otherwise invalid claims according to their own protocol. A valid signature alone is not a complete authorization decision.

Check time claims with care

JWT time claims are usually numeric dates measured in seconds since the Unix epoch. A tool may translate exp into a date so a person can read it, but that display can be misleading if the input has the wrong type, the system clock is inaccurate, or the application applies a small clock-skew allowance. A decoder's date output does not account for the server's full policy or prove that the token has not been revoked.

The application should validate any time claims that its protocol requires and compare them against a trustworthy clock. It should also consider token lifetime, refresh behavior, and the consequences of accepting a token after a user signs out or loses access. Expiration reduces the window in which a stolen token can be reused, but a still-valid bearer token remains sensitive until it expires or the system otherwise rejects it.

Protect tokens like temporary passwords

An access token can authorize requests without asking for the account password again. Keep it out of screenshots, public issue trackers, analytics events, shared logs, and messages. Avoid sending a live token to a website that offers to decode it. If a token has been exposed, follow the issuer's procedure to revoke or replace it, sign out affected sessions where possible, and review the activity associated with the account.

Token storage also depends on the application architecture. Browser storage choices involve tradeoffs among cross-site request risks, script access, session behavior, and usability. There is no storage location that makes a token safe regardless of the surrounding code. Follow the identity provider's current guidance, use short-lived tokens where suitable, and let a server-side library handle validation rather than writing security checks from a visual example.

Quick checklist

• Assume a signed JWT payload is readable unless it is specifically encrypted.
• Treat decoding and signature verification as separate operations.
• Validate algorithm, signature, issuer, audience, and time claims in the application.
• Keep live tokens out of screenshots, chats, logs, and public reports.

Try it locally

Use these related utilities to turn the note into a practical workflow.

• JWT Decoder
• Base64 Encoder

Learn how this material is prepared in the SafeStack Editorial Policy.