RFC 7515 JWS & RFC 7519 JWT • 100% Client-Side In-Memory

JWT & JWS Decoder Online – Decode Access Tokens Without Secret Key

Inspect, decode, and debug JSON Web Signatures (JWS) and JSON Web Tokens (JWT) locally. Understand why decoding is not verifying, inspect standard claims, and check real-time expiration countdowns.

Can You Decode and Read a JWS / JWT Without the Secret Key?

Yes. Standard RFC 7515 JWS and RFC 7519 JWT tokens are signed, not encrypted. The Header (JOSE) and Payload are Base64URL-encoded JSON objects that can be decoded and inspected by anyone without a secret key. The cryptographic secret or public key is only required to verify the signature, never to read the payload claims.

CRITICAL SECURITY DISTINCTION: DECODE ≠ VERIFY

Successfully Decoding a JWT Does NOT Prove Its Signature Is Valid

A common security misconception is that if a token decodes into valid JSON, it is authentic. Standard JWS/JWT tokens are simply Base64URL-encoded strings—anyone can forge header and payload claims without a secret key. Never grant authorization based solely on decoded claims. Cryptographic verification requires validating the signature with the HMAC secret or RSA/ECDSA public certificate.

Verify Cryptographic Signature With Secret / Key →
100% Client-Side Privacy: Your JWTs, JWS signatures, and credentials are processed solely in your browser memory and are NEVER uploaded to any server.
WhatsApp
Encoded Token (Paste JWT / JWS) 0 chars
Supports RFC 7515 JWS Compact Serialization & Bearer Tokens 100% Offline
Header Payload Signature
Token Expiration & Status Awaiting Input

Paste a token or click a sample button to inspect its claims.

Header: Algorithm & Token Type (JOSE)
{"alg": "none"}
Payload: Data & Claims
{}

Standard Claims Breakdown

0 claims
No standard claims parsed yet.
Core tools process input locally. Optional AI sends the selected snippet through Cloudflare to Cloudflare AI or the optional Google Gemini fallback after consent; provider retention policies apply. Contact submissions send your details to our email provider. Offline use requires the page and its assets to finish caching; external AI and contact delivery require internet. Core operation in browser memory
Local browser processing

Decode a JWT or JWS without a secret key

  1. Paste a three-part signed token or load a sample. The header and payload use Base64URL encoding; a secret is not needed to read them.
  2. Review the algorithm and claims such as exp, iss and aud. Treat these values as untrusted until you verify the signature and application requirements.
  3. For an authenticity check, open the signature verifier and use the expected algorithm and trusted key. Decoding alone is not authentication.

What the result means

This decoder does not decrypt five-part JWE tokens. An expired or forged token may still decode successfully; readable claims do not grant access.

JWT Diagnostics

JWT Error Debugger — Fix Common Token Errors & Failures

Top 5 most-searched JSON Web Token errors. Click "Try in Decoder" to load the sample token into the live inspector above and inspect the decoded claims.

TokenExpiredError: jwt expired

TokenExpiredError: jwt expired / "exp" timestamp is in the past
Root Cause

The exp (expiration time) claim in the token payload represents a Unix epoch timestamp that has already elapsed compared to current server time.

❌ Problematic Token / Error
Payload: { "sub": "12345", "name": "Alex", "exp": 1516239022 }
Status: EXPIRED (2018-01-18T01:30:22Z)
✅ Resolved Token / Fix
Payload: { "sub": "12345", "name": "Alex", "exp": 1893456000 }
Status: ACTIVE (Valid through 2030-01-01)

Fix Resolution: Request a fresh token using your refresh token endpoint, or check clock synchronization (NTP) between identity provider and API server.

JsonWebTokenError: invalid signature

JsonWebTokenError: invalid signature / cryptographic verification failed
Root Cause

The signature segment was computed with a different secret or private key, or the payload/header was modified in transit after signing, altering the HMAC/RSA digest.

