JWT Decoder & Debugger — Inspect Token Header, Payload & Claims
Decode JSON Web Tokens online for free. Inspect header, payload claims, exp/iat timestamps, and signature segments — 100% in-browser, nothing leaves your device.
Token Algorithms will print here...
Token claims & payload dataset will print here...
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret )
How JWT Decoding Works
From an opaque base64url string to readable claims in three direct steps.
Paste the Token
Drop the full three-segment token — header.payload.signature — into the input box, or load the bundled sample token to explore the layout.
Read the Segments
The debugger base64url-decodes the header and payload instantly, color-coding the algorithm block, claim set, and signature buffer.
Check the Clock Claims
Review exp, iat, and nbf converted into your local timezone, then copy any segment as clean JSON for tests and bug reports.
Utilvo In-Browser vs Cloud JWT Debuggers
Why token inspection belongs on your device — and what the trade-offs actually are.
| Feature | Utilvo In-Browser | Cloud Decoder Sites |
|---|---|---|
| Token Residency | Decoding never leaves your device — zero upload | Tokens are POSTed to remote servers |
| Credential Safety | Safe for staging and internal audience tokens | Bearer tokens transit third-party infrastructure |
| Turnaround Latency | Instant — decode on every keystroke | Network round-trip per inspection |
| Audit Trail | Nothing logged, nothing retained | Server-side request logs may persist |
| Offline Capability | Works fully offline once the page is loaded | Requires a live connection per token |
Engineering Notes on Token Anatomy
What actually happens when a JSON Web Token is decoded — and what decoding can never prove.
Base64url, Not Base64
JWT segments use the URL-safe alphabet: − becomes - and + becomes _, usually without padding. The decoder normalizes these characters before atob, which is why tokens that fail in quick scripts parse fine here.
Three Segments, Three Meanings
The first dot-separated segment is the header (alg, typ, kid), the second is the claim payload (sub, iss, exp, and custom keys), and the third is the raw signature buffer — displayed verbatim, never decoded as text.
Decoding ≠ Verification
Anyone can decode a JWT — the payload is only base64url-encoded, not encrypted. Authenticity comes solely from verifying the signature with the secret or public key on your server. Never trust a decoded claim until that check passes.
Epoch Timestamps Made Human
NumericDate claims like exp and iat are seconds since the Unix epoch. The debugger converts them to your local timezone so expired-token debugging stops being mental arithmetic.
Pre-Flight Checklist for Token Inspection
Run through these checks whenever a JWT misbehaves in your application.
Count the Segments
A valid JWT has exactly three dot-separated parts. Two segments mean a truncated copy; four mean a JWS nested inside a JWE.
Match alg to Your Keys
Confirm the header alg is the algorithm your verifier expects — alg-confusion attacks rely on servers accepting the wrong family.
Check exp Against Clock Skew
Compare exp with your server clock, allowing a small leeway window; a "valid" token on one machine can be expired on another.
Verify Server-Side
Decoding shows structure, not truth. Validate the signature and standard claims (iss, aud, azp) in your backend before acting on them.
Standard JWT Claims Reference
The registered claim names defined by RFC 7519 that the debugger highlights most often.
| Claim | Type | Meaning | Validated By | Tool Support | Common Gotcha |
|---|---|---|---|---|---|
| iss | String | Issuer that created and signed the token | Backend allow-list | Displayed | Trailing-slash mismatches between environments |
| sub | String | Subject — usually the user or service ID | Backend authz checks | Displayed | Assuming it equals a database UUID |
| aud | String | Array | Intended recipient audience | Backend audience check | Displayed | Multi-audience tokens failing strict validators |
| exp | NumericDate | Expiration time in epoch seconds | Backend + libraries | Converted to local date | Clock skew between services |
| iat | NumericDate | Issued-at timestamp | Informational | Converted to local date | Comparing iat against the wrong clock |
| nbf | NumericDate | Not-before time — token invalid earlier | Backend + libraries | Converted to local date | Tokens rejected right after minting |
Frequently Asked Questions
Everything you need to know before inspecting an access token.
1How do I decode a JWT token online for free?
Paste the raw token (the three dot-separated base64url segments) into the input box. The debugger instantly splits and decodes the header and payload, renders the signature segment, and converts exp/iat timestamps into human-readable dates — no registration or upload required.
2Does it decode all JWT signing algorithms?
Yes. Decoding is independent of the signature scheme, so HS256, RS256, ES256, PS256, and other standard algorithms all work — the alg claim is shown from the header, and the signature segment is displayed as-is.
3Does the decoder verify the signature?
No. Decoding is a plain base64url transformation and does not prove the token is authentic. Verification requires the secret or public key and must happen in your backend. Use this tool to inspect structure and claims, then validate the signature server-side before trusting any claim.
4Is it safe to paste a production token here?
Yes — the token is decoded entirely inside your browser and is never transmitted, logged, or stored. Still, treat bearer tokens as credentials: prefer decoding short-lived test tokens, and revoke or let expire anything you paste from a live environment.
5What do the exp, iat, and nbf claims mean?
exp is the expiration time after which the token is invalid, iat is the moment it was issued, and nbf is the earliest time it is valid — all expressed as seconds since the Unix epoch. The debugger converts each into a readable date in your local timezone.
6Why does my token show as invalid or fail to decode?
Most failures come from truncated tokens (copied without the final segment), added whitespace or quotes, or a malformed base64url payload. A JWT must have exactly three dot-separated segments; re-copy the full token and the decoder will parse it.
Continue with Adjacent Developer Utilities
Discover complementary formatting, inspection, and conversion utilities for your auth workflow.