JWT decoder online, decode and inspect tokens without sending them anywhere

Need to inspect what's inside a JWT? Use ToolHQ's free JWT decoder to decode and read any JSON Web Token right in your browser -- your token is never sent to any server.

ToolHQ's JWT decoder is a free browser-based tool that decodes and displays the header, payload, and signature structure of any JSON Web Token, with your token processed entirely in the browser and never transmitted anywhere.

JWTs are the authentication tokens that power login sessions and API access for millions of applications. Being able to inspect their contents quickly -- without sending a token to a third-party service -- is an essential developer skill. This tool makes it instant and private.

Key Takeaways

• Your token is never sent to any server -- decoding happens entirely in your browser using JavaScript
• Displays the JWT header, payload, and signature in readable JSON format
• Decodes base64url encoding and shows all claims including iss, sub, exp, iat, and custom claims
• Does not verify the signature (verification requires the secret key) -- shows structure only
• Free with no login and no rate limits

---

What is a JWT and how does decoding work?

JWT stands for JSON Web Token. It's a compact, URL-safe way to represent claims (data assertions) between two parties, defined in RFC 7519. JWTs are widely used for:

• Authentication: proving a user is logged in to an API
• Authorization: specifying what resources a user can access
• Secure information exchange between services

A JWT consists of three Base64URL-encoded parts, separated by dots:

1. Header: Contains the token type (typ: "JWT") and the signing algorithm (e.g., alg: "HS256" or "RS256")
2. Payload: Contains claims -- data about the user and token metadata. Standard claims include sub (subject/user ID), iss (issuer), exp (expiration time), and iat (issued at time)
3. Signature: A cryptographic signature used to verify the token hasn't been tampered with

Decoding a JWT means reversing the Base64URL encoding to read the JSON content of the header and payload. This is trivially easy -- JWT data is encoded, not encrypted. Anyone with the token can read its contents. The security of JWT comes entirely from the signature: only the server with the secret key can create a valid signature, so a decoded token cannot be forged.

According to RFC 7519, the JWT specification was published by the IETF in 2015 and defines the structure and processing rules for JSON Web Tokens. The Wikipedia article on JSON Web Token explains that JWTs are one of the most common formats for OAuth 2.0 and OpenID Connect tokens in modern web applications.

---

Why token privacy matters when decoding JWTs

Many online JWT decoders send your token to their server to decode it. This creates a significant security risk.

JWT payloads often contain user IDs, email addresses, roles, permissions, and session data. While pasting a test token is harmless, pasting a real user's session token into a third-party service is a serious security and privacy concern. If that token is still valid (not expired), the third party could potentially use it to impersonate the user.

ToolHQ's JWT decoder performs the Base64URL decoding using JavaScript running in your browser. Your token is never transmitted. The server never sees it.

Your token is never sent to any server. This is the critical difference between this tool and other online JWT decoders.

Mini-story: Hana is a 29-year-old backend developer debugging an authentication issue in a production API. A user reported being unable to access certain resources. Hana asked the user to send their JWT so she could check whether the correct roles were present in the payload. She pasted the token into ToolHQ's JWT decoder and immediately saw the problem: the user's role was set to "viewer" when it should have been "editor." The token had been issued before a role update. She triggered a token refresh and the issue resolved. She used a browser-based decoder specifically because she had promised the user their token would not be shared with any service.

Common situations where the JWT decoder is useful:

• Debugging authentication issues by reading the token claims
• Verifying that the correct user ID, email, or roles are present in a token
• Checking token expiration (exp claim) to diagnose session timeout issues
• Inspecting tokens during API integration development
• Understanding what a third-party service puts in its JWT tokens

Decode your JWT at ToolHQ

---

How to use the JWT decoder

1. Open ToolHQ's JWT decoder in your browser.
2. Paste your JWT token into the input field. A JWT looks like three long base64url strings separated by dots (xxxxx.yyyyy.zzzzz).
3. The tool decodes instantly. The header, payload, and signature sections appear immediately.
4. Read the payload claims. Standard claims to check: sub (user ID), exp (expiration as Unix timestamp), iss (issuer), iat (issued at), and any custom claims your app uses.

The tool does not verify the signature -- it does not have access to your signing secret. It shows you the decoded contents of the token as-is.

---

Understanding JWT claims

Once you decode a JWT, here's what the common fields mean:

• sub: Subject -- the user ID or entity the token represents
• iss: Issuer -- the service or server that created the token
• aud: Audience -- the intended recipient of the token (which service should accept it)
• exp: Expiration Time -- a Unix timestamp after which the token is no longer valid
• iat: Issued At -- a Unix timestamp when the token was created
• nbf: Not Before -- a Unix timestamp before which the token is not valid
• jti: JWT ID -- a unique identifier for this specific token (useful for revocation)

Any additional fields beyond these are custom claims specific to your application, such as role, email, org_id, or permissions.

Mini-story: Rodrigo, a 35-year-old API developer, was integrating a third-party SaaS platform's API. The platform issued JWTs on authentication, but the documentation was unclear about what claims were included. Rodrigo used the JWT decoder to inspect a real token from the platform and discovered it included a custom tenant_id claim that he needed to pass back in API requests. The decoder saved him an hour of reading through incomplete documentation.

For encoding data in Base64 (not specifically JWT-related), use ToolHQ's Base64 encoder. For formatting JSON payloads in your application, use the JSON formatter. Browse all developer tools in the ToolHQ developer category.

---

Frequently asked questions

Is my JWT sent to a server when I decode it?

No. ToolHQ's JWT decoder processes your token entirely in your browser using JavaScript. Your token is never sent to any server. This is the critical privacy guarantee for this tool.

Can this tool verify my JWT signature?

No. Signature verification requires the secret key used to sign the token. The decoder only decodes the base64url-encoded header and payload. To verify a token's signature, use your server-side JWT library.

Is a JWT encrypted?

No. Standard JWT tokens (JWS format) are signed, not encrypted. Anyone with the token can read the payload -- the signing only proves the token was issued by a trusted source. If you need encrypted payloads, use JWE (JSON Web Encryption) instead.

What does an expired JWT look like?

An expired JWT decodes normally -- the content is still readable. Check the exp claim, which is a Unix timestamp. If it's less than the current time, the token is expired.

What is the difference between an access token and a refresh token?

Most JWT-based authentication systems use two tokens. An access token is a short-lived JWT (typically 15 minutes to 1 hour) that your app sends with every API request to prove identity. When it expires, your app uses a refresh token to request a new access token without requiring the user to log in again. Refresh tokens are longer-lived (days to weeks) and usually stored in an httpOnly cookie rather than JavaScript-accessible storage. When you decode a JWT and check the exp claim, you're typically looking at an access token. If the token is expired, your app should use the refresh token to get a new one.

What is the difference between HS256 and RS256 in the header?

HS256 uses a symmetric secret key (the same key signs and verifies). RS256 uses asymmetric RSA keys (private key signs, public key verifies). RS256 is preferred for distributed systems where verification happens on different servers than signing.

---

The short version

When you need to read what's inside a JWT, ToolHQ's JWT decoder does it instantly and privately -- your token is never sent anywhere, ever. Paste your token, read the decoded header and payload, check your claims, and move on.

The tool is especially critical in professional contexts: always decode JWTs in a browser-based tool rather than a service that sends your token to a server.

For Base64 encoding/decoding needs, use ToolHQ's Base64 encoder. For JSON formatting, use the JSON formatter. Browse all developer tools at the ToolHQ developer category.

Decode your JWT now

---