FuntranslatorCreate Fun Language Translations
Free

JWT Decode Online

Decode a JSON Web Token to inspect its header and payload. The tool runs in your browser. Decoding does not verify a JWT signature, validate its claims, or tell you whether an issuer is trustworthy.

Decode a JWT

Paste a compact JWT to decode its header and payload locally in this browser. The token is not sent to a server.

Decoding only reveals encoded data. It does not authenticate the token or verify its signature.

What JWT decoding shows

A JSON Web Token (JWT) is commonly represented as three text segments separated by periods. In a compact signed JWT, the first segment contains a JSON header, the second contains a JSON payload, and the third contains a signature. The header and payload are encoded with Base64URL, a URL-safe variant of Base64. This decoder reverses that encoding and formats the JSON so you can inspect the values.

Base64URL encoding is not encryption. Anyone who obtains a typical signed JWT can decode its header and payload without the signing key. Treat tokens as credentials: do not publish them, paste production tokens into untrusted services, or place passwords and private keys in claims. This page processes the text in your browser and does not submit it to a server.

How to decode a JWT

  1. Copy the complete compact token from a trusted source and paste it into the decoder above.
  2. Select Decode JWT. The tool checks for three segments and parses the first two as JSON objects.
  3. Review the header fields, such as alg and optional kid, and read the payload claims.
  4. Use the displayed signature segment only as encoded data. This tool does not validate that signature.
  5. Clear the token from the page when you finish, especially on a shared device.

A token may fail to decode if it was copied incompletely, contains spaces inside a segment, uses a different token format, or does not contain JSON in its first two parts. The decoder intentionally reports parsing errors rather than guessing at malformed input.

Decode, validate, and verify are different operations

Decoding answers “what data is represented here?” It does not answer “who created this token?” or “may this application accept it?” A valid-looking payload can be edited by an attacker; only a verifier that checks the signature with a trusted key and expected algorithm can detect that change. After signature verification, applications should also enforce the expected issuer and audience, check exp and nbf, and apply their own authorization rules.

The alg value is untrusted input until verification has succeeded. A server should choose allowed algorithms from its own configuration rather than letting a token choose arbitrary verification behavior. Do not use a successful decode as evidence that a JWT is safe, signed, current, or intended for your service.

Understanding common JWT claims

The payload can include registered claims and application-specific values. iss identifies an issuer, sub describes the subject, and aud identifies intended recipients. exp is an expiration time; nbf means a token must not be accepted before a specified time; and iat records when it was issued. These fields are only data until a trusted verifier applies the correct policy.

Do not assume every token contains every registered claim, or that a claim is trustworthy simply because it appears in the payload. The issuer and verifier must agree on the token profile. Keep payloads minimal because JWT claims are usually readable by the token holder, even when the token is signed.

When to use another JWT tool

Use the JWT Validator to inspect token structure and selected time claims; it does not perform cryptographic signature verification. Use the JWT Encoder to create a test token, or the JWT Header and Payload Formatter to work with JWT JSON. For standalone Base64 data, try the Base64 encoder and decoder. Our JWT documentation and FAQ explain token formats and safe handling in more detail. Review the privacy policy before using any online tool with sensitive data.

JWT Decoder FAQ

What does a JWT decoder do?

A JWT decoder splits a compact JSON Web Token into its header, payload, and signature segments. It Base64URL-decodes the first two segments so you can read their JSON values. It does not prove the token is authentic.

Can decoding a JWT verify its signature?

No. Decoding is a reversible text operation. Signature verification requires the correct cryptographic algorithm and trusted key, plus application-specific checks. This decoder only displays the encoded signature segment.

Does this JWT decoder send my token to a server?

No. The decoder uses browser APIs to decode the header and payload. The token is not submitted to a server by this tool. Avoid pasting live credentials into any website unless your security policy allows it.

What are the three parts of a JWT?

A compact signed JWT has a Base64URL-encoded header, a Base64URL-encoded payload, and a signature, separated by periods. The first two parts are readable after decoding; the signature is binary data represented as Base64URL text.

Why does the decoded payload contain user information?

JWT payloads contain claims chosen by the issuer, such as a subject, audience, issuer, or expiration time. A signed JWT is generally readable by anyone who has it, so do not put passwords, private keys, or other secrets in its payload.

What does the exp claim mean?

The exp claim is a NumericDate expiration time measured in seconds since the Unix epoch. A verifier should reject a token after its expiration, allowing only any small clock-skew tolerance defined by the application.

What if a JWT decoder reports malformed data?

Check that the input has three period-separated segments and that the header and payload contain valid Base64URL-encoded JSON objects. Whitespace, a truncated copy, or a token from a different format can cause decoding to fail.

How can I validate a JWT after decoding it?

Use a trusted server-side JWT library to verify the signature with an expected algorithm and trusted key. Then validate issuer, audience, expiration, not-before time, and application-specific claims. Do not trust a token just because its JSON can be decoded.