JWT 디코더

The three parts of a JSON Web Token

A JWT is a compact, URL-safe string made of three sections joined by dots: header.payload.signature. The header and payload are JSON objects that have been Base64URL-encoded; the signature is a cryptographic stamp computed over the first two parts. This decoder splits the token on its dots, decodes the header and payload back into readable JSON, and lays them out side by side so you can inspect exactly what a token is claiming. Crucially, the parts are encoded, not encrypted — anyone holding the token can read its contents, which is why you should never put secrets inside a JWT payload.

How the decoding actually works

Standard Base64 uses + and / and pads with =, but those characters are unsafe in URLs, so JWTs use Base64URL: + becomes -, / becomes _, and padding is stripped. Before decoding, this tool reverses that — swapping - back to + and _ back to /, re-adding = padding until the length is a multiple of four — then runs the browser's native atob() and parses the result as JSON. If the token doesn't have exactly three dot-separated parts, or a part isn't valid Base64URL JSON, you get a clear error instead of a silent failure.

A worked example

Decoding the classic sample token, the header reads:

• {"alg":"HS256","typ":"JWT"} — signed with HMAC-SHA256, type JWT.

And the payload:

• {"sub":"1234567890","name":"John Doe","iat":1516239022}

Here sub (subject) identifies the user, name is a custom claim, and iat (issued-at) is a Unix timestamp. The decoder turns that timestamp into a human-readable local date and surfaces it as a badge, so you immediately see when the token was minted without doing the epoch math yourself.

The claims that matter — and the status badges

JWTs use short, registered claim names. The decoder highlights the important ones as colored badges:

The expiry check compares exp against the current time on your device. If exp is in the past you'll see an "Expired" warning; otherwise a "Valid" badge — but read that carefully: it means "not yet expired," not "signature verified."

Why this tool does not verify the signature

The signature is what proves a token hasn't been tampered with, and checking it requires the secret (for HMAC algorithms like HS256) or the issuer's public key (for RSA/ECDSA algorithms like RS256). A decode-only inspector has neither, so it deliberately stops at reading the header and payload. The practical takeaway: never trust the contents of an unverified token in production code. A famous attack swaps the algorithm to none or downgrades RS256 to HS256; only real signature verification on your server catches that. Use this tool to understand a token, and your backend library to trust one.

Practical use cases

• Debugging auth failures. Paste the token your app received and check whether exp has passed or aud/iss don't match what the API expects.
• Inspecting scopes and roles. Many APIs encode permissions as custom claims; decoding shows precisely what access a token grants.
• Confirming clock issues. If a token looks valid but is rejected, comparing iat/exp to real time often reveals a server clock skew problem.
• Learning the format. Seeing the raw segments next to the decoded JSON makes the structure click.

Common mistakes

• Pasting a token with surrounding quotes or a Bearer prefix. Strip those — the decoder expects the bare three-part string.
• Assuming "Valid" means secure. It only means unexpired. Tampering is invisible without signature checks.
• Putting sensitive data in the payload. Because it's only encoded, treat everything in a JWT as public.
• Ignoring time zones. The badges use your local time; the underlying claims are UTC Unix seconds.

Privacy

All decoding happens in your browser with atob() and JSON.parse() — your token is never sent to a server, logged, or stored. Because signature verification would require your keys, that step is intentionally absent, which also means nothing secret ever needs to leave your device.