Guide
Decode JWT Tokens Without Uploading Them
9 min read · Updated
Understand JWT header and payload claims, why decoding is not verification, and how to inspect tokens privately in the browser.
JSON Web Tokens (JWTs) are everywhere in modern auth: session cookies, Authorization headers, and service-to-service calls. Debugging them means reading the header and payload — and sometimes checking the signature. Many online “JWT debuggers” ask you to paste a token into a remote form. That habit is risky: tokens can include emails, roles, and enough material for session misuse if leaked.
What a JWT actually contains
A typical JWT has three Base64URL parts separated by dots: header, payload, and signature. The header usually names the algorithm (HS256, RS256, ES256, and others) and the type (JWT). The payload holds claims such as sub, name, iat, exp, and custom fields your app defines. The signature proves integrity only when verified with the correct secret or public key.
Decoding the first two parts is not the same as trusting them. Anyone can forge a payload string. Treat decoded claims as untrusted until signature verification succeeds and your app enforces issuer, audience, and expiry rules.
Decode locally with ShadowReference
Open the JWT Decoder, paste a token, and choose the algorithm chip that matches the header (or leave it on the detected value). The tool shows color-coded token parts, structured header and payload trees, human-readable claims, and optional signature status when you provide an HMAC secret or SPKI public key.
Verification runs in the browser with Web Crypto. The secret or key stays in memory for that session and is not uploaded. Still avoid pasting production secrets on shared machines — local processing does not protect a shoulder-surfer or a compromised laptop.
Expired tokens and “none” algorithms
An expired JWT can still be decoded so you can inspect historical claims. Your application should reject expired tokens at the API boundary. Be cautious with alg: none and unexpected algorithm switches — classic JWT attacks rely on trusting the header without verifying the signature correctly.
For asymmetric algorithms (RS*, ES*, PS*), paste an SPKI public key (BEGIN PUBLIC KEY). Certificates and private keys are not required for verification and should never be pasted into a public tool.
Safer debugging habits
Prefer redacted or staging tokens when you only need structure. Prefer browser DevTools or a local script when tokens are highly sensitive. Use a private online decoder only when you understand the risk model. ShadowReference’s JWT Decoder is built for that private, in-browser workflow — decode first, verify optionally, never ship the token to our backend.
Related tools
Try these free browser tools — processing stays on your device.
- JWT Decoder — Inspect JWT tokens like jwt.io, in your browser.
- Base64 Encoder / Decoder — Encode or decode Base64 text.
- Hash Generator — One-way cryptographic hashes in the browser.