How to Decode a JWT Token — Free Online Decoder (No Upload)
You're debugging an auth flow and need to see what's actually inside the token your API is sending. A JWT decoder reveals the header and payload in seconds, so you can check the claims, the expiry, and who issued it. But there's a crucial point most guides skip: decoding is not the same as verifying. This article explains the structure, what each part means, the security line you must not cross, and why decoding a production token client-side, where your token stays in your browser and is never sent to a server, is the only sensible choice.
- A JWT has three Base64url parts split by dots: header, payload, and signature, as defined in RFC 7519.
- The payload is encoded, not encrypted - anyone with the token can read it. Never store secrets in a JWT.
- Decoding reads the contents; verifying proves authenticity. They are different operations and only verification needs a key.
- Decode production tokens client-side: your token stays in your browser and is never sent to a server, so it can't be logged or stolen.
What Is a JWT and How Is It Structured?
A JSON Web Token (JWT) is a compact, URL-safe way to carry claims between two parties, defined by RFC 7519. It has three parts separated by dots: header.payload.signature. JWTs are extremely widespread - they underpin OAuth 2.0 and OpenID Connect, the basis for "Sign in with Google" and similar flows used by billions of accounts.
The dots are the giveaway. A JWT always looks like a long string broken into three chunks: eyJhbGci... then a dot, then eyJzdWIi... then a dot, then a signature. Each of the first two chunks is a Base64url-encoded JSON object. The third is a cryptographic signature over the first two.
That design lets a server hand a client a self-contained credential. Instead of looking up a session in a database on every request, the server can read the claims directly from the token and trust them, provided the signature checks out. That statelessness is why JWTs became the default for modern API authentication.
How Does JWT Decoding Actually Work?
Decoding a JWT means Base64url-decoding the header and payload back into readable JSON. Base64url is a URL-safe variant of Base64 that swaps two characters and drops padding so the token survives inside URLs. The operation is purely reversible and needs no key, because the header and payload were never encrypted in the first place.
Here's the step by step. A decoder splits the token on the dots into three pieces. It takes the first piece, reverses the Base64url encoding, and gets the header JSON. It does the same with the second piece to get the payload JSON. The third piece, the signature, stays as raw bytes because there's nothing human-readable to extract from it.
This is why you can read any JWT you hold without permission from anyone. The encoding is transport packaging, not protection. Many developers are surprised the first time they paste a token and see their own user ID and email sitting in plain text. That reaction is healthy - it's exactly why secrets must never go in a payload.
How to Decode a JWT Online with FusionPDF
The decoder runs entirely in your browser using JavaScript Base64url decoding. Your token never leaves the page, so even a live production token is safe to inspect. Decoding is instant - splitting and decoding three short strings takes a fraction of a millisecond on any device.
Go to fusionpdf.pro/jwt-decoder. No account, no sign-up. It loads directly in your browser, nothing to install.
Paste the full JWT, including both dots. The token stays in browser memory only - confirm in your browser's network tab that no request is sent.
The decoder splits the token and shows the header and payload as formatted JSON. Standard claims like exp and iat are converted to readable dates so you can check expiry at a glance.
Check the claims you came for - issuer, subject, expiry, scopes. When you close or refresh the tab, the token is gone from memory. Nothing was ever stored or transmitted.
What's Inside the Header, Payload, and Signature?
The header declares the token type and signing algorithm; the payload carries the claims; the signature proves the first two weren't tampered with. The header almost always contains two fields: alg (the algorithm, e.g. HS256 or RS256) and typ (the type, usually JWT). Those two fields drive how the token is verified.
The header
A typical header decodes to {"alg":"HS256","typ":"JWT"}. The alg field tells the verifier which algorithm produced the signature. This field matters for security: a famous class of attacks involves swapping alg to none or downgrading it, which is why servers must pin the expected algorithm rather than trust the header blindly.
The payload
The payload holds the claims - statements about the user and the token. You'll see registered claims like iss, sub, exp, and iat, plus any custom claims the issuer added, such as roles, scopes, or a tenant ID. Everything here is readable, so it should contain identifiers and metadata, never passwords or keys.
The signature
The signature is computed over the encoded header and payload using the algorithm from the header and a secret or private key. It's what makes the token trustworthy: change a single character in the payload and the signature no longer matches. A decoder shows the signature but cannot tell you whether it's valid without the key.
Critical: a JWT payload is not secret. Because it's only Base64url-encoded, anyone who intercepts or is handed the token can read every claim inside. Never place passwords, API keys, full card numbers, or any sensitive secret in a JWT payload. The signature stops tampering, not reading.
Why Is Decoding Not the Same as Verifying?
Decoding reads the contents; verifying proves they're authentic and untampered. They are fundamentally different and only verification requires the signing key. This distinction is the single most misunderstood thing about JWTs, and getting it wrong is a documented source of authentication bypass vulnerabilities tracked in the OWASP API Security guidance.
Picture a sealed, transparent envelope. Decoding is reading the letter through the clear plastic - anyone can do it, no key needed. Verifying is checking that the wax seal is genuine and unbroken - that requires knowing what the real seal looks like, which is the signing secret or public key. You can always read the letter. Only the keyholder can confirm it's authentic.
The practical consequence is blunt: never trust a decoded payload on its own. A decoder shows you claims, but a forged token full of false claims decodes just as cleanly as a real one. Authentication decisions must happen on your server after verifying the signature with your key. The decoder is a debugging lens, not an authorization gate.
To verify a JWT properly you need the signing key. For symmetric algorithms like HS256, that's the shared secret. For asymmetric ones like RS256, it's the issuer's public key, usually published at a JWKS endpoint. A trustworthy online decoder will not ask you to paste your production secret, because doing so over a network would itself be a security risk.
What Do the Standard JWT Claims Mean?
RFC 7519 defines a set of registered claims with three-letter names that carry consistent meaning across systems. The most common are iss, sub, aud, exp, and iat. These short names exist deliberately to keep tokens compact, since a JWT often travels in a header on every single request.
- iss (issuer): who created and signed the token, e.g. your auth server's URL.
- sub (subject): who the token is about, typically the user ID.
- aud (audience): who the token is intended for, e.g. a specific API.
- exp (expiration): a Unix timestamp after which the token must be rejected.
- iat (issued at): a Unix timestamp marking when the token was created.
- nbf (not before): a Unix timestamp before which the token is not yet valid.
- jti (JWT ID): a unique identifier, useful for preventing token replay.
The timestamp claims trip people up because they're Unix epoch seconds, not human dates. A value like 1718600000 means nothing at a glance. A good decoder converts exp and iat into readable dates and times so you can immediately see whether a token is expired, which is the most common reason a previously working request suddenly returns a 401.
Why Decode a Production Token Client-Side?
A live JWT is a bearer credential: whoever holds it can act as the user until it expires. Pasting one into a server-based decoder hands that credential to a third party who could log it and reuse it. A client-side decoder never transmits the token, so your token stays in your browser and is never sent to a server, eliminating that risk entirely.
The word "bearer" is doing heavy lifting here. In an Authorization header, a JWT typically appears as Bearer eyJ..., and "bearer" literally means the system trusts whoever bears the token. There's no second factor. If someone captures a valid, unexpired token, they can impersonate the user for the life of that token. That's the whole threat model.
So consider what a server-side decoder does. It receives your token, processes it on a remote machine, and may log requests for debugging or analytics. You cannot audit that machine's retention. We've found this is the most overlooked risk in everyday developer tooling - tokens get pasted into random sites without anyone thinking about where they go.
The honest rule: treat a production JWT like a password, because functionally it is one. Decode it only in a tool that runs in your browser, like the FusionPDF JWT Decoder, where the token never leaves the page. The same client-side principle applies when inspecting raw JSON payloads, covered in our JSON formatting guide.
Frequently Asked Questions
Does decoding a JWT mean I've hacked or broken it?
No. The payload and header of a JWT are only Base64url-encoded, not encrypted, so anyone holding the token can read them. Decoding simply reverses that encoding to show the contents. It reveals nothing secret and grants no access. The signature, which proves the token is authentic, cannot be forged by decoding alone.
Can I verify a JWT's signature with a decoder?
Decoding and verifying are different operations. Decoding reads the header and payload, which needs no secret. Verifying confirms the signature was produced with the correct key, which requires the signing secret or public key. A pure decoder shows you the contents but does not prove authenticity. Always verify signatures on your server before trusting a token.
Is a JWT encrypted?
A standard signed JWT (JWS) is not encrypted. Its header and payload are Base64url-encoded and fully readable by anyone who has the token. The signature protects against tampering, not against reading. Never put secrets in a JWT payload. A separate standard, JWE, does encrypt the payload, but the common bearer token you see in Authorization headers is signed, not encrypted.
What should I do if the exp claim is in the past?
An exp (expiration) claim in the past means the token is expired and a correctly configured server will reject it. The fix is to obtain a fresh token, usually by re-authenticating or using a refresh token if your auth flow provides one. Decoding the token lets you read the exp value, a Unix timestamp, to confirm whether expiry is the cause of a 401 error.
Is it safe to paste my JWT into an online decoder?
Only if the decoder runs entirely client-side. A server-based decoder transmits your token to a remote machine, where a valid production token could be logged, retained, or misused to impersonate you. A client-side decoder like FusionPDF processes the token in your browser, so it's never sent to a server. You can verify zero network requests in your browser's network tab.
Decode Your JWT Now
Free, instant, private. Read the header, payload, and claims with expiry shown as readable dates. Your token stays in your browser - no upload, no account.
Open JWT Decoder →