Skip to tool
Security

JWT Debugger

Decode, verify, and sign JSON Web Tokens while keeping keys in the browser.

Online tools Pricing
Input0 characters
Result0 characters
Ready

Prefer a native workflow?

Keep JWT Debugger one shortcut away.

DevSexy for Mac puts the same private workflow in a focused desktop app, with global shortcuts and no browser tab to manage.

Global shortcutOffline-readyLocal processing
Try the Mac app free

This browser tool remains free.

Every token is evidence · every verdict names its proof

Decoded is not verified.

A readable header and payload prove only that two Base64URL segments contain JSON. Trust arrives later—from an expected algorithm, the right key, a valid time window, and your issuer/audience policy.

01Decoded · untrusted

Header

{ "alg": "HS256", "typ": "JWT" }
02Decoded · untrusted

Payload

{ "sub": "123", "aud": "devsexy-api", "exp": 1766073600 }
03Opaque until verified

Signature

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decode and verify a public test token

Both examples use the same public HS256 fixture. Compare a readable payload with verification under an explicit algorithm, key, issuer, audience, and time.

Loading an example replaces the token and options, including the key. This public test fixture grants no access; never use its key for a real application.

Read claims without trusting the signature

Decode · HS256 · no key. The fixture expired in 2024; decoding still displays its claims.

Input

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLnRlc3QiLCJhdWQiOiJkZXZzZXh5LWRlbW8iLCJuYmYiOjE3MTAwMDAwMDAsImV4cCI6MTcxMDAwMzYwMH0.gAP2idduo9EHFyecHJohqwzl7F3g8Bvp3xDvVWyCHsI

The subject is demo-user. The result explicitly says the signature was not checked.

"sub": "demo-user"
Signature: not checked — decoding never proves authenticity

Verify at a fixed time inside the validity window

Verify · HS256 · public test secret: devsexy-public-example-key-do-not-use-in-production · issuer https://issuer.example.test · audience devsexy-demo · verification time 1710001800 epoch seconds · zero clock skew.

Input

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLnRlc3QiLCJhdWQiOiJkZXZzZXh5LWRlbW8iLCJuYmYiOjE3MTAwMDAwMDAsImV4cCI6MTcxMDAwMzYwMH0.gAP2idduo9EHFyecHJohqwzl7F3g8Bvp3xDvVWyCHsI

Verification passes at the fixed historical instant. Clear the verification time to check today: this fixture is expired. This does not prove current authorization.

Signature: verified with the selected HS256 key, claim, and clock policy
Issuer policy: https://issuer.example.test
Audience policy: devsexy-demo

Trust ladder

Each rung proves only the next fact.

01

Compact shape

Exactly three non-empty URL-safe segments

02

JSON decoded

Header and claims are readable—not trustworthy

03

Signature verified

Integrity under an expected algorithm and key

04

Time accepted

exp / nbf with an explicit clock-skew policy

05

Issuer & audience accepted

Application configuration matches the claims

06

Domain policy accepted

Roles, tenant, scope, nonce, and revocation rules pass

Algorithm / key contract

The token’s alg field is input, not policy.

HS256 / 384 / 512Shared secret

Signer and verifier know the same key

Supported in this workbench

RS256 / 384 / 512 · PS256 / 384 / 512RSA PEM

PKCS#8 signs; X.509, SPKI, or PKCS#8 verifies

Supported; key and algorithm must match

ES256 / 384 / 512EC PEM

PKCS#8 signs; X.509, SPKI, or PKCS#8 verifies

Supported; curve and algorithm must match

JWK / JWKS / none / EdDSANot accepted

No remote key lookup or unsecured JWT

Outside this workbench’s allowlist

NumericDate clock

JWT time claims are epoch seconds.

NOW · 1,716,073,600

iat1,716,070,000Issued 60 minutes ago
nbf1,716,072,700Active for 15 minutes
exp1,716,075,400Expires in 30 minutes

Milliseconds accidentally supplied as seconds land tens of thousands of years away. Clock skew is a deliberate verifier setting, not a reason to ignore expiry.

Issuer & audience checkpoint

A valid signature from the wrong authority is still rejection.

isshttps://id.example.test/

Exact trusted issuer match

aud["devsexy-api", "account"]

At least the required audience under your policy

tenantproduction-eu

Private claim checked by domain policy

scopetools:read

Authorization still belongs to the resource server

Debugger threat desk

Handle the debugger like a bearer-token workbench.

Bearer exposure

HIGH

Tokens in URLs, screenshots, logs, clipboard history, and tickets can be replayed.

Weak HMAC secret

HIGH

Short or guessable shared secrets can be brute-forced offline.

Algorithm confusion

CRITICAL

Pin an allowlist; never let attacker-controlled alg select policy.

Untrusted kid / JWK URL

HIGH

Never turn header key hints into unrestricted file or network lookup.

Signing in a browser

REVIEW

Use test keys only; production signing keys belong in controlled infrastructure.

Inspect the evidence around a token

Decode a standalone Base64URL segment

Use the Base64 tool for encoded text that is not a complete three-part JWT.

Convert exp, nbf, or iat from seconds

Check the human-readable UTC instant without confusing seconds with browser milliseconds.

Inspect request URL encoding

Review query escaping separately; a URL parser does not authenticate a bearer token.

Debug test tokens locally on your Mac

Use the offline toolbox for repeated inspection with test credentials.

Direct answer

What is JWT Debugger?

Decode JWT headers and claims online, verify supported signatures in your browser, inspect NumericDate fields, and separate cryptographic proof from application policy.

What can it do?

  • Decode
  • Verify
  • Sign

How to use JWT Debugger

  1. 01

    Decode a test token first

    Review the three compact segments, algorithm, and claims. Decoding does not validate the signature or accept expired tokens for use.

  2. 02

    Set the verification policy

    Select the expected algorithm and provide the matching local key. Set issuer, audience, clock skew, and optional assertion values from application policy rather than trusting the token’s own claims.

  3. 03

    Interpret the result at the chosen time

    An empty verification time uses the current clock. The example deliberately uses a fixed historical instant. Signature and claim checks do not determine revocation, tenant access, or resource authorization.

Frequently asked questions

Can an expired or altered JWT still be decoded?
Yes. Decoding reads the JSON header and claims without verifying authenticity or enforcing expiry. Use Verify with the expected algorithm and key to check integrity and configured claim policy.
Why does the example verify even though its exp is in 2024?
The example sets verification time to 1710001800 seconds, inside its historical validity window. Clear that field to use today’s clock. A historical verification result does not make this token valid now.
Which keys and checks does this JWT debugger support?
The workbench supports HS256/384/512 secrets, RSA RS/PS256/384/512 and EC ES256/384/512 PEM keys. It can check configured issuer, audience, time, and custom assertions. It does not fetch remote JWKS or check revocation; JWK input, EdDSA, and alg none are outside its allowlist.