tooloora

JWT Decoder — read tokens locally, signature NOT verified

Decode JWT header and payload to readable JSON with exp/iat/nbf as dates and an expired badge. Runs entirely in your browser, because tokens must never reach a third-party server.

Runs locally — nothing is uploaded

Signature is NOT verified

This tool only decodes. It cannot tell whether the token is genuine and unmodified – that check needs the issuer's key and belongs on the server.

The token stays in your browser – it is never sent to any server.

Decode and read JWTs locally

Paste a JSON Web Token and see the header and payload as formatted JSON, the standard claims made human-readable (exp, iat and nbf as dates, with an expired badge) and the raw signature segment. One thing first, loud and clear: the signature is NOT verified, this tool only decodes. Everything runs in your browser, your token never leaves your device.

Why must a token never reach someone else's server?

A JWT is not harmless debug text but a live credential: whoever holds it can act as the named user against the API until it expires. Copying a production token into an online tool that transmits it to a server is the same as giving away your session. That is exactly why this tool decodes strictly locally: no request, no log, no third party. It also works offline.

How is a JWT structured?

Per RFC 7519 (May 2015) a JWT consists of three Base64url segments separated by dots: header (algorithm and type), payload (the claims) and signature. Base64url is a reversible encoding, not encryption; anyone can read header and payload without any key. So never put passwords or other secrets into claims. The signature makes tampering detectable for the verifier, but it hides nothing.

What do the standard claims mean?

RFC 7519 section 4.1 registers exactly seven claims: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at) and jti (token ID). The three time claims are NumericDates, seconds since the Unix epoch (January 1, 1970 UTC); the tool converts them into readable dates with relative time and marks expired tokens with a badge.

Why does this tool not verify the signature?

Because a serious check requires the issuer's secret or public key and belongs on the server that trusts the token. A decoder in the browser can only show what the token claims, not whether it is genuine. Tools that promise in-browser verification tempt you to paste the secret key, which is even more sensitive than the token itself. For debugging, decoding is enough; for trust decisions, never.

When the token cannot be decoded

The tool reports the failing segment individually: structure (not three dot-separated parts), header or payload, each distinguishing invalid Base64url from invalid JSON. Bearer prefixes and line breaks from log copies are removed automatically. If the error persists, the copy is usually truncated, or the value simply is not a JWT but an API key or an opaque session ID.

Frequently asked questions

Is my token uploaded to a server?

No, and for JWTs that is essential: a token is a live credential. Anyone who obtains it can impersonate you against the issuing API until it expires. Pasting tokens into online tools that transmit them to a server is effectively handing out your session. This decoder runs entirely in your browser, sends nothing anywhere and works offline.

Does this tool verify the signature?

No, deliberately not, and it says so prominently: the signature segment is displayed but never checked. Decoding only proves what the token claims, not that it is genuine or unmodified. Verification requires the issuer's secret or public key and belongs on the server that trusts the token. Never treat a decoded token as authenticated.

Why can anyone read my JWT without a key?

Because JWTs are encoded, not encrypted. Per RFC 7519 the header and payload are plain Base64url-encoded JSON, a reversible transport encoding that anyone can undo. The signature protects integrity, meaning tampering is detectable by the verifier, but it does not hide the contents. Never put secrets like passwords into JWT claims.

What do exp, iat, nbf, iss, sub and aud mean?

They are six of the seven registered claims from RFC 7519 section 4.1 (the seventh is jti, the token ID). exp is the expiration time, iat when the token was issued, nbf the moment before which it must not be accepted; all three are NumericDates, seconds since the Unix epoch, which this tool converts to readable dates. iss names the issuer, sub the subject, and aud the intended audience.

The tool says my token is broken. What now?

The error names the failing segment. A JWT must be three Base64url parts separated by dots: header.payload.signature. Common causes are truncated copies from logs, line breaks inside the token (this tool removes whitespace automatically), a missing segment, or an API key or opaque session ID that simply is not a JWT at all.

Related tools

Base64 Encode & Decode — local, UTF-8 safeEncode and decode Base64 (incl. URL-safe), UTF-8 correct, 100% in your browser.JSON Formatter & Validator — local, with error positionFormat, minify and validate JSON with exact error position, 100% in your browser.Hash Generator — SHA-256, SHA-512 & more, localSHA-1/256/384/512 checksums of text via Web Crypto, all live, 100% in your browser.