JWT Inspector — Decode Token Header and Payload

JWT Inspector At a Glance

A JWT inspector decodes the visible header and payload of a JSON Web Token and presents them as readable JSON. Many JWTs have three dot-separated parts: a header, a payload, and a signature. The first two sections commonly contain Base64URL-encoded JSON; decoding them does not require the signing key. The information you see can help explain an authentication integration, inspect token expiration claims, or identify a mismatched issuer value during controlled testing.

Decoding must never be confused with authenticating. Anybody can construct an arbitrary JWT-shaped string and include convincing-looking claims, including administrator privileges or an expiration time many years in the future. This tool does not check signatures, validate keys, consult issuers, or prove that a token was issued by the organization named in its contents. Treat every decoded claim as untrusted until it has been verified by the receiving application's security implementation.

How to Inspect a JSON Web Token

Paste a compact JWT with its three segments separated by periods. The input accepts an optional leading Bearer label copied from an authorization header. Run the inspection to see the decoded header and payload, relevant time claims, and warnings. The tool reports malformed Base64URL sections, incorrectly encoded UTF-8, and invalid JSON rather than guessing at a partial object. It does not make a request to the issuer or try to discover public signing keys.

Use representative tokens from a safe test environment wherever possible. An active access token may authorize private API operations, and sharing it with another person can be equivalent to sharing a temporary password. Avoid including live credentials in troubleshooting screenshots, support tickets, analytics events, or exported logs. If you need to demonstrate a claim structure, replace identifying values with fictional placeholders and generate a fresh nonproduction example.

What the JWT Header Contains

The header typically describes the token's type and the algorithm its issuer claims to have used. Fields such as typ and alg are part of the token's data, not independent statements made by a trusted service. A header with alg set to RS256 suggests an RSA-based signing method, but this tool does not establish that a valid RS256 signature exists. Similarly, a kid field can identify a candidate key, yet the key identifier alone does not prove which key actually signed the token.

Some applications use encrypted JSON Web Tokens or more elaborate JOSE structures that do not match the ordinary three-part signed format. This inspector focuses on compact, three-part JWTs carrying JSON objects in their first two sections. It rejects incompatible inputs instead of pretending to decode encrypted contents. Security-sensitive applications should use maintained JOSE libraries configured with accepted algorithms, trusted keys, expected issuers, and required claims rather than relying on visual inspection.

Reading Registered Claims in the Payload

The payload can contain registered claims such as iss for issuer, sub for subject, aud for intended audience, exp for expiration, nbf for not-before, and iat for issued-at. Applications often add their own fields for roles, scopes, tenant identifiers, or feature permissions. These fields are visible to anyone who possesses an unencrypted JWT. They are encoded for transport, not hidden from inspection, so passwords and other secrets should not be placed in ordinary JWT payloads.

Claim names may be short, but their meaning depends on the service's security rules. A string in sub could refer to a user ID, service account, or a different identifier depending on the issuer's convention. An audience claim can be a string or an array in JWT usage; the receiving application must decide whether it matches an accepted audience. This inspector displays the values as submitted and does not invent an identity or permission meaning for custom fields.

Understanding Expiration and Not-Before Times

The exp, nbf, and iat claims typically use NumericDate values: seconds since the Unix epoch. They are not ordinary date strings or millisecond timestamps. An exp value is the time after which an accepting service should no longer process the token. An nbf value identifies the earliest permitted time, while iat records the claimed issue time. The inspector converts valid numeric values to readable dates so you can notice if a timestamp looks unexpectedly distant.

Time-related warnings rely on the current device clock, which may be wrong or out of sync with a server. Expiration does not demonstrate that the signature is valid, and a future expiration cannot establish that the issuer intended to authorize the current request. Servers may also allow small clock-skew tolerances. Use this display for diagnosis, not as the access-control decision for an application handling protected information.

Why Signature Verification Matters

A signed JWT normally carries a cryptographic signature over its encoded header and payload. A receiving service must verify that signature against an authorized key and restrict the accepted algorithms. If the bytes change after signing, a properly configured verifier should reject the token. Merely splitting the string at periods and decoding Base64URL does nothing to confirm this integrity. It reveals what somebody wrote into a token-shaped message, whether that person is authorized or not.

An attacker can alter a role claim to admin, encode the modified JSON, and create a token that still looks readable. Without valid signature verification and issuer checks, an application could be tricked into accepting those claims. The inspector displays a prominent warning that signature verification has not happened. If a header declares alg:none, that is also a reason to exercise caution: the header's statement must not be allowed to weaken a server's expected verification method.

A Worked Example With a Test Token

Suppose a development service issues a token whose payload contains {"sub":"test-user-17","scope":"read:reports","exp":1790000000}. The inspector can decode the three properties, display the expiration as a calendar time, and indicate whether the current local clock is past that claimed time. It cannot establish that test-user-17 exists, that the permission is currently granted, or that the server that protects the report accepts this particular token.

If a report endpoint returns 401, inspect the request's token format and relevant time claims, but also check the actual server logs and configured issuer, audience, allowed algorithms, and key rotation. A token may decode perfectly and still fail for legitimate security reasons. Conversely, a decoding error can mean the supplied value was truncated, encrypted, malformed, or not a JWT at all. The inspector can narrow the diagnostic question without replacing the verifier.

Base64URL Encoding and Unicode Claims

JWT's compact representation uses Base64URL characters that are safe in HTTP headers and URLs. It replaces the plus and slash characters found in conventional Base64 and commonly omits padding. The encoded sections therefore resemble random characters even though their decoded contents may be readable JSON text. A decoder must restore the correct encoding and interpret UTF-8 carefully to avoid silently corrupting non-ASCII names or messages.

The Base64 Encoder and Decoder is useful when comparing ordinary Base64 and URL-safe Base64 representations, but it should not be used to guess the validity of token signatures. In addition, JSON Formatter and Validator can help inspect a separate JSON payload in a readable form. Formatting and decoding assist with comprehension; neither process grants security assurances.

Token Privacy and Safer Debugging Practices

Tokens commonly appear in request headers, browser storage, authentication callbacks, and debugging logs. Even when a JWT payload contains only public-looking claims, the full signed string can act as a bearer credential for as long as a service accepts it. Keep active tokens out of screenshots, issue trackers, and examples. Rotate or revoke a credential that has been disclosed where unauthorized recipients could use it. Do not put secret signing keys in a token inspector expecting only a token string.

Access-token lifetimes, refresh-token storage, and revocation mechanisms differ between systems. The inspector does not determine whether a token has been revoked, whether a session is still active, or whether the issuer has rotated its keys. It does not reveal hidden secrets from a secure signature. Where a real application needs an access decision, consult its authentication middleware or validated token library rather than relying on what the payload happens to say.

JWT Inspection Versus JWT Verification

Inspection is a reading task. Verification is a security decision based on cryptographic evidence and a trusted context. Verification often requires an expected issuer, an intended audience, supported algorithms, and a reliable current time, along with appropriate public or secret keys. A token can pass its signature test yet remain unacceptable because it was issued for a different service, has expired, or lacks an authorization scope. A visual inspector has no way to apply all of these service-specific policies.

If a configuration change seems to affect token behavior, the JSON Diff Tool can show structural differences between sanitized configuration snapshots or diagnostic payloads. Avoid comparing live tokens that contain secrets. A useful workflow is to inspect redacted development examples, review the application's verification settings, and reproduce the request in a controlled test environment with logs that do not expose credentials.

Frequently Asked Questions About JWT Inspection