Decode JWT Payload

It returns both sections as structured objects, making claims, identifiers, timestamps, issuers, audiences, and algorithm metadata easy to inspect or pass into another tool. The signature is deliberately not verified, so the decoded values describe what the token says rather than proving who created it. Use the result for debugging, development, documentation, and careful inspection, never as evidence that a token is authentic or authorized.

Understand what decoding does and does not prove

A JWT commonly contains a header, a payload, and a signature, joined by periods. The first two segments are base64url-encoded JSON, which means their contents are encoded for compact transport but are not encrypted or hidden. This capability splits the supplied token, decodes those two segments as UTF-8, parses their JSON, and returns the resulting header and payload objects. It does not use the third segment to authenticate anything. That distinction matters because anyone can construct a token-shaped string with arbitrary claims. Seeing a subject, role, issuer, audience, or expiration value in the decoded payload does not establish that a trusted system issued it. Use decoding when you need visibility into token structure, want to diagnose claim names or values, or need a readable representation for development. Use a proper JWT verification library with an explicitly trusted key, allowed algorithm, issuer, and audience whenever a security decision depends on the token.

Supply a compact JWT and interpret the response

Paste or send the complete compact JWT in the token field. A structurally valid token has exactly three segments separated by two periods, even though this decoder only reads the first two. The response contains a header object and a payload object. Typical header fields include typ, which often identifies the JWT media type, and alg, which names the claimed signing algorithm. Typical payload fields include sub for a subject, iss for an issuer, aud for an audience, exp for an expiration time, and application-specific claims. No claim is required by this decoder; it preserves the JSON values that are present. NumericDate claims such as exp, nbf, and iat remain numbers rather than being converted into dates, avoiding assumptions about how a caller wants to display or compare them. If the token has the wrong number of segments, malformed base64url, invalid UTF-8, invalid JSON, or a decoded section that is not an object, the request returns an invalid-input error instead of a partial result.

Use decoded claims safely in development workflows

Decoding is especially useful at the boundary between systems. An API developer can compare the claims produced by an identity provider with the names an application expects. A support engineer can inspect a redacted test token to discover whether an audience or scope is missing. A test suite can decode tokens created by a local fixture and assert that required custom claims were included before separately testing cryptographic verification. Keep the security boundary explicit in every workflow: decoded data is untrusted input. Do not grant access, select a tenant, accept an identity, or expose private data solely because a decoded claim requests it. Avoid pasting real bearer tokens into logs, tickets, chat, or shared documents, because a JWT may be a live credential even when its payload looks harmless. Prefer synthetic, expired, or locally generated examples for troubleshooting. When automation must process real tokens, send them only through an appropriately protected channel and follow decoding with verification performed against trusted configuration.