JWT Decoder Online — Decode JSON Web Tokens Free
JWT decoder online — decode any JSON Web Token to view header, payload, and claims. Spots expired tokens, exposes algorithm. 100% browser-based, no signup.
Your token is decoded entirely in your browser using atob() and JSON.parse(). Nothing is sent to a server. PDFFlare cannot verify a JWT's signature without the signing secret or public key — for verification, use your own auth library on a trusted backend.
PDFFlare's JWT decoder online turns any JSON Web Token into a readable header, payload, and signature in milliseconds. Paste a token and the decoded claims (iss, sub, aud, exp, iat, nbf, jti) appear inline with plain-English explanations, expiration status, and an algorithm warning if the token uses alg: none. Use it as a JWT parser, JWT debugger, or a quick JSON Web Token decoder — no signup, no rate limits, no token leaves your browser.
Working through the same auth or debugging session? Pair this with Base64 Encode / Decode for arbitrary base64url payloads, Hash Generator to compute MD5 / SHA-256 checksums, or UUID Generator to mint jti values for new tokens.
Decoding runs entirely in your browser via atob(), TextDecoder, and JSON.parse(). PDFFlare never sees the token, never logs it, and cannot verify its signature — that requires the issuer's secret or public key, which belongs in your own backend. Use this view JWT claims tool for debugging, learning, and incident response, then verify on a server you trust.
How to Decode a JWT
Paste your JSON Web Token
Drop the full token (header.payload.signature, three dot-separated parts) into the input box. The decoder runs entirely in your browser — nothing is uploaded.
Inspect the decoded header and payload
The header reveals the signing algorithm (alg) and token type (typ). The payload shows every claim — standard registered claims (iss, sub, aud, exp, iat, nbf, jti) are highlighted with plain-English explanations.
Check expiration and copy any section
A coloured banner shows whether the token is Active, Expires within an hour, or Expired. Use the Copy buttons to grab the header JSON, payload JSON, or raw signature for sharing or further analysis.
When Do You Need a JWT Decoder Online?
Debugging auth flows: Login broken? Refresh-token loop? The first move is to decode JWT online and read what the token actually claims — wrong aud, missing scope, expired exp, or a clock skew between your auth server and your API server. The decoder surfaces these in seconds, before you reach for stack traces.
Inspecting third-party tokens: Integrating with Auth0, Okta, Cognito, Firebase, Supabase, or your own identity provider? Each issuer packs different custom claims into the payload. Use this JWT debugger free to see exactly which claims arrive on your tokens so you wire your middleware to the right field names the first time.
Incident response: When a security alert fires, you often have a captured token and minutes to figure out who issued it, who it's for, and when it expires. Pasting it into a JSON Web Token decoder gives you the answer faster than spinning up your dev environment — and PDFFlare keeps the token in your browser so it never lands in a third-party log.
Learning JWT structure: The fastest way to understand JWTs is to decode a few. Load the sample token, watch how the three base64url parts split, see how the header declares the algorithm, and trace which claims your backend cares about. After a handful of tokens the structure clicks — and PDFFlare's view JWT claims explanations make the standard fields self-documenting.
Why Choose PDFFlare's JWT Decoder?
Header, Payload, and Claims Insights
Decoded JSON for both header and payload, plus a separate Standard Claims block that explains iss, sub, aud, exp, nbf, iat, and jti in plain English.
Expiration & Algorithm Warnings
A traffic-light banner shows Active / Expires within an hour / Expired with the exact ISO timestamp and human-readable relative time. alg: none tokens trigger a clear security warning — never miss them in a code review.
100% Browser-Based
Decoding uses your browser's built-in atob() and JSON.parse(). The token never goes to any server — safe for production access tokens, internal admin sessions, and anything you wouldn't paste into a third-party debugger.
No Signup Required
Free, unlimited, no account, no rate limits, no API keys. Decode JWT online as many times as you need — perfect for debugging in production incidents when every second matters.
Frequently Asked Questions About JWT Decoder
A JWT is a compact, URL-safe representation of claims between two parties, defined in RFC 7519. It has three parts joined by dots: a base64url-encoded header (algorithm and token type), a base64url-encoded payload (the claims), and a signature. JWTs are widely used for authentication and authorization — most OAuth 2.0 and OpenID Connect access tokens are JWTs.
No — and no client-side decoder safely can. Verifying a JWT signature requires either the shared secret (for HS256 / HS384 / HS512) or the issuer's public key (for RS256, ES256, EdDSA, etc.). PDFFlare never asks for either. If you need verified decoding, use your own auth library on a trusted backend — jose, jsonwebtoken on Node, PyJWT on Python, or your platform's SDK.
JWTs use the exp claim — a Unix timestamp in seconds since 1970 — to mark expiration. PDFFlare's decoder compares exp against your browser's current time and shows Expired, Expires within an hour, or Active. If the token actually still works in your app, your server's clock may be skewed or your auth library may allow a leeway window (typically 30-60 seconds).
Decoding happens entirely in your browser — the token never travels over the network and never reaches PDFFlare. That said, a JWT that's still active grants real access to whatever issued it. If the token is sensitive (production access token, internal admin session), prefer to decode it inside your own dev tools or a local CLI. Once a token is in your clipboard or editor, treat it as you would any other credential.
The none algorithm tells a verifier not to check the signature. It exists in the JWT spec for unsigned tokens but has been the source of major auth bypasses — an attacker who can craft tokens signed with none can impersonate anyone if a verifier accepts that algorithm. Every modern JWT library rejects none by default; PDFFlare's JWT decoder flags it loudly so you can spot it during debugging or a security review.
JWS (JSON Web Signature, RFC 7515) is the format for signed tokens — header.payload.signature, all base64url-encoded. JWE (JSON Web Encryption, RFC 7516) wraps the payload in real ciphertext so it is unreadable without the key. JWT (RFC 7519) is a set of claims serialised as either a JWS or a JWE; in practice almost every JWT you see is a JWS. PDFFlare's JWT decoder handles JWS tokens (the dot-separated three-part form). JWE tokens have five parts and require decryption — outside the scope of any client-side decoder.
These are the seven registered claims from RFC 7519. iss (issuer) names who minted the token. sub (subject) names the principal — usually a user ID. aud (audience) names the intended recipient(s); your verifier should reject tokens whose aud does not match your service. exp and nbf bound when the token is valid. iat is when it was issued. jti is a unique token ID, useful for revocation lists. Custom claims (anything else) are application-specific.
The most common reasons: the token is missing one of the three parts (check for trailing whitespace or truncated values); it is actually a different token format like an opaque session ID or a JWE; the header or payload base64url is malformed; or the JSON inside the base64url is malformed. PDFFlare's JWT decoder shows a specific error for each case so you can pinpoint where the token broke.
Decoding is algorithm-agnostic — every JWT, regardless of alg, uses the same base64url-encoded header.payload.signature structure. You can paste an HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512, or EdDSA token and PDFFlare will decode the header and payload identically. Verification (which checks the signature) is the part that depends on the algorithm, and that requires keys we do not have.