Can I decode a JWT without the secret?

Yes — and you don't need the secret to decode. A JWT's header and payload are just base64url-encoded JSON; any decoder, including PDFFlare's, can read them in milliseconds. The secret (or public key) is only required to verify the signature, which is a separate step. Decoding tells you what claims the token carries; verification tells you the issuer actually minted it. Read first, verify on a backend you trust.

Why does my JWT show as Expired even though it works?

PDFFlare's JWT decoder uses your browser's clock to compare against the exp claim. If the token still works in your backend, the most likely cause is clock skew — your laptop, your auth server, and your API server have slightly different times. Most JWT libraries allow a 30-60 second leeway window for this exact reason. A larger drift (CI runners, virtualized environments) can show a fresh token as expired in the decoder while the verifier accepts it.

Is alg: none safe to accept?

No — alg: none means the verifier should not check the signature. It's a known attack pattern: an attacker who can craft a token with alg: none can impersonate anyone if a verifier accepts that algorithm. Every modern JWT library (jose, jsonwebtoken, PyJWT, golang-jwt) rejects alg: none by default. PDFFlare's JWT decoder flags it loudly so you spot it in code review or during incident response.

How do I verify a JWT signature after decoding?

Decoding shows you what's in the token; verification proves the issuer minted it. Use a real auth library on a backend you control: jose for modern Node, jsonwebtoken for legacy Node, PyJWT for Python, golang-jwt for Go, or your identity provider's SDK. You'll need either the shared HMAC secret (for HS256/HS384/HS512) or the issuer's public key (for RS256, ES256, EdDSA, etc.). PDFFlare never asks for either — verification belongs in trusted code, not a web tool.

What's the difference between a JWS and a JWE?

JWS (JSON Web Signature, RFC 7515) is signed but not encrypted — the payload is base64url-encoded JSON anyone can read. JWE (JSON Web Encryption, RFC 7516) wraps the payload in real ciphertext that requires a key to decrypt. JWS tokens have three dot-separated parts; JWE tokens have five. Almost every JWT you encounter in practice is a JWS. PDFFlare's JWT decoder handles JWS; if your token has five parts, it's a JWE and needs your backend's decryption library.

May 5, 20269 min read

How to Decode a JWT Online (Free JWT Decoder, Browser-Only)

You captured a JWT from your browser's Network tab. It looks like three blobs of gibberish separated by dots. You need to know what claims it carries — who issued it, who it's for, when it expires, what scopes it grants — and you need to know in the next five minutes because something in production isn't working. That's the moment a good JWT decoder online earns its keep.

In this guide you'll learn how to decode JWT online using PDFFlare's JWT Decoder — paste a JSON Web Token and get the header, payload, signature, and standard claims surfaced in seconds. Use it as a JWT parser, a JWT debugger free of signups and rate limits, or a JSON Web Token decoder for incident response. It runs entirely in your browser — your token never reaches a server, never lands in a log, never gets cached on a CDN.

What Is a JWT and Why Does It Look Like Gibberish?

A JWT (JSON Web Token, RFC 7519) is three base64url-encoded strings joined by dots: header.payload.signature. The header declares the signing algorithm. The payload is a JSON object of claims. The signature is a cryptographic check over the first two parts.

The dots and the funny-looking characters (- and _ instead of + and /) are the only thing standing between you and a regular JSON object. Decode the header and payload from base64url, parse the JSON, and you have a fully readable token. The signature stays opaque — you can't verify it without the issuer's key, but you don't need to verify to read.

Most people use a JWT token decoder online for one of three reasons: debugging an auth flow that's failing, integrating with a new identity provider whose claim names you don't know yet, or responding to a security incident where you have a captured token and minutes to figure out who issued it. All three are reading problems, not verification problems — which is why a decode-only tool like PDFFlare's view JWT claims interface is enough.

How to Decode a JWT Step by Step

Open the JWT decoder. Visit /tools/dev/jwt-decoder in any modern browser. No login, no signup, no install. The page loads in under a second on a typical connection.
Paste the full token. Copy the whole JWT — all three dot-separated parts — and paste it into the input box. If you pasted only the payload by accident, the decoder will tell you the token is missing parts; re-copy from the source.
Read the decoded header. The header card shows the JSON header along with an Algorithm subtitle (HS256, RS256, ES256, EdDSA, etc.). If you see alg: none, stop — see the security section below.
Read the decoded payload. The payload card shows the full JSON, plus a Standard Claims block that highlights the seven RFC 7519 registered claims (iss, sub, aud, exp, nbf, iat, jti) with plain-English descriptions and a human-readable timestamp for each time-based claim.
Check the expiration banner.A coloured banner at the top tells you whether the token is Active, Expires within an hour, or Expired. Pair this with your backend's clock to spot clock-skew bugs in seconds.
Copy what you need. Each card has a Copy button — grab the header JSON, payload JSON, or raw signature for sharing in a Slack thread or pasting into your debugger.

Common JWT Claims Explained (RFC 7519)

The seven registered claims from RFC 7519 are the same across every JWT-issuing platform — Auth0, Okta, Cognito, Firebase, Supabase, Keycloak, your homegrown auth service. Knowing them cold pays back every time you pop a token open.

