JWT decoder
A JWT is a bearer credential — whoever holds it can act as you. This decodes it in your tab and makes no request at all, which matters more here than on any other page: pasting a live token into a site that transmits it hands that site a working login.
Header, claims and expiry, decoded and formatted. Signature verification is deliberately not offered, for reasons worth reading below.
Nothing is transmitted. Open the Network tab before you paste and watch nothing happen.
The payload is not encrypted, and people are surprised by that
A JWT has three parts separated by dots: a header, a payload and a signature. The first two are base64, which is an encoding — a way of writing bytes as text — and not encryption. Anyone holding the token can read every claim in it, without a key and without a tool.
The signature does not hide the contents. It proves the contents have not been altered since they were signed. Those are completely different guarantees, and confusing them is how personal data ends up in a token that gets logged, cached and forwarded.
Why this will not verify signatures
Verification requires the signing key. For an HMAC algorithm that key is a shared secret — the same value used to create valid tokens. Anyone who has it can mint a token claiming to be anybody.
A page that asks you to paste that in has asked for the keys to the whole system, and there is no way for you to verify what it did with them. So this does not offer the feature rather than offering it safely, because there is no safe version of it on a website. Verify signatures in your own code, or in a tool running on your own machine.
The claims worth knowing
| Claim | Means |
|---|---|
iss | Issuer — who minted it |
sub | Subject — usually the user id |
aud | Audience — who it is for, and who should reject it |
exp | Expiry, in seconds since 1970 |
nbf | Not valid before this time |
iat | Issued at |
jti | A unique id, so a token can be revoked individually |
alg: none, the oldest trick
The header names the algorithm, and the specification includes none for unsecured tokens. The
attack writes itself: take a valid token, rewrite the claims to say you are an administrator, set the algorithm
to none, drop the signature. A library that trusts the header will accept it.
The fix is that a verifier must decide which algorithms it permits and reject everything else, rather than
asking the token what to do. If you see none in something you did not create yourself, that is
worth looking into.
Questions
Is it safe to paste a JWT into a website?
Generally no, and that is the reason this page exists. A JWT is a bearer credential — whoever holds it can act as you until it expires. Pasting one into a site that sends it to a server hands that server a working login. This page decodes it in your tab and makes no request at all, which you can confirm with the Network tab open and watch nothing leave.
Can you verify the signature?
No, deliberately. Verifying requires the signing key, and a website is the last place anyone should paste one — the signing key does not just check tokens, it mints them. Decoding shows what the token says, which is exactly what any holder of it can already read.
Is the payload of a JWT encrypted?
No. It is base64-encoded, which is an encoding and not encryption — anyone with the token can read every claim in it. This surprises people regularly, and it is why putting anything sensitive in a JWT payload is a mistake. The signature protects the token from being altered, not from being read.
What do iat, exp and nbf mean?
They are the standard time claims, all in seconds since 1970. iat is when the token was issued, exp when it stops being valid, and nbf the time before which it should be rejected. This page converts all three to readable dates and tells you whether the token has expired.
What does "alg: none" mean?
It means the token claims to need no signature, and it is one of the oldest attacks on JWT: an attacker takes a valid token, rewrites the claims, sets the algorithm to none and strips the signature. Any library that honours it will accept the forgery. A correctly configured verifier rejects none outright.
Why is my token rejected when it decodes fine here?
Decoding and accepting are different tests. A token can be perfectly well-formed and still be refused for having expired, for being signed with a key the server has rotated away from, for the wrong audience or issuer claim, or for an algorithm the server does not permit. This page shows the contents; only the server knows its own rules.
What BriskFile will not do to you
-
Your files never leave your device
Every conversion runs in your browser. Open DevTools, watch the Network tab, and you will see no upload — because there is not one.
-
No account, no email, no watermark
Nothing to sign up for and nothing stamped on your images. There is no step between choosing a file and getting it back.
-
No limits at the download button
No daily cap, no file counter, no "upgrade to download". If the tool starts a job, it finishes it.
-
Checkable, not just claimed
Open the Network tab and convert something — nothing goes out. Or load the page, disconnect, and watch it keep working: the tool is already on your machine, and your file never leaves it.