JWT Encoder & Decoder

About JWT

A JSON Web Token is three Base64url segments: a header naming the algorithm, a payload of claims, and a signature over the first two. The token is shown with each segment in its own colour and the decoded header, payload and signature underneath in the matching colour, so the eye pairs them without reading.

Every claim is listed with what it means and, for the time claims, what it says about now: exp becomes an absolute timestamp and “expires in 12 minutes”, and the token's overall standing — valid, expired, or not valid yet — is reported alongside. Claims an issuer invents are listed too, marked as its own.

Signatures are checked with Web Crypto. HS256, HS384 and HS512 take the shared secret; RS, PS and ES tokens take the issuer's public key as PEM, the block that begins -----BEGIN PUBLIC KEY-----. The signing mode does the reverse: give it claims, an algorithm and either a secret or a PKCS#8 private key, and it writes a token. Both directions run entirely in this tab, which matters because a JWT is usually a live credential and a signing key always is.

Beside the decoded token there is a grade, and it answers a different question from the panels above it: not what the token says, but whether it should be accepted. The two disagree more often than people expect — a token can decode perfectly, read sensibly, and still be one an attacker wrote. Anything that makes it unacceptable outright reaches nothing at all: alg: none, a signature that does not verify, an expiry in the past, or a secret sitting in the payload. And without a key the grade is capped and labelled unverified, because a mark this cannot justify would be worse than no mark.

Where it helps

• Decodes header and payload without sending the token anywhere — important, because a JWT is usually a live credential.
• Reads tokens with zip: DEF, which almost nothing else online will open, and can sign them too — with a warning about what you have made.
• Grades the token on whether it should be accepted, with every point taken off written out as a line you can argue with.
• Catches a password or an API key sitting in the payload — base64 is not encryption, and that is the mistake this format invites.
• Verifies HS, RS, PS and ES signatures: a shared secret for HMAC, a PEM public key for the rest.
• Explains every claim and turns the time claims into both a timestamp and a plain-language “expires in…”.
• Signs new tokens as well as reading them, with the key never leaving the browser.
• Accepts a token with or without the Bearer prefix.
• Wraps a finished token in gzip and Base64 for a cookie, a header or a URL — and unwraps one automatically on the way back in, working out from the bytes which compression it was.
• Measures what the wrapping actually cost rather than assuming it helped: a JWT is already Base64, and on a short one the wrapper makes it longer.

Limits

• A decoded token is not a trusted token: without signature verification the claims are just text an attacker can edit.
• Public keys have to be pasted as PEM; a JWKS endpoint is not fetched, because nothing here goes to the network.
• EdDSA is not supported, since browsers do not agree on Ed25519 in Web Crypto yet.
• Encrypted tokens (JWE, five segments) are not supported — this reads signed JWS tokens.
• Wrapping a token for transport is a convention between two ends, not a standard: nothing in the JWT specifications describes it, so whatever receives it has to know to unwrap it.
• Wrapping makes a short token bigger, not smaller. It only pays once there are enough claims to have something worth compressing.

Frequently asked questions

What is zip: DEF, and should I use it?

It DEFLATEs the claims before they are encoded. RFC 7516 defines it for encrypted tokens (JWE); no RFC defines it for signed ones, and most libraries will fail to read a signed token that uses it. It is supported here in both directions because such tokens do exist and nothing else online opens them. Sign with it only where you know the other end expects it — and check the result, because on a small claim set DEFLATE's overhead makes the token longer, not shorter.

What is the difference between zip and wrapping for transport?

What they compress, and who has to understand it. zip compresses the claims *inside* the token: the payload segment is no longer plain JSON, the header declares zip: DEF so a reader knows, and a library that does not implement it cannot read the token at all. Wrapping leaves the token completely alone — an ordinary JWT is produced, and then the whole string is gzipped and Base64'd for transport. Whatever receives it decompresses it back into the identical token before verifying anything, so every library reads it. If you need a big token to fit in a cookie or a URL, wrapping is almost always what you want; zip is for the rare case where the other end specifically expects it.

My wrapped token came out longer than the original. Why?

Because a JWT is already Base64 text, so there is less repetition to remove than it looks, and both steps cost something: gzip adds about 18 bytes of header and trailer, and Base64 then adds a third again on top of whatever is left. Below roughly 200 characters that overhead is bigger than anything compression recovers. The result reports the size in both directions rather than assuming it helped — if it grew, send the plain token.

Do I have to tell it how a token was wrapped before decoding?

No. Paste the blob and it works it out: gzip and zlib each announce themselves in their first two bytes, and raw DEFLATE is tried once those are ruled out. A plain token passes straight through untouched, so nothing is guessed at when there is nothing to guess. The result says which one it found.

Is it safe to paste a production token here?

The decoding happens in your browser and nothing is uploaded. Treat the token as a live credential anyway: anyone looking at your screen can read it.

How do I verify an RS256 or ES256 token?

Paste the issuer's public key as PEM in the key field — the block beginning -----BEGIN PUBLIC KEY-----. It is the same key their JWKS endpoint publishes, in the form Web Crypto reads.

What key does signing need?

HS256, HS384 and HS512 sign with the shared secret. RS, PS and ES sign with a PKCS#8 private key: the PEM that begins -----BEGIN PRIVATE KEY-----.

The token decodes but says “Signature INVALID”. What now?

Either the secret is wrong, or it needs decoding first — some frameworks store the signing key Base64 encoded. Check the exact bytes your issuer signs with.

What does “Expired” actually compare against?

The exp claim against your computer's clock. A machine with a skewed clock will disagree with the server that issued the token.

Related tools

• Base64 — Encode or decode UTF-8 text and URL-safe Base64
• HMAC Generator — Keyed message authentication codes
• Hash Generator — SHA-2, SHA-3, BLAKE and legacy digests, in any encoding
• Unix Timestamp — Convert between timestamps, ISO dates and local time
• Base32 — Encode or decode Base32 in the RFC 4648, extended hex and Crockford alphabets
• Base58 — Encode or decode Base58, and verify the Base58Check checksum an address carries

More Encoders & Decoders tools

• Base64 — Encode or decode UTF-8 text and URL-safe Base64
• Base32 — Encode or decode Base32 in the RFC 4648, extended hex and Crockford alphabets
• Base58 — Encode or decode Base58, and verify the Base58Check checksum an address carries
• URL Encoder — Percent-encode components or whole URLs
• HTML Entities — Escape and unescape HTML entities
• Punycode — Convert internationalised domain names to and from their ASCII form
• Unicode Converter — Escape, unescape and inspect code points
• Unicode Inspector — Analyse every character: category, script, block and encoding
• Number Base Converter — Binary, octal, decimal and hexadecimal, with the bits explained
• Hex and Text Converter — Text to hexadecimal bytes and back, with a dump
• Gzip Compressor and Decompressor — Compress and expand gzip, zlib and raw deflate