❌ Problematic Token / Error
Header.Payload.TAMPERED_OR_WRONG_SECRET_SIGNATURE
Digest mismatch: Computed HMAC !== Received HMAC
✅ Resolved Token / Fix
Header.Payload.VALID_VERIFIED_SIGNATURE
Digest matches: HMAC-SHA256(header.payload, SECRET)

Fix Resolution: Ensure the API server uses the exact same secret key or public key (RS256) as the authentication server, and never alter payload bytes after signing.

JsonWebTokenError: jwt malformed (Segment Count)

JsonWebTokenError: jwt malformed / Expected 3 dot-separated segments
Root Cause

RFC 7519 compact JWTs must consist of exactly 3 parts separated by periods: Header.Payload.Signature. Pasting the "Bearer " prefix or omitting a section breaks the parser.

❌ Problematic Token / Error
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0
(Has "Bearer " prefix and missing 3rd signature segment)
✅ Resolved Token / Fix
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.Xp8sK2_9aB07R_8X9vU3L0x_6YpM5NqD9kM0wP8a1b2
(Clean 3-segment compact serialization)

Fix Resolution: Strip the "Bearer " header prefix using token.replace(/^Bearer\s+/, "") before decoding, and confirm all 3 segments exist.

Base64Url Illegal Character / Whitespace

TypeError: Failed to execute "atob" / The string contains invalid base64 characters
Root Cause

JWT uses RFC 4648 URL-safe base64 (- instead of +, _ instead of /, no = padding). Extra whitespace, newlines, or standard base64 characters cause decoding exceptions.

❌ Problematic Token / Error
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 .eyJzdWIi... (Embedded whitespace before period)
✅ Resolved Token / Fix
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIi... (Sanitized URL-safe base64 string)

Fix Resolution: Trim trailing spaces and newlines using token.trim(). Replace + with - and / with _ before base64 decoding.

Algorithm None Vulnerability (alg: "none")

SecurityException: Algorithm "none" is rejected in production mode
Root Cause

Attackers forge tokens by specifying "alg": "none" in the header and omitting the signature. Insecure parsers that do not enforce algorithms accept unsigned forged payloads.

❌ Problematic Token / Error
Header: { "alg": "none", "typ": "JWT" }
Signature: (empty / unsigned bypass attempt)
✅ Resolved Token / Fix
Header: { "alg": "HS256", "typ": "JWT" } or { "alg": "RS256", "typ": "JWT" }
Enforced cryptographic signature verification

Fix Resolution: Always enforce strict algorithm whitelisting in your JWT verification middleware: algorithms: ["HS256", "RS256"]. Never permit alg: "none".

In-Depth Developer Guide

Need code examples? Learn how to decode JWT tokens without a secret key in Node.js, Python, and Go

Read Complete Tutorial
Frequently Asked Questions (FAQ) · JWT & JWS Decoder (RFC 7515 Compact Token Parser)

JWT Decoder & Inspector — RFC 7519 JSON Web Token Technical Guide

Decode, inspect, and validate JSON Web Tokens (JWT) in your browser. Parse header algorithms, payload claims, expiry, and signature structure per RFC 7519.

MU
IBM Maximo & Developer Tools Architect
Technical Reference

01. JSON Web Tokens: RFC 7519 Structure & Claims

A JSON Web Token (JWT) defined in RFC 7519 is a compact URL-safe representation of claims between two parties. A JWT consists of three Base64URL-encoded parts separated by dots: the Header, Payload, and Signature. The header specifies the token type ("JWT") and the signing algorithm (alg), such as HS256 (HMAC-SHA256) or RS256 (RSA-SHA256).

The payload contains registered claims defined in RFC 7519 Section 4: iss (issuer), sub (subject), aud (audience), exp (expiration time as Unix timestamp), nbf (not before), iat (issued at), and jti (JWT ID). Private claims for application-specific data may also be included.

