JWT Decoder: Decode JSON Web Tokens (JWS) Online

This page counts compact segments first, then base64url-decodes only a three-part JWS (RFC 7515 / RFC 7519). Compact JWE (RFC 7516) is five segments and is rejected — the ciphertext is not decrypted. Decode is not HMAC, RSA, ECDSA, or JWKS verification, and it does not check exp or nbf. For the longer comparison, see Compact JWS vs JWE: Decode Is Not Verify.

The sample compact JWS decodes to header {"alg":"HS256","typ":"JWT"} and payload sub user-42, name Ada Lovelace, iat 1516239022 → 2018-01-18T01:30:22.000Z, exp 1516242622 → 2018-01-18T02:30:22.000Z. Those NumericDate seconds are display-only — the same POSIX-seconds clock as Unix timestamp Seconds mode, not an expiration check. The third segment bm90LWEtcmVhbC1zaWduYXR1cmU is ASCII not-a-real-signature, not an HMAC over the first two parts. A leading Bearer prefix and interior whitespace are stripped before the count. JOSE JSON serialization (JWS or JWE objects, not compact dots) is out of scope. Encoding UTF-8 as RFC 4648 §5 belongs on Base64url, not this decoder.

The snippets below split a compact JWS (RFC 7515 / RFC 7519), base64url-decode the first two segments (RFC 4648 §5), and parse them as JSON — the same decode-only path this page uses. They do not verify HMAC, RSA, or ECDSA signatures, and they do not check exp or nbf. For why decode is not verify, see Compact JWS vs JWE: Decode Is Not Verify.

const token =
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjQyNjIyfQ.bm90LWEtcmVhbC1zaWduYXR1cmU';

const [headerSeg, payloadSeg] = token.split('.');
const header = JSON.parse(Buffer.from(headerSeg, 'base64url').toString('utf8'));
// { alg: 'HS256', typ: 'JWT' }

const payload = JSON.parse(Buffer.from(payloadSeg, 'base64url').toString('utf8'));
// { sub: 'user-42', name: 'Ada Lovelace', iat: 1516239022, exp: 1516242622 }

import base64
import json

def b64url_decode(segment):
    pad = '=' * ((4 - len(segment) % 4) % 4)
    return base64.urlsafe_b64decode(segment + pad)

token = (
    'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.'
    'eyJzdWIiOiJ1c2VyLTQyIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjQyNjIyfQ.'
    'bm90LWEtcmVhbC1zaWduYXR1cmU'
)
header_b64, payload_b64, _sig = token.split('.')
header = json.loads(b64url_decode(header_b64))
# {'alg': 'HS256', 'typ': 'JWT'}

payload = json.loads(b64url_decode(payload_b64))
# {'sub': 'user-42', 'name': 'Ada Lovelace', 'iat': 1516239022, 'exp': 1516242622}

The third segment is the signature bytes, not JSON. That token's signature decodes to the ASCII string not-a-real-signature — reading it still does not prove the header or payload were signed. Use a JWT library with the issuer's key when you need verification.

POSIX cut -d. splits a compact JWS. GNU and BSD base64 decode RFC 4648 §4 (+ / /), not JWT's RFC 4648 §5 (- / _). JWT segments also omit = padding. This page's compact JWS happens to use only A–Z a–z 0–9 in all three segments, so the alphabet map is a no-op. The header is 36 characters (a multiple of 4); GNU coreutils 9.4 base64 -d writes {"alg":"HS256","typ":"JWT"}. The payload is 98 characters. The same command writes the claims JSON, then base64: invalid input (exit 1). Restore == first. The signature is 27 characters — it writes ASCII not-a-real-signature, then the same error; restore =. These commands do not verify HMAC, RSA, or ECDSA.

TOKEN='eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjQyNjIyfQ.bm90LWEtcmVhbC1zaWduYXR1cmU'

printf '%s\n' "$TOKEN" | cut -d. -f1 | base64 -d
# {"alg":"HS256","typ":"JWT"}

printf '%s\n' "$TOKEN" | cut -d. -f2 | base64 -d
# {"sub":"user-42","name":"Ada Lovelace","iat":1516239022,"exp":1516242622}
# base64: invalid input

printf '%s==\n' \
  'eyJzdWIiOiJ1c2VyLTQyIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjQyNjIyfQ' \
  | base64 -d
# {"sub":"user-42","name":"Ada Lovelace","iat":1516239022,"exp":1516242622}

printf '%s' 'eyJ4IjoiPj4_In0' | tr -- '-_' '+/' \
  | awk '{n=(4-length($0)%4)%4; printf "%s",$0; for(i=0;i<n;i++) printf "=";}' \
  | base64 -d
# {"x":">>?"}

printf '%s\n' "$TOKEN" | cut -d. -f1 | basenc --base64url -d
# {"alg":"HS256","typ":"JWT"}

printf '%s==\n' \
  'eyJzdWIiOiJ1c2VyLTQyIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjQyNjIyfQ' \
  | basenc --base64url -d
# {"sub":"user-42","name":"Ada Lovelace","iat":1516239022,"exp":1516242622}

printf '%s' 'Pj4-Pz8_' | basenc --base64url -d
# >>>???

printf '%s\n' "$TOKEN" | jq -Rr 'split(".") | .[0],.[1] | @base64d'
# {"alg":"HS256","typ":"JWT"}
# {"sub":"user-42","name":"Ada Lovelace","iat":1516239022,"exp":1516242622}

printf '%s\n' 'eyJ4IjoiPj4_In0' | jq -Rr '@base64d'
# jq: error (at <stdin>:1): string ("eyJ4IjoiPj...) is not valid base64 data

printf '%s\n' 'eyJ4IjoiPj4_In0' \
  | jq -Rr 'gsub("-";"+") | gsub("_";"/") | @base64d'
# {"x":">>?"}

macOS ships BSD base64 — decode with -D (or -d on recent releases). OpenSSL 3.0 base64 -d -A on the unpadded payload writes the claims JSON without the closing } and exits 0 — pad first. A five-segment compact JWE still has a first and second field; cut -d. -f1,2 prints them. This page rejects five segments and does not decrypt. For why decode is not verify, see Compact JWS vs JWE: Decode Is Not Verify. Encoding UTF-8 as RFC 4648 §5 belongs on Base64url, not this decoder.