JWT Decoder — Decode JSON Web Tokens Instantly

Paste any JWT and see its header, payload, and signature decoded in real time. Standard claims (exp, iat, nbf) are interpreted into human-readable expiry information. Your token is decoded locally in your browser — nothing is uploaded.

Paste a JWT to begin
Header ALGORITHM & TOKEN TYPE 

					


					

						

							Payload
							DATA & CLAIMS
							
						

						


						
					


					

						

							Signature
							BASE64URL — NOT VERIFIED
							
						

						

					


				


				

					
					This tool decodes JWTs. It does not verify the signature — that requires the issuing server’s secret or public key. A decoded token can still be forged; never trust claims from an unverified JWT.
				


			

		


		


									

					

						

Free JWT Decoder — Inspect JSON Web Tokens in Your Browser





This is a free online JWT decoder that splits any JSON Web Token into its three parts — header, payload, and signature — and pretty-prints the decoded JSON the moment you paste. Standard claims like exp, iat, and nbf are humanised into relative phrases (“expires in 2 hours”, “issued 40 seconds ago”) so you don’t have to convert Unix timestamps by hand just to check whether a token is still valid.





Everything happens locally. The token is split on dots and base64url-decoded with plain JavaScript — no external libraries, no network calls, nothing sent to a server, nothing logged. You can disconnect from the internet after the page loads and the decoder keeps working, which matters when you’re inspecting a token you’d rather not paste into a third-party service.





What is a JSON Web Token?





A JWT is a compact, URL-safe credential that carries a JSON payload plus a cryptographic signature. It’s the format most modern APIs, single-sign-on systems, and microservices use to pass authentication and authorisation data around. A JWT has exactly three base64url-encoded parts separated by dots:





    

  • Header — a small JSON object that declares the signing algorithm (alg) and token type (typ). Common algorithms include HS256 (HMAC-SHA256), RS256 (RSA), and ES256 (ECDSA).
    • 




  • Payload — the claims. Standard claims include iss (issuer), sub (subject / user id), aud (audience), exp (expiration), iat (issued at), and nbf (not before). Applications add their own custom claims like role, scope, or tenant_id.
    • 




  • Signature — the output of the signing algorithm applied to the first two parts. This is what lets a server verify a token without needing a session lookup.
    • 






The three parts are joined with dots (header.payload.signature). The dots make JWTs trivial to split and decode — which is why every JWT decoder, including this one, can read the header and payload of any token without any key.





Decoding ≠ verifying (important)





This tool, like every browser-based JWT decoder, does not verify the signature. Verification requires the issuer’s secret (for HMAC algorithms) or public key (for RSA/ECDSA), and neither is available to a generic decoder. That’s not a limitation — it’s how JWTs are designed to work:





    

  • Anyone can decode a JWT. The payload is readable by design. If you don’t want a value visible, don’t put it in a signed JWT — use a JWE (encrypted JWT) or store the data server-side and put only an opaque reference in the token.
    • 




  • Only the key-holder can verify or issue one. Verification belongs on your server, using a library that checks the signature against the correct secret or public key and rejects the token if anything is off.
    • 






A decoded payload is not a verified payload. Never trust the claims from a JWT your server hasn’t validated — the payload you see in this decoder could have been crafted by anyone with base64 skills.





How to use this JWT decoder





    

  1. Paste your token into the input box. It should look like eyJhbGciOi….
    Click Load sample if you just want to see what a decoded JWT looks like.
    2. 




  2. The three panels update instantly:

      

    • Header — algorithm and token type.
      • 




    • Payload — all claims, plus a separate “Standard Claims” section that humanises iat, exp, and nbf.
      • 




    • Signature — the raw base64url-encoded signature bytes (not verified).
      • 

    

    3. 




  3. Use the Copy button on any panel to grab the decoded JSON for a bug report, a gist, or a unit test fixture.
    4. 






The standard claims you’ll see most often





These are defined in RFC 7519 and are the ones this decoder pays special attention to:





    

  • iss — issuer. Who minted the token. Usually your auth server’s URL.
    • 




  • sub — subject. Who the token is about. Typically a user ID.
    • 




  • aud — audience. Which service the token is intended for. Servers must reject tokens addressed to someone else.
    • 




  • exp — expiration. Unix timestamp after which the token is invalid. Shown here as “expires in X” or “expired X ago”.
    • 




  • iat — issued at. When the token was minted.
    • 




  • nbf — not before. Token is invalid until this instant.
    • 




  • jti — JWT ID. A unique identifier for the token, useful for revocation lists.
    • 






Common use cases





    

  • Debugging “401 Unauthorized” — paste the token your client is sending and check whether exp has passed or aud matches what the server expects.
    • 




  • Verifying SSO tokens — confirm the iss, sub, and scope claims match what your identity provider should be emitting.
    • 




  • Auditing permission scopes — look at custom claims like roles, permissions, or tenant_id to check what a token authorises.
    • 




  • Teaching and documentation — use the “Load sample” button to show a colleague the structure of a JWT without handing them a real one.
    • 




  • Inspecting third-party tokens — see what’s inside a JWT returned by Auth0, Okta, AWS Cognito, Firebase, Supabase, Keycloak, or a custom OAuth 2.0 provider.
    • 