The signature is computed over the Base64URL(header).Base64URL(payload) string using the algorithm declared in the header. For HS256, this uses HMAC with a shared secret. For RS256, an RSA private key signs and the corresponding public key verifies.

  • RFC 7519 Registered Claims: iss, sub, aud, exp, nbf, iat, jti — standard interoperability fields.
  • Algorithm Support: HS256/384/512 (HMAC), RS256/384/512 (RSA), ES256/384/512 (ECDSA).
  • Expiry Detection: exp claim compared to current UTC time — instantly flags expired tokens.
Security Note: Never Paste Production Tokens

This tool decodes and inspects JWT structure without transmitting tokens to any server. Never paste production JWT tokens into untrusted third-party web services. All decoding runs client-side in your browser memory.

02. JWT Algorithm Security & Common Vulnerabilities

The "alg: none" attack (CVE-2015-9235) occurs when a JWT library accepts tokens with the algorithm set to "none", bypassing signature verification entirely. Always validate that the algorithm header matches your expected algorithm and reject "none" unconditionally.

The RS256-to-HS256 algorithm confusion attack tricks servers that accept both RSA and HMAC algorithms: an attacker changes alg from RS256 to HS256 and signs the token using the server's public key as the HMAC secret. Mitigation requires pinning accepted algorithms per endpoint.

  • Algorithm "none" attack: RFC 7519 §8 requires unconditional rejection in validators.
  • RS256 to HS256 confusion: Pin expected algorithm per endpoint — never accept from token header alone.
  • Weak HMAC secrets: Minimum 256-bit random entropy per NIST SP 800-107 recommendations.

03. JWT Expiry, Audience Validation & Best Practices

Every JWT consumer must validate: the exp claim has not passed, the nbf claim has been reached, the iss matches the expected token issuer, and the aud matches the intended recipient. Skipping any of these validations creates security vulnerabilities independent of the signature algorithm strength.

Use short-lived access tokens (15 minutes to 1 hour) paired with longer-lived refresh tokens stored in HttpOnly cookies. This minimizes the impact window if an access token is leaked, while maintaining session continuity through secure refresh flows.

  • Validate exp: Reject tokens where exp is before current UTC time.
  • Validate aud: Ensure the token was issued for your specific service — prevents token reuse across services.
  • Short-lived tokens: 15 min to 1 hour access token lifetime reduces breach impact window.
  • HttpOnly cookie for refresh: Protects long-lived refresh tokens from JavaScript XSS access.

Frequently Asked Questions (FAQ)

Can I verify JWT signatures in this tool?

Yes. For HS256 tokens, paste your HMAC secret. For RS256/ES256, paste the RSA or EC public key in PEM format. All verification runs client-side via Web Crypto API.

Are my JWT tokens sent to your servers?

Never. Decoding, parsing, and signature verification execute entirely in your browser memory using the Web Crypto API. Your tokens remain private.

What does the exp claim represent?

The exp (expiration time) claim is a NumericDate value representing seconds since Unix epoch after which the token MUST be rejected per RFC 7519 §4.1.4.

Is my confidential data uploaded to external servers when using JWT & JWS Decoder (RFC 7515 Compact Token Parser)?

No. Core processing in JWT & JWS Decoder (RFC 7515 Compact Token Parser) executes in volatile browser memory without server uploads. Inputs to local tools are not logged on remote servers; optional cloud-assisted features require user consent.

Can I use JWT & JWS Decoder (RFC 7515 Compact Token Parser) offline without an active internet connection?

Offline use requires the page and its tool assets to finish caching first. Core transformations can then run locally; optional AI and contact delivery require internet.

Is JWT & JWS Decoder (RFC 7515 Compact Token Parser) free to use with any rate limits or paywalls?

Core tools are free to use without an account. Device memory and tool-specific safety limits apply. Optional AI and online contact services have usage limits.

More free tools that run safely in your web browser.

Explore the tool directory