Security

JWT Inspector

Paste a JSON Web Token and read its header, payload, claims, expiry, and signature state at a glance. When you need to confirm a signature or generate a fresh token, the tool accepts HMAC secrets and RSA, ECDSA, or EdDSA keys, and runs everything in the browser without sending the token or key to a server.

  • Parsing, verification, and signing happen locally in the browser, with no upload
  • Header, payload, and signature are split automatically and rendered as readable JSON
  • Common HMAC, RSA, PS, ECDSA, and EdDSA algorithms verify whenever the right key material is provided
  • Expiry, issued-at, and not-before claims are shown as real dates to surface clock-skew issues quickly
tools/JWT Inspector
Optional

HMAC algorithms expect a shared secret. RSA, PS, ES, and EdDSA expect PEM or JWK material.

Waiting for input
Paste a token on the left and its header and payload will appear here right away.

Overview

Read tokens, verify signatures, and produce fresh test tokens in one place, with every operation running in the browser.

  1. 01

    Complete token decoding

    Splits the token into header, payload, and signature, then renders them as readable JSON without any manual Base64URL work.

  2. 02

    Multi-algorithm verification

    Supports HS256 through HS512, RS256 through RS512, PS256 through PS512, ES256 through ES512, and EdDSA whenever the right key is supplied.

  3. 03

    Human-readable timestamps

    Expiry, issued-at, and not-before values appear as real dates so clock skew and expiration problems stand out immediately.

  4. 04

    Generate signed tokens

    Edit the header and payload, choose an algorithm, paste a matching key, and a new token is produced as you type.

  5. 05

    Smart key detection

    Recognizes shared secrets, PEM public and private keys, X.509 certificates, and JWK objects, then imports them with the right method for the selected algorithm.

  6. 06

    Local processing only

    Tokens and keys stay in the browser. Nothing is sent to a server or third-party API while the tool is open.

How to use

Inspect mode is for existing tokens, sign mode is for new tokens you need for testing or debugging. Both share the same panel.

  1. 01

    Paste an existing token into inspect mode. The header and payload decode immediately.

  2. 02

    To confirm the signature, paste the matching shared secret, PEM public key, or JWK into the verification key field.

  3. 03

    Switch to sign mode when you need to build a fresh token from editable header and payload JSON.

  4. 04

    Pick an algorithm and provide the matching secret or private key. The token regenerates as you type.

  5. 05

    Copy the resulting token from the output panel and use it in your API call, test fixture, or local integration.

Details

Each task focuses on a different part of the token. Picking the right mode and the right field keeps debugging direct.

  • Use inspect mode without a key to see what claims a token carries and whether it has expired.
  • Provide the matching secret or public key in inspect mode to confirm the token actually came from the expected issuer.
  • Use sign mode to produce a token for a local API, unit test, or mock service without going through a full login flow.
  • HMAC algorithms sign and verify with the same shared secret, which is convenient while debugging.
  • RSA, PS, ECDSA, and EdDSA sign with a private key and verify with a public key, so prepare the matching role.
  • Hover over exp, iat, and nbf in the payload to see the absolute date, which usually exposes clock-skew problems quickly.

Use cases

Wherever an application uses authentication, authorization, or claim-based routing, this inspector removes the back and forth between tools.

  1. Login and auth debugging

    Check the subject, roles, scopes, expiry, and signature state on a login token while tracking down 401 or 403 responses.

  2. Backend API integration

    Generate predictable signed tokens for local APIs, mock services, and automated tests instead of completing the full login flow each time.

  3. Third-party token review

    Decode a token issued by a partner and confirm that the algorithm, issuer, audience, and expiry all match what your backend expects.

  4. SSO and OIDC troubleshooting

    Compare aud, iss, and auth_time across environments to find configuration differences without inspecting raw responses.

  5. Security review and regression

    Confirm that production tokens use the expected algorithm and that no secrets or sensitive data leaked into the payload by mistake.

  6. Webhook and callback checks

    When a webhook is delivered as a JWT, verify its signature, source, and freshness before trusting the contents.

See also

When a decoded header or payload is hard to scan, open JSON Formatter to tidy up the JSON, then copy it back into sign mode. To inspect a single Base64URL segment outside the token, Base64 Encoder and Decoder is the quickest way to experiment with encoding and decoding. For non-JWT use such as API request signing, webhook signatures, or standalone HMAC digests, open HMAC Generator . When you need a disposable secret for a local HS256 test token, generate one with Password Generator instead of reusing real credentials.To compare the decoded payloads of two issued JWTs — for example to check claim changes, tightened scopes, or audience adjustments — paste the two JSON documents into JSON Diff for a path-keyed structural diff, with word-level highlighting for long string claims. To trace which request actually carried a token in its Authorization header, hand the full message to HTTP Message Parser , which lays out the Authorization header, cookies, and body together — then come back here to verify the token. When a token is signed with RS256 or ES256, the verifying public key usually lives in an X.509 certificate; decode it with Certificate Decoder to read the subject, validity, and key details before you trust the issuer.

