What is a JSON Web Token (JWT)?
A JSON Web Token is a compact way to represent claims between two parties, typically a client and a server. Instead of storing session data on the server, many modern applications issue a token that encodes information such as the user ID, roles and expiry time. That token is then sent with each request, allowing the server to verify the claims without looking up session state in a database.
A JWT consists of three base64url-encoded parts separated by dots: a header, a payload and a signature. The header describes the type of token and the signing algorithm, the payload contains the claims in JSON form, and the signature allows the receiver to verify that the token has not been tampered with. The JWT Decoder on CodBolt focuses on unpacking these parts so you can inspect them during development and troubleshooting.
Understanding the header, payload and signature
The header is usually a short JSON object with fields like alg (algorithm) and typ (type). Common values include HS256 for HMAC with SHA-256 and RS256 for RSA with SHA-256. The payload holds the actual claims. Standard fields such as sub (subject), iss (issuer), aud (audience) and exp (expiry) help describe who the token belongs to and how long it should be trusted.
The signature is created by taking the header and payload, joining them with a dot, and applying a signing algorithm with a secret or private key. When you paste a token into this decoder, it splits the string into its three parts and decodes the header and payload into pretty-printed JSON. You can then copy those sections into the JSON Formatter if you want to explore or manipulate the claims further.
Inspecting claims during login and API calls
When a user signs in through your application, the authentication server often returns a JWT that your frontend stores in memory, local storage or cookies. If something behaves unexpectedly—like missing permissions, incorrect user information or a token that expires too soon—the first step is to inspect the token itself. Decoding the payload shows you exactly which claims are present and what values they hold.
During API debugging, you can copy a token from request headers in your browser developer tools or API client, paste it into this JWT Decoder and immediately see whether the right roles, scopes or custom fields are set. This is much faster than guessing what the backend generated, and it helps you confirm whether the issue lies in token creation or in how your application interprets the claims.
Security considerations: what decoding can and cannot do
Decoding a JWT does not verify its authenticity. Because the header and payload are only base64url-encoded, anyone who has the token can read its contents. The security comes from the signature, which requires a secret or private key to create correctly. This decoder intentionally does not ask for keys or attempt to validate signatures; it is designed as a safe inspection tool, not a full verification service.
If you need to verify that a token is genuine, you must do so on the server using your authentication library and the correct signing keys. However, you can still use this decoder to check meta information like algorithms and key IDs, then compare them with your server configuration. For deeper integrity checks and hash-based workflows, tools like the Hash Generator can help you understand how algorithms such as SHA-256 are used in token signatures.
Common JWT fields and how to interpret them
Many JWTs share a core set of standard claims. The iss field indicates who issued the token, such as your auth server or identity provider. The sub field usually stores a unique user identifier. The aud claim tells you which application or API the token is intended for. Time-based claims like exp (expiry), iat (issued at) and nbf (not before) define when the token should be considered valid.
Beyond standard claims, many systems include application-specific fields, such as roles, permissions arrays or feature flags. By decoding the payload and reviewing these custom claims, you can verify that your role mapping and authorisation logic match what the token actually contains. This is especially helpful when working with third-party identity providers where you configure mappings via a dashboard rather than code.
Debugging expired or invalid tokens
When a token stops working, the reason is often hidden in its timestamps or audience restrictions. By decoding the JWT, you can see the exact expiry time, the timezone-agnostic Unix timestamp and other temporal claims. Comparing these values with your system clock helps you spot issues like clock skew or misconfigured lifetimes.
If an API reports that a token is not meant for a particular audience, decoding lets you check the aud claim directly. When combined with tools such as the JSON Formatter and URL utilities on CodBolt, you can also inspect any state parameters or redirect URLs associated with the authentication flow, giving you a clearer picture of why a token might be rejected.
Best practices when working with JWTs
For production systems, treat JWTs as sensitive data. Avoid logging full tokens in plain text and never expose signing secrets in frontend code. Use HTTPS everywhere so tokens are not intercepted in transit, and prefer short-lived access tokens combined with refresh tokens where appropriate. Regularly review which claims you put into tokens and remove anything that is not strictly necessary.
As a safe companion in this process, the JWT Decoder on CodBolt gives you a quick way to see what is inside a token without running any verification logic in the browser. Use it alongside server-side libraries, the JSON Formatter and related security tools to debug authentication issues, document your token structure and educate your team on how your sign-in system works under the hood.