On this page
JWT Decoder
Decode JSON Web Token headers and claims, inspect timestamps, and optionally verify a JWS signature with a key you provide. Processing stays in this browser tab.
Paste a token
Instant decodePaste a compact JWT. Spaces and line breaks around the token are ignored; spaces inside a segment are rejected.
Registered claim checks
JWSAdvanced: verify signature and check expected claims
Signature verification is optional and runs with the browser Web Crypto API on HTTPS-capable browsers. Supply a trusted signing key from the issuer using the algorithm you expect; never treat a decoded token or a key copied from an untrusted header as proof of identity.
Previous expiry alerts
Saved only in this browser. Tokens and claim values are never stored in the history.
Expiry alerts detected by this page will appear here.
No expiry alerts have been recorded yet.
JSON Web Tokens are compact containers for claims used across APIs, websites, identity systems, and distributed services. Their short, URL-friendly form makes them convenient, but convenience can also encourage a dangerous assumption: a readable token is not automatically a trustworthy one. This guide explains what a JWT contains, how its encodings and signatures work, what a decoder can and cannot tell you, and how to validate tokens responsibly.
Introduction: why JWTs are so widely used
Modern applications often need to pass information between systems that do not share a server-side session. A browser may receive an access token from an identity provider, then present it to an API. A service may pass a short-lived assertion to another service. A mobile client may hold a credential while making requests to several endpoints. JSON Web Tokens provide a standardized way to represent a set of claims in a compact, portable format.
The format is popular because its payload can be represented as JSON, its compact form is suitable for HTTP headers, and a signed token can carry integrity protection without requiring the receiving service to query a central session store for every request. These advantages do not make JWT the right choice for every system. Token size, revocation, key distribution, privacy, and operational complexity all matter. A team should select an authentication architecture to fit its threat model rather than adopting JWT simply because it is familiar.
The first practical distinction is between reading a token and trusting it. A decoder converts encoded segments into readable data. A verifier checks a cryptographic signature or message authentication code using a trusted key. An application must then validate the claims and apply its own authorization rules. These are separate steps, and skipping one can turn a useful credential into a security vulnerability.
What is a JWT decoder?
A JWT decoder is a tool that parses the compact representation of a JSON Web Token and displays readable components. A typical signed JWT, called a JSON Web Signature or JWS in compact serialization, has three dot-separated segments: a protected header, a payload, and a signature. The header and payload are Base64URL-encoded byte sequences. The third segment contains a Base64URL-encoded signature or MAC. The format and claim model are defined by RFC 7519, the JSON Web Token specification, while the compact signature representation is specified by RFC 7515 for JSON Web Signature.
Decoding the first two segments does not require the signing key. They are encoded, not concealed. Anyone who obtains a typical signed token can usually inspect its header and claims. A signature protects integrity and helps establish who signed the content, but it does not hide the payload. If claims contain private information, a signed-only token may expose that information to anyone who can read the token. JSON Web Encryption (JWE) is a distinct construction intended to provide confidentiality. The JWT specification allows claims to be represented in a JWS and/or JWE structure, including nested forms.
Some tools also offer signature verification. Verification asks a much narrower question: does this signature match the exact signing input under the specified algorithm and key? A successful cryptographic check is not a complete authorization decision. The application still needs to decide whether the key belongs to a trusted issuer, whether the intended audience matches, whether the token is within its validity period, and whether the subject is allowed to perform the requested action.
How a compact JWT works
The header
The header is a JSON object that commonly includes alg, the algorithm used to create the signature, and sometimes typ, which indicates a token type. A header might be represented as {"alg":"HS256","typ":"JWT"}. After UTF-8 encoding, that JSON is converted to Base64URL text. Header values are input data, not instructions that a verifier should blindly obey. A verifier should use a configured allowlist of algorithms and keys appropriate to the application.
The payload and claims
The payload is a JSON claims set. A claim is a name/value pair describing an assertion, such as who issued the token, who it concerns, which service should accept it, or when it expires. RFC 7519 registers commonly used claim names, including iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), and iat (issued at). Registered claims are not automatically mandatory in every application; the application profile determines which ones it requires and how it interprets them.
JWT NumericDate values represent seconds relative to 1970-01-01T00:00:00Z. That means a timestamp such as exp: 1900000000 is not a JavaScript millisecond timestamp. Applications commonly convert seconds to milliseconds only when passing the value to date APIs. Clock skew and explicitly configured leeway may matter in distributed systems, but tolerance should be small and intentional.
The signature and signing input
For a compact JWS, the signed input is the ASCII text formed from the encoded header, a period, and the encoded payload: BASE64URL(header) + "." + BASE64URL(payload). The signature is computed over those exact encoded segments. It is not computed over a newly serialized version of the JSONobject. Reformatting JSON, changing whitespace, or re-encoding either segment changes the signing input and therefore invalidates the existing signature. The JWS standard describes this signing input and compact serialization in detail.
With an HMAC algorithm such as HS256, the issuer and verifier share a secret. With a digital-signature algorithm such as RS256 or ES256, an issuer signs with a private key and a verifier can check with a corresponding public key. These families have different key-management properties. A public verification key can be distributed more broadly than a symmetric secret, while HMAC verification requires every verifier to possess a secret capable of creating signatures as well as checking them.
Base64URL is encoding, not encryption
JWT segments use Base64URL, a variant of Base64 designed for URLs and filenames. It substitutes hyphen and underscore for the conventional plus and slash characters and commonly omits trailing padding in the JWT representation. The details are documented in RFC 4648, including the Base64URL alphabet. Base64URL changes how bytes are represented as text; it does not require a password, hide content, or establish authenticity.
That is why a browser-only decoder can reveal most ordinary JWS claims without a key. If a payload displays personal data, account identifiers, or internal metadata, the data was never confidential merely because it appeared as an unreadable-looking string. Developers should minimize claims and avoid putting secrets, passwords, private keys, or unnecessary personal data into tokens. If confidentiality is a requirement, use a properly designed encryption mechanism and still consider whether the chosen token architecture is appropriate.
Not every JWT has three segments. A compact JWE uses five segments: protected header, encrypted key, initialization vector, ciphertext, and authentication tag. The ciphertext is not ordinary JSON that a decoder can display. Without the correct decryption key and required cryptographic parameters, a tool can show the protected header but cannot recover the claims. A nested token may also wrap one token format inside another, so the outer structure alone may not tell the whole story.
Benefits and trade-offs
A compact, signed token can make it practical to carry a small set of claims across HTTPrequests and services. A receiver can verify integrity without trusting an unauthenticated payload. Standard claim names can improve interoperability when different systems agree on a profile. A token can also be useful for short-lived authorization decisions in architectures where the issuer and resource server are distinct.
There are real trade-offs. A bearer token can be used by whoever possesses it, so theft is consequential. Larger tokens increase request size and may be sent on every API call. Stateless validation can make immediate revocation difficult unless the system adds a revocation list, short expiration periods, key rotation strategy, or another control. Distributed services need a reliable way to obtain and rotate trusted keys. Claims can become stale before a token expires. These are design issues, not defects a decoder can fix.
JWTs are also not a general-purpose substitute for encrypted storage, browser session cookies, or access-control policy. A signed claim saying that a user is an administrator does not guarantee that the claim is current or issued by the right party. The resource server has to verify the signature against a trusted issuer, validate the intended audience and time constraints, and enforce authorization using the token's defined meaning.
Important JWT features and registered claims
The iss claim identifies the issuer. A consumer should compare it with an issuer it explicitly trusts and ensure that the verification key is associated with that issuer. The sub claim identifies the subject, often a user or service, but the application defines what that identifier means. Subject values should not be treated as globally meaningful unless the issuer and scoping rules make them so.
The aud claim identifies intended recipients. If an application is a recipient, it should verify that its identifier appears in the audience value when the claim is present or required by the token profile. Audience validation helps prevent a token meant for one service from being replayed to another. In practice, exact comparison rules and accepted audiences should be defined by the application rather than guessed from the token.
The exp claim is the time on or after which a JWT must not be accepted. The nbf claim marks a time before which it must not be accepted. The iat claim records when it was issued. These claims do not enforce themselves; a consumer must check them against a reliable clock and its policy. A token with no expiration may be unacceptable to an application even if its signature is valid.
Other claims may be application-specific. A role, scope, tenant identifier, or permission string only has meaning under the issuer's documented contract. A decoder can show a value but cannot tell whether the issuer is trusted, the role is current, or the operation is permitted. RFC 8725, JSON Web Token Best Current Practices, emphasizes algorithm verification, issuer and subject validation, audience checks, and not blindly trusting received claims.
What a decoder can and cannot establish
A decoder can help inspect a token's syntax, header, JSON claims, timing values, and segment count. It can reveal malformed Base64URL, invalid UTF-8, invalid JSON, a likely expired timestamp, or a mismatch between an expected issuer and the displayed iss value. These observations are useful for debugging and education. They are not proof of provenance.
A local signature verifier can establish whether the supplied signature matches a particular algorithm, key, and signing input. That result is meaningful only if the algorithm was expected independently and the key came from a trusted source. If an attacker supplies both a token and an arbitrary key, a matching signature merely proves the token was signed with that attacker-controlled key. Verification also does not check every application-specific rule by itself.
A decoder cannot turn encrypted JWE ciphertext into claims without the appropriate decryption operation and key. It also cannot know whether a provider has revoked a token, whether a user account remains active, or whether a request complies with an application's authorization policy unless those checks are explicitly supplied by a trusted application context. Never use a pretty-printed payload as the sole basis for granting access.
Real-world examples
Debugging an expired API access token
A developer receives a 401 response from a test API and decodes the token's payload. The exp value converts to a time in the past, while iat indicates the token was issued earlier that day. This is a useful debugging clue: the client may be reusing a stale token or the refresh flow may have failed. The decoder does not issue a replacement token and does not prove that the API's clock or validation policy is correct. The developer should compare the result with the identity provider's documentation and server-side logs, while keeping the token out of public tickets and screenshots.
Checking that an access token targets the right service
An organization operates separate billing and reporting APIs. A decoded access token shows an audience identifier for the reporting service. A request to the billing service fails, which may be the intended result. The token's audience is a diagnostic clue. The billing service must make its own signature and audience checks using a trusted key source; client-side inspection is not a replacement for enforcement.
Confirming a signing-key migration
During a planned rotation, an engineering team inspects the JWT header's kid value and checks whether the issuer publishes the expected new public key. The key identifier can help select among configured keys, but it is not itself a key and must not be treated as authorization. A safe service uses a controlled issuer-to-key mapping, handles overlap between old and new keys deliberately, and removes retired keys when policy permits.
Investigating a token that does not parse
A copied token may contain a line break, quotation marks, a prefix such as Bearer, a truncated segment, or a character that was changed by a messaging system. A strict decoder can identify whether the issue is segment count, Base64URL syntax, UTF-8 decoding, or JSON parsing. The developer can then obtain a fresh token from the authorized test flow rather than attempting to repair a production credential by hand.
Common mistakes to avoid
- Confusing decoding with verification. Readable claims have not been authenticated. Verify the signature with an expected algorithm and trusted key before relying on them.
- Assuming Base64URL hides data. It is a text encoding. Do not place confidential material in a signed-only JWT.
- Trusting the token's algorithm field alone. The verifier must enforce an explicit algorithm allowlist and bind keys to the expected algorithm. RFC 8725 calls for algorithm verification and appropriate algorithms.
- Skipping audience and issuer validation. A valid signature can belong to a token intended for a different service or issued by an untrusted party.
- Using a shared HMAC secret in too many places. Every service with the secret can create valid MACs. Limit access, rotate keys, and assess whether asymmetric signing is a better fit.
- Mixing seconds and milliseconds. JWT NumericDate values are seconds. JavaScript date constructors commonly use milliseconds, so multiply by 1,000 only when converting to a JavaScript timestamp.
- Treating
kid,jku, or other header values as trusted. Token-controlled lookup values can create injection or server-side request forgery risks if blindly followed. Use a constrained, trusted key discovery design. - Posting live tokens in bug reports. Bearer credentials may grant access to an account or API. Redact them, use short-lived test credentials, and revoke or rotate a token if it has been exposed.
- Ignoring revocation and expiration design. A long-lived stateless token can remain useful after a permission change. Choose lifetimes, revocation controls, and session behavior to match the risk.
Professional tips for safer JWT handling
Start by writing a token profile for each use. State which issuer is trusted, which audience is accepted, which algorithms are allowed, which claims are required, how expiration is evaluated, and what a consumer should do on any failure. Different token types should have mutually exclusive validation rules when confusion between them could matter. Clear profiles make code review and incident response much easier.
Obtain verification keys through a trusted configuration or issuer metadata flow that has been validated for your environment. Do not let arbitrary token headers choose a URL that the server fetches. If key identifiers select among keys, perform that lookup only inside a vetted set belonging to the expected issuer. Validate the key type and permitted algorithm as well as the signature.
Keep the claim set small and avoid relying on long-lived role or account state when that state changes frequently. Set realistic expiration times and design refresh and revocation behavior explicitly. A short lifetime reduces exposure but is not a substitute for secure storage, TLS, or server-side authorization. Protect tokens as credentials in logs, analytics, crash reports, browser storage, and support workflows.
When debugging, work with synthetic or short-lived tokens in a controlled environment. A browser-based tool reduces the risk of sending data to a third-party decoder, but the device itself can still be shared, monitored, or compromised. Use trusted browsers, avoid screenshots, and clear the page when finished. For a production decision, reproduce the validation in the service that will actually consume the token and test both valid and invalid cases.
Finally, favor established, maintained cryptographic libraries and platform APIs over custom cryptographic code in application backends. A decoder is a convenience for understanding representation. Production token validation has more responsibilities: secure key lifecycle, algorithm constraints, claim policy, error handling, observability without credential leakage, and a defense-in-depth authorization model.
Frequently asked questions
1. Is a JWT encrypted by default?
No. A common three-part signed JWT uses Base64URL encoding and a signature, not encryption. Its header and payload are readable by anyone who has the token. A JWE is a different, typically five-part compact structure intended for encryption.
2. Can someone change a JWT payload?
Someone can edit the text, but a properly verified signature or MAC will no longer match the changed signing input. A consumer that decodes without verifying may still be fooled by altered claims, which is why decoding alone must never establish trust.
3. Does a valid signature mean that a token is safe to accept?
Not by itself. The consumer must use an expected algorithm and trusted key, validate issuer, audience, time claims, token type, and any application-specific requirements, then apply authorization policy.
4. What does the exp claim mean?
exp is the expiration time in NumericDate seconds. Under RFC 7519, the current time must be before that value for the token to be accepted. The consuming application is responsible for enforcing this rule and any narrowly defined clock tolerance.
5. What is the difference between iss and aud?
iss identifies who issued the token. aud identifies its intended recipient or recipients. A consumer should check both against its trusted configuration when required by its token profile.
6. Why does a JWT have three parts?
A compact JWS has an encoded protected header, an encoded payload, and an encoded signature, separated by periods. A compact JWE has five parts because encryption also represents values such as an encrypted key, initialization vector, ciphertext, and authentication tag.
7. What does Base64URL mean?
It is a URL- and filename-friendly Base64 alphabet that uses hyphen and underscore in place of plus and slash. It is reversible encoding, not encryption or a signature.
8. Can I decode an encrypted five-part JWT?
You can inspect a decodable protected header, but the encrypted claims remain ciphertext. Recovering them requires the appropriate decryption key and the correct cryptographic procedure. A normal decoder cannot reveal encrypted content merely by changing its encoding.
9. What is the kid header?
kid is a key identifier that can help an application select a verification key from a trusted set. It is only an identifier. The consumer must constrain lookup to trusted issuer keys and must not treat the value as proof of trust.
10. Which is better: HS256 or RS256?
Neither is universally better. HS256 uses a shared secret, so each verifier that can check a token can also produce one. RS256 uses an asymmetric key pair, allowing verifiers to hold a public key while the issuer keeps the private signing key. Choose according to trust boundaries, interoperability, key operations, and your security profile.
11. Are JWT claims always required?
No. RFC 7519 defines registered claim names, but the specification does not make every registered claim mandatory in every JWT. Each application should define its own required claims and validation rules.
12. Can I use this decoder for access-control decisions?
No. A decoder helps inspect a token and may perform a local cryptographic check, but it does not know the policy or trusted identity configuration of your application. Make access decisions in the consuming service after complete validation.
13. Why is my signature verification failing?
Common causes include the wrong key, wrong algorithm, token alteration, wrong key encoding, a public key that does not correspond to the signing private key, or a mismatch between the chosen curve and algorithm. Check the issuer's trusted configuration and use an unmodified test token.
14. Is it safe to paste a production token into an online tool?
Any bearer token should be treated as a credential. This page processes input locally and makes no token network request, but browser extensions, shared-device access, screenshots, and compromised systems remain risks. Prefer synthetic or short-lived test tokens and revoke exposed credentials promptly.
15. Does a JWT decoder need the secret key?
No key is needed to decode an ordinary JWS header and payload. A trusted key is needed to verify a signature. A JWE requires appropriate decryption material to reveal its protected payload.
Conclusion
JWTs are a compact way to represent claims, but their security depends on the full validation process around them. Base64URL makes data transport-friendly; it does not make data secret. A signature can protect integrity, but only when the consumer chooses an expected algorithm, uses a trusted key, checks issuer and audience, evaluates time claims, and enforces application policy. Use a decoder to understand a token's structure and troubleshoot development issues, not as a substitute for secure authentication or authorization. Keep tokens confidential, minimize their claims, and follow the standards and best practices that match your system.
Sources and Further Reading
- RFC 7519: JSON Web Token (JWT) — the JWT structure, registered claims, and processing context.
- RFC 7515: JSON Web Signature (JWS) — compact serialization and signing input.
- RFC 8725: JSON Web Token Best Current Practices — guidance for safer validation and deployment.
- RFC 4648: Base-N Encodings — Base64 and the URL-safe Base64 alphabet.
- MDN: SubtleCrypto.verify() — browser API reference for cryptographic signature verification.
This educational material is not a security audit or a substitute for the token issuer's documentation and your application's validation policy.