What sits inside a JWT

A token is three dot-separated segments. Knowing what each one carries makes it easier to spot which part you need to look at when something goes wrong.

  1. Header

    Describes the token type and signing algorithm. It usually contains typ and alg, and sometimes kid to identify which key was used.

  2. Payload

    Carries claims such as issuer, subject, audience, expiry, and your own application data. It is Base64URL encoded, not encrypted, so anyone can decode and read it.

  3. Signature

    Calculated from the header, payload, and a key. It lets you detect tampering and confirm the issuer, and cannot be reproduced without the right key.

Standard payload claims

RFC 7519 defines a set of registered claim names that almost every issuer relies on. Use the reference below to recognise the common fields and their typical values while debugging tokens.

iss
Issuer
Identifies the service or authority that produced the token. Receivers usually check it against a list of trusted issuers.
e.g. https://auth.example.com
sub
Subject
Identifies the principal the token represents, typically a user ID. It should be unique within the issuer.
e.g. user_1234567890
aud
Audience
Declares which service or client is allowed to consume the token. Receivers should confirm that their own identifier appears in aud.
e.g. https://api.example.com
exp
Expiration
Unix seconds after which the token must not be accepted. Most libraries reject expired tokens automatically.
e.g. 1710003600
nbf
Not Before
Unix seconds before which the token is not yet valid. Useful for tokens that should activate at a specific time.
e.g. 1709996400
iat
Issued At
Unix seconds that record when the token was created. Helps you reason about token age and clock drift.
e.g. 1709996400
jti
Token ID
A unique identifier for the token. Useful for replay protection and for correlating tokens with server-side audit logs.
e.g. a1b2c3d4-...-e5f6
auth_time
Auth Time
Records when the user actually authenticated. Common in OpenID Connect and SSO flows that require a recent login.
e.g. 1709992800

Best practices

Treat a JWT as signed plaintext rather than a private container, and most common mistakes disappear.

  • Do not trust claims inside a token until you have verified the signature with the correct secret or public key.
  • JWT is signed, not encrypted. Never store passwords, keys, or sensitive personal data in the payload.
  • Keep production signing keys and private keys in a key management system. Do not paste them into browser tools, chats, or screenshots.
  • Match the algorithm to the key type. A token signed with HS256 cannot be verified with HS512, and RSA public keys cannot verify HMAC tokens.
  • When debugging auth issues, check exp, iat, and nbf early and compare the issuer and receiver clocks. Clock skew is easy to overlook.
  • For long-lived tokens, pair them with refresh logic and a revocation strategy so a leaked token stays useful for as little time as possible.

Limitations

Knowing what the tool does not cover keeps expectations grounded around JWT security and compatibility.

  • Only compact JWS tokens are supported. Encrypted JWE tokens are out of scope.
  • Tokens and keys are never persisted. Everything is released when you close the tab.
  • Invalid JSON in the header or payload will prevent a token from being signed until the JSON is fixed.
  • The tool is not a key management service. Avoid pasting long-lived or master keys into any online tool, including this one.
  • Extremely large payloads can slow down the editor, though processing still happens locally rather than being truncated or uploaded.

FAQ

Common questions about signed versus encrypted tokens, verification failures, supported algorithms, and how data stays local.

Is a JWT encrypted?

Most JWTs are signed, not encrypted, which means anyone can decode the payload once they have the token. If you need encryption, the standard you are looking for is JWE rather than JWS.

Why does signature verification keep failing?

The usual causes are a mismatched key, a different algorithm than the one in the header, a payload that was modified after signing, or a token that was issued with a different key family. Compare the alg in the header against the key you provided.

Can I use this for production secrets?

Use the tool for inspection, debugging, and local test token generation. Keep production secrets and private keys inside a secure key management system, not in browser tools or shared screens.

Does the page send my token or key anywhere?

No. Parsing, verification, and signing all happen in your browser. The page does not include any network call that ships your token or key to a server.

Which algorithms are supported?

HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, and EdDSA, which covers the defaults of most modern backend frameworks.

Why do exp and iat show up as dates?

The standard stores those claims as Unix epoch seconds. The tool converts them to readable dates so you can quickly check for expiration and clock-skew problems.

Can I trust the decoded payload?

Only after a successful signature verification. Decoding alone proves the payload is valid JSON, not that it came from the expected issuer or was kept intact in transit.

Related tools

Keep working on security and identity tasks with matching tools for password generation, hashing, and signature checks.