JWT Decoder: Header Payload Signature

Paste any JSON Web Token for an instant, color-coded breakdown of all three segments. Everything happens in your browser - your token is never transmitted anywhere.

Paste your JWT - decoding is instant, no button needed
Token segments
Header Algorithm and Token Type 
Paste a JWT above to decode...
Payload Claims and Data 
Paste a JWT above to decode...
Signature Integrity Proof 
Paste a JWT above to decode...
Signatures cannot be verified without the server's secret key. This tool decodes the payload safely for inspection only.
🔒
100% Client-Side and Private: All decoding runs locally in your browser with vanilla JavaScript. Your token is never uploaded, transmitted, or logged. Open the network tab in DevTools while using this tool and you will see zero outbound requests.

The Complete Guide to JSON Web Tokens

JSON Web Tokens are the backbone of modern authentication. You encounter them every time you stay logged in to a web app, call a REST API, or use a single sign-on system. Knowing how to read and inspect them is a foundational skill for developers, security engineers, and anyone who works with web services.

How to Use This Tool

Copy your JWT from any source - a browser cookie, a localStorage value, a Postman response, or an Authorization header - and paste it into the input box above. The decoder splits the token on the period character and decodes each Base64Url segment in real time. The pink panel shows the Header (the algorithm and token type). The purple panel shows the Payload (all claims, with any Unix timestamps expanded to human-readable dates). The cyan panel shows the raw Signature with an explanation of what it proves.

Key Terms Explained

JSON Web Token (JWT)
A compact, URL-safe token format defined in RFC 7519. It consists of three Base64Url-encoded segments joined by periods, used to securely transmit claims between two parties in a verifiable, self-contained package.
Base64Url Encoding
A variant of standard Base64 designed for URLs and HTTP headers. It replaces + with - and / with _ so the token string is safe to embed in a URL without percent-encoding. It is encoding, not encryption - anyone with the string can read it.
Claims
Key-value pairs in the JWT payload conveying information about the subject. Registered claims (exp, iat, sub, iss, aud) are standardized by RFC 7519. Public claims are registered in the IANA registry. Private claims are custom fields agreed upon by both parties.
Header
The first segment of a JWT. It declares the token type (typ: "JWT") and the signing algorithm used (alg: HS256, RS256, etc.). The server uses this to know how to verify the signature.
Payload
The second segment of a JWT. Contains the claims - the actual data being transmitted, such as a user ID (sub), expiration time (exp), issued-at time (iat), user role, and any custom application data the issuer chose to include.
Signature
The third segment of a JWT. Created by signing the encoded header and payload with a secret key using the declared algorithm. Changing any byte of the header or payload invalidates the signature and causes the server to reject the token.
HS256 (HMAC-SHA256)
A symmetric signing algorithm. The same secret key signs and verifies the token. Fast and simple for a single server, but every party that needs to verify tokens must possess the secret key - which creates a secret-sharing problem in distributed systems.
RS256 (RSA-SHA256)
An asymmetric signing algorithm. A private key signs the token; a separate public key verifies it. Any service can verify tokens by fetching the public key (often via a JWKS endpoint) without ever seeing the private signing key. This is the preferred choice for public APIs and multi-service architectures.

Frequently Asked Questions

What is a JSON Web Token used for?

A JSON Web Token is a compact, URL-safe token used to securely transmit information between two parties. JWTs are most commonly used for authentication and authorization: after you log in, a server issues a JWT that your client sends with every subsequent request to prove your identity - typically in the HTTP Authorization header as a Bearer token.

They are also used for sharing claims between services in microservice architectures. The token encodes information like your user ID, role, and expiration time directly inside it, so each service can verify your identity without querying a shared session database on every request. This stateless design is a major reason JWTs became popular for REST APIs, mobile backends, and single sign-on systems.

Is it safe to paste my JWT into this tool?

Yes, for this specific tool. All decoding is 100% client-side: it runs locally in your browser using vanilla JavaScript. Your JWT is never sent to any server, never logged, and never stored anywhere. Open your browser's network tab while using the tool and you will see zero outbound requests when you paste a token.

That said, apply common sense with live tokens. If a token grants access to a production system, revoke it after debugging rather than sharing it with colleagues via chat or email. A valid, unexpired JWT is a functional credential for whatever it authorizes, regardless of who holds it.

Can someone steal my data if they intercept my JWT?

Yes. If an attacker intercepts a valid JWT, they can use it to impersonate you until the token expires, because the JWT itself is proof of identity. This is why JWTs must always be transmitted over HTTPS, never plain HTTP. It is also why tokens should have short expiration times using the exp claim.

The payload of a JWT is Base64Url encoded, not encrypted. Anyone who obtains the raw token string can decode and read its contents - which is exactly what this tool does. Never store sensitive data like passwords, credit card numbers, or private keys in a JWT payload unless the entire token is also wrapped in JWE (JSON Web Encryption). If privacy of the payload contents matters, use JWE rather than plain JWS.

Why can't I edit the payload and send it back to the server?

Because the server validates the signature on every request. The signature is computed by combining the Base64Url-encoded header and payload, then running them through a signing algorithm (such as HMAC-SHA256) with a secret key that only the server knows. The result is the third segment of the JWT.

If you change even a single character in the payload - say, bumping your user role from "user" to "admin" - the signature no longer matches the modified content. Any properly implemented server will reject the token as tampered and return a 401 Unauthorized error. Without the server's secret key, you cannot generate a valid signature for altered content. This cryptographic binding between the payload and the signature is the entire security model of JWTs, and why they are trusted for authentication without a database lookup on every request.