JWT Decoder

Structure and Composition of a JSON Web Token

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The structure of a JWT consists of three distinct parts separated by dots (.). These three components are:

• Header: Contains metadata about the token, such as the cryptographic algorithm used to secure it and the token type.
• Payload: Contains the claims, which are statements about an entity (typically, the user) and additional data.
• Signature: Created by signing the encoded header and payload with a secret key or a public/private key pair to ensure the integrity of the token.

Because the token must be easily transmitted via HTTP headers and URLs, each of these three parts is encoded using Base64URL encoding. This encoding scheme replaces standard Base64 characters like + and / with - and _ respectively, and omits padding characters (=) to prevent transmission issues in web environments.

Decoding the JWT Header and Payload

The header of a JWT is a JSON object that defines how the token should be processed. It typically contains two primary claims:

• alg: The cryptographic algorithm used to secure the token, such as HS256 or RS256.
• typ: The type of token, which is commonly set to JWT.

The payload contains the actual claims or data transmitted between systems. Claims are categorized as registered, public, or private. Registered claims are predefined, recommended claims that provide useful, interoperable metadata. Common registered claims include:

• iat (Issued At): The Unix epoch timestamp indicating when the token was generated.
• exp (Expiration Time): The Unix epoch timestamp after which the token must not be accepted for processing.

The JWT Decoder extracts these JSON objects from their Base64URL-encoded format and displays them as formatted JSON.

Token Expiration and Validity Status

The lifetime of a JWT is managed through specific timestamp claims embedded within the payload. The decoder reads these claims to determine the current status of the token relative to the system clock.

The tool evaluates the exp (Expiration Time) and iat (Issued At) claims to assign one of the following status badges:

• Valid: The current time is after the issued time and before the expiration time.
• Expired: The current time has passed the timestamp defined in the exp claim.
• Not yet valid: The current time is earlier than the time specified in the token's activation or issued claims.
• No expiry: The payload does not contain an exp claim.

This evaluation relies solely on the temporal claims present in the payload and does not confirm whether the token has been revoked by the issuing authority.

Decoding Versus Verification

There is a fundamental difference between decoding a JWT and verifying it.

Decoding is the simple process of reversing the Base64URL encoding to reveal the plaintext JSON structure of the header and payload. Anyone who intercepts a JWT can decode and read its contents.

Verification, on the other hand, is the process of mathematically proving that the token has not been altered since it was issued. This requires verifying the signature using either a shared secret key (for symmetric algorithms) or a public key (for asymmetric algorithms).

This tool only decodes the header and payload. It does not verify the signature, nor does it ask for a signing secret or public key. Relying on decoded data without verifying the signature in a production environment introduces severe security risks, as malicious actors can easily modify the payload claims (such as user roles or identifiers) and re-encode the token.

Browser-Based Processing and Privacy

When working with sensitive authentication tokens, data privacy is a critical consideration. This tool processes all inputs locally. The decoding of the Base64URL strings and the parsing of the JSON structures happen entirely within your browser. No token data is uploaded to BroBroGo servers.

Troubleshooting Input Errors and Validation Rules

To successfully decode a token, the input must conform to strict formatting rules. If the input does not meet these criteria, the tool hides the decoded areas and displays specific error messages:

• Format Validation: The input must consist of three dot-separated parts. If this structure is missing, the tool displays: Not a valid JWT — expected three dot-separated parts.
• Length Validation: If the input string is excessively long, the tool displays: That's too long to be a real JWT.
• Base64URL Decoding: If the header or payload cannot be decoded due to malformed Base64URL characters, the tool displays Couldn't decode the header — invalid Base64URL or Couldn't decode the payload — invalid Base64URL.
• JSON Parsing: If the decoded bytes do not form valid JSON, the tool displays The header isn't valid JSON or The payload isn't valid JSON.

When the input field is cleared, the tool returns to its default state and focus is automatically restored to the input field.

Frequently Asked Questions

Is it safe to paste my JWT here?

Yes. Decoding happens entirely in your browser — your token is never sent to BroBroGo.

Does this verify the signature?

No. It only decodes the header and payload for you to read. Verifying a signature needs the signing secret or public key, which this tool never asks for.

How do I know if my token has expired?

The decoder reads the exp claim and shows a status badge — valid, expired, not yet valid, or no expiry — next to the decoded token.