JWT::Decoder

// decode JWTs without sending data to a server

Security Notice

This tool works entirely in your browser. No data is sent to any server. Note that this tool only decodes JWTs, it does not verify signatures.

# JWT::Input
>

Usage Tips

  • Paste a JWT to automatically decode it - no server round-trip
  • Click the flask icon to load an example JWT
  • Switch between JSON and Table views for easier reading

How to Use This JWT Decoder

Step-by-step guide to decoding and verifying your JSON Web Tokens

This JWT decoder tool allows you to securely inspect and verify JSON Web Tokens (JWTs) without sending sensitive data to any server. Whether you're debugging authentication issues, developing JWT-based applications, or just learning about JWTs, this tool gives you a visual breakdown of token structure and validation capabilities.

The decoder supports token inspection, data extraction, and signature verification (currently supporting HS256 algorithm). All operations happen entirely in your browser - your tokens and secrets never leave your device, making it safe for security-sensitive work.

Decoding a JWT

  1. Enter your JWT: Paste your JWT into the input area on the right side of the screen. The token will be decoded automatically as soon as it's entered.
  2. View the results: The decoded header and payload will be displayed in the output section. You can toggle between JSON and Table views using the tabs.
  3. Expand claims: Click on the "Show Details" toggle to expand and collapse complex claims for better readability.

Tip: If you don't have a JWT handy, click the "Example" button to load a sample token for testing.

Verifying a Signature

  1. Enter your JWT: Make sure your JWT is pasted in the input area.
  2. Enter your secret key: Type your secret key in the verification section text box.
  3. Select the right format: Choose "UTF-8 Text" for plaintext secrets or "Base64" if your secret is Base64 encoded.
  4. Check results: The verification result will appear automatically, showing whether the signature is valid or invalid.

Working with the Results

  • Copy individual sections: Use the copy buttons next to the Header, Payload, or Signature sections to copy just that part.
  • Copy all data: Click the "Copy All Decoded Data" button at the bottom to copy the complete decoded information as JSON.
  • Expanded view: Click the expand button on any section to see the full content in a larger modal window.
  • Toggle dark mode: Click the sun/moon icon in the top right to switch between light and dark themes for better readability in different environments.

Common Issues and Troubleshooting

Invalid JWT Format

Make sure your JWT contains three parts separated by dots. A valid JWT looks like: xxxxx.yyyyy.zzzzz

Signature Verification Failed

Double-check that you're using the correct secret key and that you've selected the right secret format (UTF-8 or Base64).

Base64 Decoding Error

Ensure your JWT is correctly formatted without extra spaces or line breaks, especially if you copied it from a log file or email.

Security Note: This tool processes everything locally in your browser. Your tokens and secrets are never sent to any server, making it safe for handling sensitive authentication data.

Understanding JWT Tokens

Secure, compact, and self-contained tokens for information transmission

JSON Web Tokens (JWTs) are an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed using a secret key (with HMAC) or a public/private key pair using RSA or ECDSA.

Although JWTs can be encrypted to provide secrecy between parties, signed tokens focus on verifying the integrity of the claims within. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

When should you use JWTs?

  • Authorization: The most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources permitted with that token. Single Sign On is a feature that widely uses JWT because of its small overhead and its ability to be easily used across different domains.
  • Information Exchange: JWTs are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.

JWT Structure

A JWT consists of three parts separated by dots (.), which are:

  • Header: The header typically consists of two parts: the type of the token (JWT) and the signing algorithm being used, such as HMAC SHA256 or RSA. For example: {"alg": "HS256", "typ": "JWT"}. This is Base64Url encoded.
  • Payload: Contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims. This is also Base64Url encoded.
  • Signature: To create the signature part, you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that. For example, for HMAC SHA256: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret).

Types of JWT Claims

The payload portion of a JWT contains claims about the entity, typically the user and additional metadata:

  • Registered claims: These are predefined claims such as iss (issuer), exp (expiration time), sub (subject), aud (audience), and others. These claims are not mandatory but recommended to provide a set of useful, interoperable claims.
  • Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
  • Private claims: These are custom claims created to share information between parties that agree on using them and are neither registered nor public claims.

Security Note: For signed tokens, the information contained within the token is exposed to users or other parties, even though they are unable to change it. This means you should not put secret information within the token unless it is encrypted.

