JWT decoder

Paste any JSON Web Token and read the decoded header and payload as pretty-printed JSON. The token itself is the input; the decoded JSON is the output. The decoder splits the three dot-separated segments, base64url-decodes the first two, and pretty-prints them. The third segment (the signature) is not verified by this tool: decoding only reveals what is inside the token, not whether it is valid. Nothing uploads.

Input
Line 1:1 LF cloud_done Saved locally
Result JWT Decoder
0 lines 0 chars

JWT decoding, header and payload, no signature check

A JSON Web Token (RFC 7519) is three base64url-encoded segments joined by dots: header.payload.signature. The header declares the signing algorithm and token type; the payload carries the claims (subject, expiry, custom fields); the signature is an HMAC or RSA signature over the first two segments using a secret or key. TextResult splits on the dots, base64url-decodes segments one and two, parses each as JSON, and pretty-prints the result.

Decoding is not verifying. This tool reads the contents of the token, but it does not check the signature against any key. A token with garbage in the signature segment still decodes the same as a real one. To verify, you need the issuer's secret (HS256) or public key (RS256) and a JWT library on a trusted server. Verification is the security step; decoding is the inspection step.

Base64url is the URL-safe variant of base64: - replaces +, _ replaces /, and padding = is usually omitted. The decoder swaps - back to + and _ back to / before calling the standard base64 decoder, so JWTs from any spec-compliant issuer parse the same. If the input does not split into at least two segments, or if either segment is malformed, the decoder returns [not a JWT] or [invalid JWT].

How to use jwt decoder

  1. 1Paste your JWT (the full header.payload.signature string) into the input panel.
  2. 2The decoded header and payload appear in the output panel as pretty-printed JSON.
  3. 3The signature is shown as part of the original token but is NOT verified.
  4. 4Use the result to inspect claims, expiry (exp), issuer (iss), and the algorithm in the header.
  5. 5For real verification, run the token through a JWT library on a trusted server with the issuer's key.

Keyboard shortcuts

Drive TextResult without touching the mouse.

Shortcut Action
Ctrl FOpen the find & replace panel inside the input Plus
Ctrl ZUndo the last input change
Ctrl Shift ZRedo
Ctrl Shift EnterToggle fullscreen focus on the editor Plus
EscClose find & replace, or exit fullscreen
Ctrl KOpen the command palette to jump to any tool Plus
Ctrl SSave current workflow draft Plus
Ctrl PRun a saved workflow Plus

What this tool actually does

Splits and base64url-decodes the three segments

The input is split on .. The first two segments are base64url-decoded (with - -> + and _ -> / normalisation), then parsed as JSON. The third segment is the signature; the decoder does not parse or verify it.

Pretty-prints header and payload

Output uses JSON.stringify(obj, null, 2), so the result is two-space indented, line-broken JSON ready to read. Header is shown first, then payload. Common claims include sub, iss, aud, exp, iat, plus any custom claims the issuer added.

Does NOT verify the signature

Decoding answers "what is inside this token?", not "is this token valid?". A tampered token decodes the same as a fresh one if the contents are still valid base64url JSON. Real verification needs the issuer's secret or public key and a JWT library; this tool is for inspection only.

Handles missing padding and URL-safe characters

Standard JWTs strip the trailing = padding and use - / _ in place of + / /. The decoder swaps the URL-safe characters back before calling atob, so tokens from any compliant library parse correctly.

Graceful failure on bad input

A string with fewer than two segments returns [not a JWT]. A string where either segment is not valid base64 or not valid JSON returns [invalid JWT]. The error appears in the output panel rather than throwing.

Worked example

The header declares HS256 (HMAC-SHA256), the payload carries the standard sub and iat claims plus a custom name. The third segment SflKxw... is the signature and is shown but NOT verified.

Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Output
Header:
{
  "alg": "HS256",
  "typ": "JWT"
}

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

Settings reference

Behaviour Effect on output
Three-segment input Split on . into header, payload, signature.
Header and payload decode Base64url decoded, parsed as JSON, pretty-printed with 2-space indent.
Signature segment Shown only by way of the raw input. NOT verified, NOT decoded.
URL-safe characters - -> + and _ -> / before base64 decode.
Missing padding Tolerated. JWTs typically omit trailing =.
Fewer than two segments Returns [not a JWT].
Bad base64 or non-JSON Returns [invalid JWT].

FAQ

Does this tool verify the JWT signature?
No. Decoding reads the header and payload but does not check the signature. To verify, you need the issuer's secret (for HS256) or public key (for RS256/ES256) and a JWT library running on a trusted server. Verification is the security step; this tool is for inspection.
Can someone tamper with a JWT and have it still decode?
Yes. Anyone can change the payload, re-base64url-encode it, and the result still decodes. What they cannot do without the signing key is produce a matching signature, so a tampered token will fail server-side verification. Decoding alone gives no security guarantees.
What do iat, exp, and sub mean?
Standard claims from RFC 7519. iat is "issued at" (Unix seconds), exp is "expiry" (Unix seconds, server should reject the token after this time), sub is "subject" (typically the user ID). Issuers also add custom claims, which appear alongside the standard ones in the payload.
Why does my token return [invalid JWT]?
Either the header or payload segment is not valid base64url, or it is valid base64url but the decoded bytes are not valid JSON. Common cause: a stray space or newline broke a segment in half during paste. Re-copy the full token and paste again.
Is the token sent anywhere?
No. Decoding runs entirely in your browser. Nothing is uploaded, nothing is logged. Safe to inspect tokens that contain user data.