security

JWT Decoder

Decode JWT header and payload locally, inspect exp/iat/nbf times, and understand signature limits without uploading tokens.

Decoded

Header, payload, and time claims update locally as you type.

AlgorithmHS256
TypeJWT
Signaturedemo-signature-not...
Decode only, not verified

This tool reads the token contents but does not validate the signature, issuer, audience, or trust chain. Treat decoded values as untrusted until your application verifies them.

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "sub": "1234567890",
  "name": "DevCove Demo",
  "admin": false,
  "iat": 1700000000,
  "nbf": 1700000000,
  "exp": 4102444800
}

Registered time claims

expExpiration time

Active

Unix seconds
4102444800
Local time
Jan 1, 2100, 12:00:00 AM
UTC
2100-01-01T00:00:00Z
Relative
in 26,883 days
iatIssued at time

Issued

Unix seconds
1700000000
Local time
Nov 14, 2023, 10:13:20 PM
UTC
2023-11-14T22:13:20Z
Relative
923 days ago
nbfNot valid before

Active

Unix seconds
1700000000
Local time
Nov 14, 2023, 10:13:20 PM
UTC
2023-11-14T22:13:20Z
Relative
923 days ago

JWT Course

Learn JSON Web Tokens from structure to claims, verification boundaries, and practical debugging.

Course home

About this tool

DevCove JWT Decoder helps developers inspect JSON Web Tokens without uploading them. Paste a token to decode the Base64URL header and payload, pretty-print the JSON, inspect algorithm and type fields, and translate exp, iat, and nbf claims into local time, UTC, and relative status. The tool intentionally decodes only; it does not claim a token is trusted unless you verify the signature in your own system.

How to use this tool

Use this JWT decoder when you need to quickly inspect token contents during API debugging:

  1. Paste a JWT from an Authorization header, cookie, log, or OAuth callback. The optional Bearer prefix is accepted.
  2. Check the decoded header for alg and typ so you know how the token says it was signed.
  3. Review the payload JSON for subject, issuer, audience, scopes, roles, and custom claims.
  4. Inspect exp, iat, and nbf cards to compare Unix seconds with local time, UTC, and relative status.
  5. Copy the header or payload JSON when you need to include a safe excerpt in a bug report.
  6. Verify the signature and trust rules in your backend or identity provider before trusting any claim.

Features

Focused on the parts developers usually need when troubleshooting auth and API requests:

  • Base64URL decoding for JWT header and payload.
  • Pretty-printed JSON output for both decoded sections.
  • Accepts tokens with or without the Bearer prefix.
  • Shows algorithm, type, and a compact signature preview.
  • Explains exp, iat, and nbf as Unix seconds, browser local time, UTC, and relative time.
  • Highlights expired tokens and tokens that are not valid yet.
  • Clear errors for wrong segment count, Base64URL failures, and invalid JSON.
  • Copy decoded payload, decoded header, or the original token.
  • 100% browser-local processing; tokens are not sent to DevCove servers.
  • Explicit decode-only warning so users do not confuse decoding with verification.
  • Linked JWT subject course with lessons about structure, claims, mistakes, and debugging.

FAQ

Does this JWT decoder verify the signature?

No. It decodes the header and payload so you can inspect them. Signature verification requires the correct secret or public key plus issuer, audience, clock, and algorithm rules from your application.

Is it safe to paste a JWT here?

The decoding runs locally in your browser and the token is not uploaded to DevCove. Still, tokens can be sensitive credentials, so avoid sharing decoded values or screenshots unless you know they are safe.

What does exp mean in a JWT?

exp is the expiration time, usually stored as Unix seconds. If exp is in the past, a correctly validating application should reject the token.

What is the difference between decode and verify?

Decode means reading Base64URL JSON. Verify means proving the token was signed by a trusted issuer and that claims such as aud, iss, exp, and nbf satisfy your rules.

Why does my JWT have three parts?

A compact JWT has header.payload.signature. The first two parts are Base64URL-encoded JSON; the third part is the signature bytes encoded for transport.

Can a decoded payload be trusted?

Not by itself. Anyone can create a token-looking string with arbitrary JSON. Trust only tokens that pass your signature and claim validation.