Validators
JWT Decoder
Paste JWT on the left, hit Run, copy a pass/fail with a reason, not a shrug. No Node, no pip, no Docker for a five-minute job. That is the jwt decoder.
Drop a file on the left. Drafts stay in this browser. Shortcut: Ctrl or Cmd + Enter to run.
How this jwt decoder works
- Paste or drop a .txt file into the input on the left.
- Flip options if you see them (comments, indent, case). Defaults are the safe ones.
- Hit Run, or Ctrl / Cmd + Enter. Leave “Process on server” off unless you mean it.
- Read the status line, then copy, download, or jump to a related tool.
What this jwt decoder is for
The file is already in front of you. You need to validate it without opening a whole IDE profile. Paste, run, copy. Typical timing: before you save a config, publish an API sample, or paste a token into docs.
You walk away with a pass/fail with a reason, not a shrug.
What it will not pretend to be
This is not a full W3C HTML auditor or a cryptographic verifier unless the page says so. Decoding a JWT is not verifying it. Anyone can read Base64URL payload claims. Signature checks belong on a server with the key.
By default nothing leaves the tab. Tick “Process on server” only if you want to compare results or use gzip numbers that match the server library.
A practical way to use it
Drop a .txt file onto the input or paste. Flip options if they are there. Run. Read the status line. Copy or download. Drafts stay on this device so a refresh does not punish you.
When you are done, hop a related tool instead of starting over: minify and beautify toss the file back and forth, format and validate often share a parser, convert wants valid input first.
The small print that saves a round-trip
Decoding a JWT is not verifying it. Anyone can read Base64URL payload claims. Signature checks belong on a server with the key.
You searched “jwt decoder online.” You got an editor, not a login wall. That is the deal.
Frequently asked questions
What is inside a JWT?
Three Base64URL parts: header, payload, signature. eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJkZXYifQ.sig decodes the middle to {"sub":"dev"}. Reading claims is not verifying the signature.
Does decoding a JWT prove it is authentic?
No. Anyone can mint a fake payload and Base64 it. Verification needs the secret or public key on a server. Treat a decoded token like a postcard you found on the floor.
Fun fact?
Fun fact: alg: none was a real vulnerability class — implementations that trusted the header’s algorithm. Never let the token pick none. Decoder UIs that highlight alg exist because of that history.
What are typical claims?
sub (who), iat (issued at), exp (expiry), iss (issuer), aud (audience). Times are usually Unix seconds. If exp is in 2017, the token is a fossil even if it still “decodes.”
Why is the signature gibberish?
It is binary HMAC or RSA bytes, Base64URL-encoded. You cannot “read” it. You can only recompute it with the key and compare. A decoder that says “valid” without a key is lying or confused.
Example of a header?
{"alg":"HS256","typ":"JWT"} is common. If you see "alg":"none" or an unexpected kid, stop and ask why. The header is JSON too — same pretty-print rules.
Can I decode the token in a URL?
Tokens in query strings leak via logs and Referer. Prefer Authorization: Bearer. Decoding still works either way; leaking is the separate disaster.
JWT vs opaque session cookies?
JWT is self-contained claims. Opaque sessions store the truth on the server. Decoder tools exist because JWTs are readable. That readability is a feature and a foot-gun.