Frequently Asked Questions

Common questions about JWT tokens and this decoder

Is this JWT decoder secure?

Yes, this JWT decoder is designed with security in mind. All processing happens directly in your browser - no data is sent to our servers. Your tokens and private keys never leave your device, making it safe for handling sensitive information.

Since JWTs often contain authentication information, it's crucial that they're decoded securely. This tool uses your browser's built-in JavaScript capabilities to decode and verify tokens without external dependencies or server calls.

What's the difference between decoding and verifying a JWT?

Decoding a JWT involves converting the Base64URL encoded header and payload back into JSON, allowing you to read these parts. Anyone can decode a JWT without needing a key, as the data is only encoded, not encrypted.

Verifying a JWT involves checking the signature to ensure the token hasn't been altered and was created by a trusted source. This requires the secret key (for HMAC algorithms) or the public key (for RSA/ECDSA algorithms) that corresponds to the key used to sign the token.

This tool lets you do both: decode JWTs to inspect their contents and verify signatures to confirm their authenticity.

What algorithms are supported for verification?

Currently, this tool supports verification for:

  • HS256 (HMAC with SHA-256) - The most common algorithm using a shared secret key

Support for the following algorithms is planned for future updates:

  • RS256 (RSA Signature with SHA-256) - Uses a public/private key pair
  • ES256 (ECDSA Signature with SHA-256) - Uses a public/private key pair with elliptic curve
  • HS384/HS512 - HMAC with SHA-384/SHA-512
What's the difference between UTF-8 and Base64 secret formats?

When verifying JWT signatures with HMAC algorithms:

  • UTF-8 Text: Use this for plain text secrets (most common). The characters themselves are used directly as the secret key. For example, if your secret is "my-secret-key", those exact characters are used for verification.
  • Base64: Use this when your secret is binary data encoded as Base64. The tool will decode the Base64 string to binary before using it for verification. This is useful when your secret key was generated as random bytes and then encoded as Base64 for storage.

If your JWT was created with a text-based secret, use UTF-8. If it was created with a binary secret (that was likely encoded as Base64 for storage), use Base64.

How do JWTs work in authentication systems?

In authentication systems, JWTs typically work like this:

  1. The user logs in with their credentials (username/password).
  2. The server verifies the credentials and generates a JWT containing user identity information and permissions.
  3. The server sends this JWT to the client, which stores it (often in browser storage or a cookie).
  4. For subsequent requests, the client includes this JWT (typically in the Authorization header).
  5. The server verifies the JWT signature and uses the claims inside to identify the user and determine their access rights.

This approach allows for stateless authentication, where the server doesn't need to store session information - all necessary data is contained within the token itself.

Are there security considerations I should know about JWTs?

Yes, there are several important security considerations when working with JWTs:

  • Always validate the signature before trusting the content of a JWT
  • Check the expiration time (exp) claim to prevent using expired tokens
  • Verify the issuer (iss) and audience (aud) claims match your expected values
  • Use strong secret keys (at least 256 bits for HS256) or proper key management for asymmetric signatures
  • Be cautious about storing sensitive data in JWTs, as the payload is only encoded, not encrypted (unless using JWE)
  • Implement token revocation mechanisms for cases where tokens need to be invalidated before their expiration
  • Store tokens securely on the client side, and be aware of XSS vulnerabilities if storing in browser storage
  • Ensure your token validation library is up-to-date to protect against known vulnerabilities
How can I decode JWTs in my own applications?

To decode and verify JWTs in your own applications, you can use libraries available for most programming languages:

  • JavaScript: jsonwebtoken (Node.js), jose, or auth0/jwt-decode (browser)
  • Python: PyJWT or python-jose
  • Java: java-jwt, JJWT, or Nimbus JOSE+JWT
  • C#/.NET: System.IdentityModel.Tokens.Jwt or Microsoft.AspNetCore.Authentication.JwtBearer
  • Go: golang-jwt/jwt or lestrrat-go/jwx
  • PHP: firebase/php-jwt or lcobucci/jwt
  • Ruby: jwt gem

Most JWT libraries provide functions to both decode JWTs (read their contents without verification) and verify JWTs (check their signatures to confirm authenticity).

For quick debugging and exploration, you can always use this online tool without installing any dependencies.