JWS vs. JWE — which does this decoder handle?





When people say “JWT” they almost always mean JWS (JSON Web Signature) — a signed token with a readable payload. That’s what this tool decodes. A JWE (JSON Web Encryption) is an encrypted JWT with five dot-separated parts and an unreadable payload unless you hold the decryption key; JWE tokens are less common outside specific enterprise and healthcare integrations, and this decoder does not attempt to process them. If your token has five dots instead of two, it’s a JWE and you’ll need the decryption key in your own code to read it.





A note on alg: "none"





Some tokens declare "alg": "none" in the header, which means the token is unsigned. This was the source of a well-known class of vulnerabilities: attackers would take a valid token, change the algorithm to none, strip the signature, and libraries that didn’t filter algorithms would accept the forged token as valid. Every well-maintained JWT library now rejects alg: "none" by default. If you see it in a token from an external source, treat that token as completely unauthenticated — anyone could have produced it.





Is it safe to paste a production token here?





The decoding itself is safe — your token never leaves your browser. But a live JWT is, in most systems, a bearer credential: whoever holds it can impersonate the user until it expires. Treat production tokens like passwords. Prefer pasting expired tokens, sample tokens, or tokens from a staging environment when you’re debugging. If you must paste a live production token, revoke it (log the user out, rotate the session) as soon as you’re done. This advice applies to every JWT decoder, including the ones that claim to be “secure”.





Privacy and offline use





All decoding happens locally with the browser’s built-in atob and JSON.parse — there are no external libraries, no fetch calls, no analytics hooks on the token input. Once the page has loaded, you can disconnect from the internet and keep decoding. Nothing about your token is ever logged, cached on a server, or sent to a third party.

					

				

					
		
		

			

				FAQ
				
Frequently Asked Questions

				

											

							
							

								

									
A JWT is a compact, URL-safe token that carries a JSON payload signed with a secret or a key pair. It has three base64url-encoded parts separated by dots: a header that declares the signing algorithm, a payload that holds claims (user ID, expiry, scope, etc.), and a signature that the issuer computes over the first two parts. Servers use JWTs for authentication, session replacement, and passing claims between services.

								

							

						

											

							
							

								

									
Part 1 (header) and part 2 (payload) are each a JSON object that has been base64url-encoded. Part 3 (signature) is the binary output of the signing algorithm applied to the first two parts, also base64url-encoded. The parts are joined with dots: header.payload.signature. The dots make JWTs trivial to split and decode — which is exactly what this tool does.

								

							

						

											

							
							

								

									
No, and that is intentional. Signature verification requires the issuer's secret (for HMAC algorithms like HS256) or the issuer's public key (for RSA/EC algorithms like RS256, ES256). Neither is available to a generic decoder. Anyone can decode a JWT — that is by design — but only the holder of the correct key can verify or issue one. If you need to verify a token, do it server-side with the proper key.

								

							

						

											

							
							

								

									
The decode itself happens entirely in your browser — the token is split on dots and base64-decoded with pure JavaScript. Nothing is sent to a server, logged, or stored. That said, JWTs often carry sensitive claims (user IDs, emails, permission scopes) and in some systems the token itself is a bearer credential. Treat a live production token the same way you would treat a password. This tool is safer than any other JWT decoder that makes a network call, but you should still avoid pasting tokens from production if you can test with a sample or a non-production environment.

								

							

						

											

							
							

								

									
"iat" (issued at) is the Unix timestamp when the token was created. "exp" (expiration) is the Unix timestamp after which the token is no longer valid — servers reject tokens whose exp has passed. "nbf" (not before) is the Unix timestamp before which the token is not yet valid — useful for delaying activation. All three are standard claims defined in RFC 7519. This tool automatically interprets them as relative times (e.g. "expires in 2 hours" or "expired 3 days ago") so you do not have to convert timestamps by hand.

								

							

						

											

							
							

								

									
A signed JWT is technically a JWS (JSON Web Signature) — the payload is readable but authenticated by a signature. An encrypted JWT is a JWE (JSON Web Encryption) — the payload is encrypted and unreadable without the key. The JWT spec covers both, but in practice "JWT" usually means JWS because that is what authentication systems use. This tool decodes JWS tokens (3 dot-separated parts). JWE tokens have 5 dot-separated parts and require the decryption key to read the payload; this tool does not handle JWE.

								

							

						

											

							
							

								

									
Some JWTs use alg:"none" to indicate an unsigned token — the signature part is empty. This was a historical CVE gold mine: attackers would change the alg from HS256 to none, strip the signature, and libraries with lazy verification would accept the forged token. Well-maintained JWT libraries now reject alg:"none" by default. If you see alg:"none" in a token from a third party, treat that token as unauthenticated.

								

							

						

											

							
							

								

									
Yes. Once the page has loaded, the decoder runs entirely in your browser. All parsing is plain JavaScript with the browser's built-in atob function — no external libraries, no network calls. You can disconnect from the internet and continue decoding tokens.