JWT Decoder & Debugger
Decode, inspect, and validate JSON Web Tokens entirely client-side. Zero network latency. No data ever leaves your browser.
Signature verification requires cryptographic secret keys. This free client linter checks and visualizes structures safely entirely client-side.
The Architecture of JSON Web Tokens: Securely Inspecting Header and Payload Data
A JSON Web Token is a compact, URL-safe credential format defined under RFC 7519 that enables stateless session architecture across distributed systems. Instead of storing session state in a database, a server encodes identity and permission claims directly into a signed token, which is then issued to the client and presented on every subsequent request. The server validates the token's cryptographic signature in memory, eliminating costly round-trips to a session store entirely.
The problem for any engineer reading or debugging raw tokens is immediately apparent: a JWT looks like meaningless noise at a glance. A real production token resembles something like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 — a three-segment string encoded in Base64URL. Manually reversing that encoding, stripping padding characters, then parsing the resulting JSON and converting Unix epoch timestamps is neither fast nor reliable under pressure. A purpose-built JWT decoder removes every step of that friction, surfacing structured claim data, algorithm metadata, and expiry windows in a single interface, directly in your browser, with no data ever leaving your machine.
Anatomy of a JWT: Three Distinct Components
Every token conforming to RFC 7519 is composed of exactly three Base64URL-encoded segments, separated by a literal period (.) character. Understanding each segment's responsibility is foundational to secure token handling.
1. The JOSE Header
The JSON Object Signing and Encryption (JOSE) Header is a small JSON object describing the token's cryptographic machinery. At minimum it declares alg — the signing algorithm — and typ, typically the literal string JWT. The algorithm field is the single most security-critical value in the entire token. Common values are HS256 (HMAC-SHA-256, symmetric), RS256 (RSA-SHA-256, asymmetric), and ES256 (ECDSA P-256). A well-documented and historically exploited vulnerability involves an attacker changing this field to none in a forged token: any server that blindly trusts the token's own declared algorithm rather than enforcing an allowlist will accept the unsigned payload as valid. A decoder that surfaces this field prominently gives developers the first line of defence.
2. The Payload and Registered Claims
The Payload carries the JWT's actual information — a JSON object of claims. RFC 7519 defines a set of registered claim names with specific semantic meaning:
"sub": "usr_8836", // Subject — who this token is about
"iss": "auth.affilore.com", // Issuer — which system minted it
"aud": "api.affilore.com", // Audience — intended recipient
"iat": 1716940800, // Issued At (Unix epoch)
"exp": 1716944400, // Expiry (Unix epoch)
"nbf": 1716940800, // Not Before — earliest valid time
"roles": ["editor", "billing"]
}
The exp claim is arguably the most important for security posture. An expired token must be rejected regardless of a valid signature — yet numerous real-world vulnerabilities stem from applications that check the signature but skip expiry validation. A decoder that highlights expired tokens with a visible warning, and shows the remaining validity window or time-since-expiry, catches these bugs during development before they reach production.
3. The Signature and Base64URL Padding
The Signature is computed as HMAC-SHA256(base64url(header) + "." + base64url(payload), secret) for symmetric algorithms, or via an asymmetric private key for RS256 / ES256. Its sole purpose is to prove the token was issued by a trusted party and has not been tampered with since. Critically, Base64URL differs from standard Base64 in two important ways: it replaces + with - and / with _, and it omits trailing = padding characters that would otherwise break URL query string parsing. Decoders must implement this specific variant; using a standard Base64 library without modification will silently misparse tokens and produce incorrect output.
Decoding a Token Step by Step
Follow this workflow whenever you need to inspect a JWT from an API response, browser cookie, or Authorization header during development or incident response.
Locate and Copy the Token String
Extract the raw token from your source — typically the Authorization: Bearer <token> header in network inspector, a Set-Cookie response, or a localStorage entry. Copy the full three-segment string including both period delimiters. Do not truncate; even one missing character will invalidate the Base64URL decoding.
Paste Into the Affilore Decoder Input
Paste the token string into the decoder's input field. The tool immediately segments the three parts and decodes each concurrently in the browser's JavaScript runtime. No network request is made. The decoder will visually separate the Header, Payload, and Signature into colour-coded panels, and will flag a malformed token if the segment count or Base64URL encoding is invalid.
Inspect the Registered Claim Structure
In the Payload panel, verify the critical registered claims: confirm iss matches your expected issuer domain, verify aud is scoped to the correct API endpoint, and check that sub maps to the expected user or service identity. A mismatch in any of these constitutes a validation failure that must be rejected at runtime.
Read Epoch Timestamps as Human Dates
JWT timestamps use Unix epoch seconds — the number of seconds elapsed since January 1, 1970 UTC. Affilore's decoder automatically converts exp, iat, and nbf values into locale-aware datetime strings, and calculates the remaining validity window or how long ago the token expired. This eliminates the need for external epoch-to-date converters.
Audit the Algorithm and Custom Claims
Verify the Header's alg field matches your system's expected algorithm. Flag any token declaring none as an immediate security concern. Then review any application-specific custom claims — roles, scopes, tenant IDs — to confirm they carry the expected values for your current test scenario before submitting a bug report or opening a security ticket.
Why Local Client-Side Execution Is Non-Negotiable
Many JWT debugging tools available online operate as server-side processing services: you submit your token, it travels to a remote backend, gets decoded in a server runtime, and the result is returned to your browser. This architecture has a fundamental and irreconcilable security flaw. Production JWTs frequently contain high-sensitivity data — user identifiers, role assignments, tenant information, OAuth scopes, and in some deployments, partial PII. Transmitting these over the network, even to an ostensibly trustworthy third-party tool, violates the principle of least privilege and creates an external logging footprint you cannot control.
nd server. This architecture guarantees that sensitive security tokens, authorization roles, user identifiers, and other embedded payload details never leave the safety of your local machine. You are completely protected from external server logs, network interception, and data breaches. Because we enforce zero tracking and run completely client-side, the tool remains completely free of external dependencies, offering zero-latency, high-performance execution for all of your developer debugging workflows.
Comprehensive FAQ: Mastering JWT Debugging
Does this tool send my token to a remote server?
No. All parsing, validation, and layout highlight transformations execute 100% locally within your active browser instance. Your raw JSON Web Token strings are never transmitted over the internet. This zero-network approach ensures that sensitive API keys, user databases, and authorization claims are protected from external tracking, logging, or interception.
Why do some claims display formatted dates in green?
Standard JWT claims like exp (Expiration Time), iat (Issued At), and nbf (Not Before) represent time values as raw Unix epoch seconds. This decoder parses these specific claims and converts them into localized, human-readable date-time strings, appended directly in the visual viewer. This helps developers immediately diagnose expired tokens or verify lifecycles without using manual converters.
What does the "NOT VERIFIED" status mean for the signature?
Since this is a client-side debugger running inside a secure sandbox, it does not prompt you to enter a private cryptographic secret or RSA public certificate key. Consequently, it validates the structure of the signature segment but does not cryptographically verify the signature's authenticity. This layout is designed to help you inspect and check structure safely without uploading sensitive private certificates to a web interface.