JWT Decoder & Builder

Decode, edit, and generate JSON Web Tokens entirely in your browser. Inspect claims and verify HMAC signatures offline.

100% Offline Processing. Your tokens are highly sensitive. This tool uses a Javascript cryptographic engine that runs entirely within your browser. No data is ever transmitted to our servers.
Header (Algorithm & Token Type)
EDITABLE
Payload (Data & Claims)
EDITABLE

How to Build and Re-Sign a JWT

Unlike simple viewers, this tool features a full two-way binding JWT Builder. You can paste an existing token to decode it, or you can write your own JSON payload from scratch directly in the editors above.

  • Edit the JSON: Click into the Payload block and modify the data (e.g., change "role": "user" to "role": "admin").
  • Enter your Secret: Paste your backend HMAC secret key into the verification box.
  • Instant Generation: The tool will automatically calculate a new cryptographically secure signature (using HS256, HS384, or HS512) and output the valid JWT string into the top input box. You can then copy it as a Bearer header.

The Base64 Misconception: Encoded, Not Encrypted

The single most dangerous misconception in web security is that JSON Web Tokens hide data from the user. They do not.

Never Store Sensitive Data

The Header and Payload of a standard JWT are merely Base64Url encoded. Encoding is not encryption. Anyone who intercepts the token can simply paste it into a decoder and instantly read the JSON payload. If you store passwords, Social Security Numbers, or internal database secrets inside the payload, they are publicly visible.

Symmetric vs Asymmetric Signing

If anyone can decode the payload, how are JWTs secure? The security comes entirely from the Signature. If a user modifies the payload, the signature will instantly become invalid unless they also possess the secret key.

  • HMAC (HS256/384/512): Symmetric signing. The server uses a single "Secret Key" to both create the signature and verify it. This is incredibly fast but dangerous if the secret is leaked, as attackers can forge tokens.
  • RSA/ECDSA (RS256, ES256): Asymmetric signing. The server uses a hidden Private Key to sign the token. A distributed Public Key is used by other microservices to verify the token. This is the enterprise standard (OAuth2/Auth0) because services can verify tokens without knowing how to forge them.

Understanding Standard Claims

JWT payloads utilize standardized 3-letter acronyms (Claims) to keep the token size as small as possible. The Claims Inspector above automatically parses these for you:

exp Expiration Time: The exact Unix timestamp when the token permanently expires.
iat Issued At: The timestamp of when the token was originally generated.
sub Subject: The unique ID of the user or entity holding the token.

Frequently Asked Questions

Never Store Sensitive Data

Are JWT payloads encrypted?

No. Standard JSON Web Tokens are Base64Url encoded, not encrypted. Anyone who intercepts the token can easily decode the payload and read its contents. Never store sensitive information like passwords or Personally Identifiable Information (PII) in a JWT payload.

Can I edit the JWT payload and send it back to the server?

You can edit the payload locally, but the server will instantly reject it. The final section of a JWT is a cryptographic signature generated using a secret key held only by the server. If you alter even a single character in the payload, the signature will no longer match the contents, and the token will be invalidated.

Is it safe to paste my production JWT into this tool?

Yes. This tool is built with a 100% offline client-side JavaScript architecture. The decoding and signature verification happens entirely within your local browser memory, and the token is never transmitted to our servers or any third-party APIs.

Why does a JWT have three parts separated by dots?

A JWT consists of three distinct base64-encoded strings: The Header (which defines the token type and signing algorithm), the Payload (which contains the actual claims/data), and the Signature (which ensures the token hasn't been tampered with). The dots act as structural delimiters.

How do I securely store a JWT on the frontend?

Do not store JWTs in localStorage or sessionStorage, as they are highly vulnerable to Cross-Site Scripting (XSS) attacks. The most secure method is to store the JWT in a HttpOnly, Secure, SameSite=Strict cookie, which makes the token inaccessible to frontend JavaScript while still being automatically attached to outgoing API requests.

What happens if a JWT expires while a user is active?

The server will return a 401 Unauthorized error. To prevent abruptly logging the user out, modern applications use a "Refresh Token" pattern. When the short-lived access JWT expires, the frontend silently sends a long-lived HTTP-only refresh token to the server to instantly request a fresh access JWT.

Rate Offline JWT Token Decoder

Help us improve by rating this tool.

4.7/5
911 reviews