What is the iss (issuer) claim?

The iss claim names who minted the token. In OpenID Connect this is usually a URL like https://accounts.google.com. Your verifier should assert that iss matches an issuer you trust before accepting the token — a token from an unexpected issuer is the first sign of a token-substitution attack.

What is the sub (subject) claim?

The subclaim names the principal the token is about — usually a stable user identifier the issuer assigns to each user. It should be unique within the issuer's namespace, and the pair (iss, sub) should uniquely identify a user across your whole system.

What is the aud (audience) claim?

The aud claim names the intended recipient(s). Your verifier must reject tokens whose auddoesn't include your service — that's how you stop a legitimate token issued for a different API from being replayed against yours. audcan be a string or a JSON array of strings; PDFFlare's JWT decoder displays both correctly.

What is exp, iat, nbf?

All three are Unix timestamps in seconds. exp (expiration time) bounds when the token stops being valid; nbf (not before) bounds when it starts; iat (issued at) records when it was minted. Most token bugs hide here — wrong server clock, missing leeway in the verifier, or a refresh-token loop that never lets iat advance.

What is the jti claim?

The jti claim is a unique token identifier — useful when you need to track or revoke individual tokens. UUIDs are the conventional choice for jti; you can mint them at issuance time with PDFFlare's UUID Generator.

JWT Decoder vs JWT Verifier — What This Tool Cannot Do

A decoder shows you what's in the token. A verifier proves the token is authentic — that the signature matches the header and payload, and that the issuer minted it with their key. PDFFlare is a decoder, not a verifier, by design: verifying requires the signing key (HMAC secret for HS256/HS384/HS512, or the issuer's public key for RS256/ES256/EdDSA), and a third-party tool should never see those.

For verified decoding, run a real auth library on a backend you control — jose on the modern Node ecosystem, jsonwebtoken on legacy Node, PyJWT on Python, github.com/golang-jwt/jwton Go, or your identity provider's SDK. Use PDFFlare's JWT debugger free of charge for the read step, then verify in a trusted environment before granting access.

Common Mistakes When Reading JWTs

Trusting alg: none

The none algorithm tells a verifier don't check the signature. It exists in the spec for unsigned tokens but it has been the source of catastrophic auth bypasses — every modern JWT library rejects it by default, and PDFFlare's decoder shows a red warning whenever it appears so you spot the issue during code review or incident response.

Confusing clock skew with an expired token

PDFFlare's decoder uses your browser's clock when marking a token Expired. If the token still works in your backend, the most likely cause is that your auth server, your API server, and your laptop have slightly different clocks — most JWT libraries allow a leeway window of 30-60 seconds, and a 15-minute time drift on a CI runner can mark a fresh token as expired in your tool.

Confusing JWS with JWE

A signed JWT (a JWS) has three dot-separated parts. An encrypted JWT (a JWE, RFC 7516) has five. If your token has five parts, it's encrypted — no client-side tool can decode it without the key, and you should reach for your backend's decryption library instead. PDFFlare's JWT decoder will tell you the part count is wrong rather than silently misparsing.

Skipping the aud check on the verifier

Reading the audclaim during debugging is half the battle; the other half is making sure your verifier actually checks it. A token issued for service A, replayed against service B that doesn't check aud, is a real attack class — and it's easy to spot once you have a decoder open showing the claim front and centre.

Privacy and Security Notes

Decoding happens entirely in your browser via atob(), TextDecoder, and JSON.parse(). PDFFlare's JSON Web Token decoder never sends your token to any server, never logs it, never caches it. It's safe to use for production access tokens, internal admin sessions, and anything you wouldn't paste into a third-party debugger.

That said, an active token still grants real access while it's valid. Treat any JWT in your clipboard the way you'd treat a password — close the tab when you're done, don't leave it in a Slack DM history, and rotate the underlying credential if a sensitive token may have leaked.

Related Tools

Base64 Encode / Decode — JWTs use base64url for the header and payload; this tool handles arbitrary base64 and base64url payloads when you need to dig deeper than the JSON.
Hash Generator — compute MD5, SHA-1, SHA-256 hashes of arbitrary text. Useful when you're comparing token fingerprints across log lines or building your own minimal HS256 verifier in a scratchpad.
UUID Generator — mint new jti values, request IDs, and correlation IDs. v4 for opaque tokens, v7 for time-ordered primary keys.
URL Encode / Decode — encode JWT-bearing query parameters or decode the redirect-URI claims you'll often see in OpenID Connect tokens.

Wrapping Up

A JWT looks opaque, but it's really just three pieces of base64url and a JSON object you already know how to read. Drop a token into PDFFlare's JWT decoder when you need to debug an auth flow, integrate with a new identity provider, or read a captured token during an incident. Header, payload, and the standard claims appear in seconds — in your browser, never on a server, with the security warnings (alg: none, expired, malformed) you actually want to see.

Bookmark the JWT Decoder for the next time auth breaks at 2 AM. Free, browser-only, no signup — and now the JWT token decoder online your team can paste into without thinking twice.