JWT Decoder & Inspector
Decode and inspect JSON Web Tokens online. View JWT headers, payloads, claims, timestamps and expiration details instantly in your browser without uploading your token.
Decode & Inspect JWT
Paste a JSON Web Token below to inspect its header, payload, claims, timestamps and signature segment.
Token Overview
Basic information extracted from the JWT header and payload.
Algorithm
—
Type
—
Claims
0
Characters
0
Bytes
0
Token Timing
Not Analysed
Decode a JWT to inspect its timing information.
Header
Token metadata and declared algorithm.
Payload
Claims carried by the token.
Claims Inspector
Registered JWT claims are shown first and explained automatically. Custom claims contained in the payload are also listed below.
Signature Segment
This is the encoded signature segment exactly as it appears in the token. Displaying it does not verify the JWT signature.
Encoded JWT Segments
A signed JWT is commonly represented as three Base64URL sections separated by periods.
Header
Payload
Signature
Private Browser-Based JWT Decoding
Normal JWT decoding is performed directly inside your browser.
- No file upload is required.
- Your token does not need to be sent to SwiftVecto's server for decoding.
- Header and payload sections are decoded locally on your device.
- You can copy decoded information directly from the browser.
Even with local processing, avoid using real production access tokens unless you genuinely need to inspect them.
How a JWT Is Structured
A common signed JWT contains three sections separated by periods.
Header
Contains metadata such as the token type and declared signing algorithm.
Payload
Contains claims such as the subject, issuer, audience, permissions and expiration time.
Signature
Used by a properly configured receiving system to verify token integrity and authenticity.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlVzZXIifQ
.
signature
Common JWT Claims
These registered claim names are commonly encountered when inspecting JSON Web Tokens.
| Claim | Name | Purpose |
|---|---|---|
iss
|
Issuer | Identifies who issued the token. |
sub
|
Subject | Identifies the subject represented by the token. |
aud
|
Audience | Identifies the intended recipient of the token. |
exp
|
Expiration Time | Indicates when the token should expire. |
nbf
|
Not Before | Indicates when the token becomes usable. |
iat
|
Issued At | Records when the token was issued. |
jti
|
JWT ID | Provides an identifier for a particular token. |
Continue with These Tools
Finished using JWT Decoder & Inspector? Here are some related tools that people commonly use next to complete their workflow faster.
JSON Formatter & Validator
Format, beautify, minify and validate JSON online instantly. Detect invalid JSON, organise nested data and create clean, readable JSON directly in your browser.
Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 back to readable text instantly. Supports UTF-8 and Base64URL with private browser-based processing.
Hash Generator
Generate SHA-1, SHA-256, SHA-384 and SHA-512 hashes instantly from text. Create lowercase or uppercase hexadecimal hashes with private browser-based processing.
UUID Generator
Generate secure random UUID v4 identifiers instantly online. Create single or bulk UUIDs, choose uppercase or lowercase output, remove hyphens and copy or download results directly in your browser.
Regex Tester
Test JavaScript regular expressions online with live match highlighting, capturing groups, named groups, flags and replacement previews directly in your browser.
URL Encoder / Decoder
Encode or decode URLs and URL components instantly. Convert special characters to percent-encoded values, decode encoded text and work with URI components or form-style query data directly in your browser.
Unix Timestamp Converter
Convert Unix timestamps to readable dates or convert dates back to Unix time. Work with seconds, milliseconds, UTC, ISO 8601 and timezones directly in your browser.
How to Decode and Inspect a JWT
Use the SwiftVecto JWT Decoder & Inspector to decode JSON Web Tokens and view their header, payload, registered claims, timestamps and expiration information. Paste a JWT into the tool to inspect its contents instantly without manually decoding each Base64URL segment.
Overview
JSON Web Tokens, commonly known as JWTs, are compact tokens used by websites, APIs, mobile applications and identity platforms to exchange information between systems. A typical JWT contains three dot-separated sections: a header, a payload and a signature. The header describes information such as the signing algorithm, while the payload contains claims about the token or its subject. The signature helps a receiving application determine whether a signed token has been altered, but decoding a token is not the same as verifying that signature. This JWT Decoder & Inspector makes the readable portions of a token easier to examine during API development, authentication troubleshooting and application debugging. Common time-based claims such as exp, iat and nbf are also converted into human-readable dates.
Benefits
How It Works
Paste a JWT into the input field.
The token is split using the period characters that separate its encoded sections.
A standard signed JWT normally contains three sections: header, payload and signature.
The header and payload sections use Base64URL encoding and are decoded into their original text representations.
The decoded header and payload are parsed as JSON.
The header normally identifies information such as the token type and signing algorithm.
The payload contains claims, which are pieces of information associated with the token.
Registered timestamp claims such as exp, iat and nbf are interpreted as Unix timestamps and converted into readable dates.
If an exp claim exists, the tool can compare it with the current time and indicate whether the token appears expired.
The signature segment is displayed separately but is not treated as verified merely because the token can be decoded.
How to Use This Tool
-
1Copy the JWT you want to inspect.
-
2Paste the complete token into the JWT input field.
-
3Select Decode JWT.
-
4Review the decoded header to see information such as the declared signing algorithm.
-
5Review the decoded payload to inspect the token claims.
-
6Check the claims section for issuer, subject, audience and timestamp information where available.
-
7Review the expiration status if the token contains an exp claim.
-
8Inspect the signature segment if needed for debugging.
-
9Copy individual decoded sections when you need them elsewhere.
-
10Use Clear before inspecting another token.
Helpful Tips
- A JWT can usually be decoded without knowing its signing secret because the header and payload are encoded rather than encrypted.
- Never assume that a decoded JWT is trustworthy simply because its structure is valid.
- Signature verification is a separate security operation from token decoding.
- Check the exp claim when troubleshooting authentication failures caused by expired access tokens.
- Check the nbf claim when a token appears valid but is rejected because it is not yet active.
- Check the iss claim when debugging tokens issued by multiple identity providers.
- Check the aud claim when a token works for one API but is rejected by another.
- The iat claim shows when a token was issued and can help identify unexpectedly old credentials.
- Some identity providers add custom claims beyond the standard registered JWT claim names.
- JWT payloads may contain sensitive account or authorization information even though they can be decoded easily.
- Avoid sharing live authentication tokens in screenshots, chat messages, tickets or documentation.
- Treat bearer access tokens like credentials because anyone possessing a valid bearer token may be able to use it.
- Do not paste production secrets or private signing keys into a JWT decoder.
- A malformed token may fail decoding because one of its sections contains invalid Base64URL or invalid JSON.
- Not every token used by an authentication system is necessarily a JWT.
Common Uses
Inspect an API access token during development.
Check why an OAuth-authenticated request is being rejected.
Determine whether a JWT access token has expired.
Inspect roles or permissions included as custom claims.
View the issuer of a token returned by an identity provider.
Check the audience claim for a protected API.
Decode a token returned during an OpenID Connect login flow.
Inspect a JWT while developing a mobile application.
Review a bearer token captured from your own development environment.
Compare claims between two authentication environments.
Inspect the signing algorithm declared by a JWT header.
Convert JWT timestamps into readable dates during debugging.
Worked Examples
The following examples demonstrate how this tool can be used in realistic scenarios.
Inspecting an API Access Token
A developer receives a JWT access token after authenticating against an API. The decoder reveals the token issuer, subject, audience and expiration time, making it easier to confirm that the correct token was issued for the intended API.
Finding an Expired Token
An API begins returning an authentication error even though the same request worked earlier. Decoding the token reveals an exp timestamp that is already in the past, indicating that a fresh access token is required.
Checking the Intended Audience
A token works successfully with one service but is rejected by another. Inspecting the aud claim shows that the token was issued for a different API audience than the service currently receiving it.
Inspecting Identity Claims
An application receives an identity token containing a subject identifier, display name and additional custom claims. Decoding the payload allows the developer to inspect those values without adding temporary debugging code to the application.
Understanding Token Timing
A JWT includes iat, nbf and exp values. The inspector converts each Unix timestamp into a readable date, showing when the token was issued, when it becomes valid and when it expires.
Common Mistakes
Avoid these common mistakes to achieve the most accurate results.
- Assuming that decoding a JWT also verifies its signature.
- Treating Base64URL encoding as encryption.
- Sharing active bearer tokens because the payload appears harmless.
- Ignoring the exp claim when investigating authentication failures.
- Ignoring the aud claim when a token is rejected by an API.
- Ignoring the iss claim when working with multiple identity providers.
- Confusing an ID token with an access token.
- Assuming every OAuth access token must be a JWT.
- Removing one of the token sections before attempting to decode it.
- Adding spaces or line breaks inside the token while copying it.
- Expecting the signature segment to decode into readable JSON.
- Assuming the algorithm displayed in the header proves that the token was actually verified using that algorithm.
- Using decoded claims for authorization without performing proper server-side validation.
- Logging complete production JWTs where they may later be exposed through application logs.
Glossary
Definitions of the most important terms used by this tool.
JWT
JSON Web Token, a compact format used to represent claims that can be transferred between systems.
Header
The first encoded section of a JWT. It commonly contains metadata such as the token type and signing algorithm.
Payload
The section of a JWT containing claims associated with the token, subject, issuer or application.
Signature
Cryptographic data used by a receiving system to check the integrity and authenticity of a signed JWT when the correct verification key is available.
Claim
A named piece of information stored in the JWT payload, such as an issuer, subject, audience, expiration time or application-specific value.
Registered Claim
A standard JWT claim name defined for commonly required information, including iss, sub, aud, exp, nbf, iat and jti.
Base64URL
A URL-safe variation of Base64 encoding used to represent JWT header, payload and signature data compactly.
Issuer (iss)
A registered claim identifying the system or entity that issued the token.
Subject (sub)
A registered claim identifying the subject that the JWT refers to, often a user or account identifier.
Audience (aud)
A registered claim identifying the intended recipient or recipients of the JWT.
Expiration Time (exp)
A registered NumericDate claim indicating the time after which the token should no longer be accepted.
Not Before (nbf)
A registered NumericDate claim indicating the time before which the JWT should not yet be accepted.
Issued At (iat)
A registered NumericDate claim indicating when the JWT was issued.
JWT ID (jti)
A registered claim containing a unique identifier for a particular JWT.
NumericDate
A numeric representation of time used by JWT claims such as exp, nbf and iat, based on seconds since the Unix epoch.
Access Token
A credential presented to an API or protected resource to request authorized access. Some access tokens use the JWT format, while others do not.
ID Token
A token used by OpenID Connect to communicate information about an authenticated user to a client application. ID tokens are commonly represented as JWTs.
Bearer Token
A credential that can generally be used by whoever possesses it, making careful handling and secure transport especially important.
OAuth 2.0
An authorization framework commonly used to obtain access tokens for APIs and protected resources.
OpenID Connect
An identity layer built on OAuth 2.0 that commonly uses JWT-based ID tokens to communicate authenticated user information.
Frequently Asked Questions
What is a JWT?
JWT stands for JSON Web Token. It is a compact format used to transfer claims between systems and is commonly encountered in web applications, APIs, authentication services and OpenID Connect implementations.
What are the three parts of a JWT?
A typical signed JWT contains three dot-separated sections: a header, payload and signature. The header and payload can normally be decoded into JSON, while the signature contains cryptographic data.
Can a JWT be decoded without a secret key?
Yes. Ordinary JWT headers and payloads are encoded rather than encrypted, so they can generally be decoded without the signing secret. A key is required when cryptographically verifying a signed token.
Does decoding a JWT verify that it is genuine?
No. Decoding only reveals the token contents. Proper signature verification must be performed separately using the correct verification key and appropriate validation rules.
Is JWT data encrypted?
A normal signed JWT is not encrypted simply because it appears unreadable. Its header and payload use Base64URL encoding and can usually be decoded by anyone who obtains the token.
What does the exp claim mean?
The exp claim represents the token expiration time. After that time, a receiving application should normally reject the token when validating it.
What does the iat claim mean?
The iat claim means Issued At and records the time when the token was issued.
What does the nbf claim mean?
The nbf claim means Not Before. It represents the earliest time at which the token should normally be accepted.
What does the iss claim mean?
The iss claim identifies the issuer of the JWT, such as an identity provider or authorization server.
What does the aud claim mean?
The aud claim identifies the intended audience of the JWT. Depending on the token, it may be a string or a collection of audience values.
What does the sub claim mean?
The sub claim identifies the subject of the token. It is often a user or account identifier but its exact meaning depends on the issuer.
What does jti mean?
jti stands for JWT ID. It provides an identifier for the token and may be used by an application for token tracking or replay-prevention strategies.
Can I check whether a JWT has expired?
Yes. If the payload contains a numeric exp claim, the decoder can compare that timestamp with the current time and show whether the token appears expired. This is informational and does not replace complete token validation.
Why does my JWT have more claims than the standard ones?
JWTs may contain private or application-specific claims in addition to standard registered claims. Identity providers and applications often add roles, scopes, tenant identifiers, usernames or other information needed by their systems.
Is an access token always a JWT?
No. OAuth access tokens can use JWTs, but authorization servers may also issue opaque tokens that cannot be decoded as JWTs.
Is a JWT always an access token?
No. JWT is a data format. JWTs can be used for access tokens, OpenID Connect ID tokens and other application-specific purposes.
Can I edit the payload and reuse the token?
Changing the header or payload of a signed JWT changes the data covered by its signature. A correctly validating server should reject a modified token unless it has been legitimately re-signed using an authorized signing key.
Why can I read my JWT if it is used for security?
JWT security normally comes from signature validation, secure transport, proper authorization rules and careful token handling rather than from hiding the payload contents.
Should I put passwords inside a JWT?
Sensitive secrets such as passwords and private keys should not normally be placed in an ordinary signed JWT payload because the payload can generally be decoded by anyone who obtains the token.
Does SwiftVecto send my JWT to the server?
The interactive decoder is designed to perform normal JWT decoding directly inside your browser, so the token does not need to be uploaded as a file or sent to SwiftVecto for routine inspection.
Can this tool verify JWT signatures?
No. This tool is a JWT Decoder & Inspector. It displays the encoded token contents and useful claim information but does not claim that the token signature is valid.
Why is my token not decoding?
The token may not be a JWT, may be incomplete, may contain invalid Base64URL data, or its decoded header or payload may not contain valid JSON.
Things to Know
- A conventional signed JWT normally contains three sections separated by periods.
- JWT headers and payloads normally use Base64URL encoding.
- Base64URL encoding is not encryption.
- Decoding a token does not prove that its signature is valid.
- The exp, nbf and iat claims are interpreted as Unix-based NumericDate values when they are numeric.
- Expiration status shown by the tool is based on the current device time and the token exp claim.
- Some JWTs may omit one or more registered claims.
- Applications may include custom claims that are meaningful only to the issuing system.
- The normal interactive decoder is designed to work entirely inside the browser.
- Treat active access tokens as sensitive credentials even when the decoded payload contains no obvious secrets.
Disclaimer
This tool decodes and inspects JWT contents but does not authenticate the token or verify its cryptographic signature.
A token shown as structurally valid may still be expired, incorrectly issued, intended for another audience, revoked, malformed according to application-specific rules or cryptographically invalid.
Do not use decoded JWT claims as a substitute for proper server-side authentication, authorization and signature verification.
Token expiration information is provided for debugging and informational purposes and depends on the timestamp contained in the token and the device clock.
Users remain responsible for protecting access tokens, identity tokens and other authentication credentials.
Official References
The following official resources were used when developing this tool and are useful for further reading.
RFC 7519 - JSON Web Token (JWT)
https://www.rfc-editor.org/rfc/rfc7519
RFC 7515 - JSON Web Signature (JWS)
https://www.rfc-editor.org/rfc/rfc7515
RFC 4648 - Base64 and Base64URL Encoding
https://www.rfc-editor.org/rfc/rfc4648
OpenID Connect Core 1.0
https://openid.net/specs/openid-connect-core-1_0.html