JWT Decoder
Decode and inspect JSON Web Tokens instantly
What is JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519 that enables two parties to exchange verifiable claims as a JSON object. JWTs are the dominant standard for stateless authentication on the modern web — when you authenticate through OAuth 2.0, OpenID Connect, or most API gateways, the credential you receive is almost always a JWT. The token is self-contained: it carries all the information a server needs to authorize a request without querying a database or maintaining server-side session state.
Every JWT consists of three Base64url-encoded segments separated by dots: a header, a payload, and a signature. The header declares metadata — most importantly the signing algorithm (HS256, RS256, ES256, etc.) and the token type. The payload holds claims — standardized key-value pairs like the issuer, subject, and expiration time, alongside any custom data your application needs. The signature binds the header and payload together cryptographically, so any modification to either part invalidates the token.
Decoding a JWT is a routine part of development and debugging. Because the header and payload are merely encoded (not encrypted), anyone with the token can read its contents — this is intentional. Inspecting a token lets you confirm the correct claims are present, verify the expiration timestamp, check which algorithm was used, and identify misconfigurations — all without needing the signing secret or private key.
How it works
When you paste a JWT into this decoder, it splits the token string on the two dot delimiters to isolate the header, payload, and signature segments. Each of the first two segments is decoded from Base64url encoding — a URL-safe variant of standard Base64 that substitutes "+" with "-", "/" with "_", and strips padding characters. The resulting byte sequences are then parsed as UTF-8 JSON to produce human-readable objects.
The tool examines the decoded header to surface the algorithm ("alg") and token type ("typ") fields. It then scans the payload for registered claims — "exp" (expiration), "iat" (issued at), "nbf" (not before), "iss" (issuer), "sub" (subject), and "aud" (audience) — automatically converting Unix timestamps to human-readable dates and calculating whether the token is currently valid, expired, or not yet active. Custom claims are displayed alongside the standard ones with their JSON types.
The signature segment is displayed as a hex or Base64 string but is not verified, because verification requires either the shared HMAC secret or the issuer's RSA/ECDSA public key, neither of which this tool asks for or needs. The focus is purely on inspection: understanding what the token contains, confirming it is structurally well-formed, and checking its temporal validity — all performed entirely in your browser with zero network traffic.
How to use this tool
- Copy the full JWT string you want to inspect. JWTs typically begin with "eyJ" because the Base64url encoding of the opening JSON brace and common header fields produces those characters.
- Paste the token into the input field. The decoder processes the token instantly as you type — there is no submit button or processing delay.
- Review the decoded header section to confirm the signing algorithm (e.g., HS256, RS256, ES256) and token type. An unexpected algorithm could indicate a misconfiguration or a potential "alg: none" attack vector.
- Examine the decoded payload to inspect every claim. Timestamp claims like "exp", "iat", and "nbf" are automatically converted from Unix epoch seconds to human-readable dates in your local timezone.
- Check the expiration status indicator, which tells you at a glance whether the token is currently valid, how long until it expires, or how long ago it expired.
- Use the copy buttons next to each decoded section to grab the header or payload JSON for pasting into documentation, bug reports, or comparison with tokens from other environments.
Examples
Debugging a 401 Unauthorized error
Your API returns a 401 and you suspect the token has expired. Extract the Bearer token from the Authorization header in your browser dev tools or HTTP client, paste it into the decoder, and check the "exp" claim. If it expired a few minutes ago, the root cause is likely a missing token refresh flow rather than a permissions issue.
Verifying OAuth scopes after integration
After wiring up a new OAuth 2.0 integration, decode the access token returned by the identity provider to confirm it includes the expected "scope" or "scp" claim with the permissions your app requested. This catches misconfigured OAuth client registrations before they surface as cryptic authorization errors in production.
Tracing claims through a microservices chain
In a microservices architecture where a gateway issues JWTs consumed by downstream services, decode the token at each hop to verify that custom claims (tenant ID, user roles, feature flags) survive the full chain. This reveals if any intermediary is stripping, rewriting, or failing to propagate claims.
Comparing staging and production tokens
Decode JWTs from both environments side by side to confirm they share the same issuer ("iss"), audience ("aud"), and signing algorithm. Mismatches in these fields between environments are a common and frustrating source of deployment-time authentication failures.
About this tool
Paste any JWT token to decode the header, payload, and signature. Inspect all claims, check token expiration, and validate structure — all client-side, your tokens never leave your browser.
Common use cases
- • Debugging authentication issues by inspecting token claims and expiration times
- • Verifying JWT payloads returned by OAuth providers during integration development
- • Checking whether a token contains the expected scopes or roles before deploying
- • Quickly inspecting tokens from API responses without writing code
Frequently asked questions
- Is it safe to paste my JWT token here?
- Yes. SnipTools runs entirely in your browser — your token is never sent to any server. All decoding happens client-side using JavaScript, so your sensitive tokens stay on your device.
- What parts of a JWT does this tool decode?
- It decodes all three parts: the header (algorithm and token type), the payload (all claims including iss, sub, exp, iat, and custom claims), and shows the signature. It also checks whether the token has expired.
- Can I verify the signature of a JWT with this tool?
- This tool decodes and inspects JWTs but does not verify signatures against a secret or public key. For signature verification during development, use the JWT Generator tool which supports HMAC signing.
- What are the most common JWT claims and what do they mean?
- Standard registered claims include: "iss" (issuer — who created the token), "sub" (subject — the user or entity the token represents), "aud" (audience — the intended recipient service), "exp" (expiration time as a Unix timestamp), "nbf" (not before — the token is invalid before this time), "iat" (issued at — when the token was created), and "jti" (JWT ID — a unique identifier used to prevent replay attacks). Beyond these, applications commonly add custom claims for roles, permissions, tenant IDs, or any JSON-serializable data the consuming service needs.
- Why does my JWT have three parts separated by dots?
- A JWT is structured as three Base64url-encoded segments joined by periods: the header (specifying the signing algorithm and token type), the payload (containing all the claims), and the signature (a cryptographic MAC or digital signature over the first two parts). This design lets any party read the header and payload without needing a key — the signature is only required to verify that the token was not tampered with and was issued by a trusted authority.
- What is the difference between a JWT access token and a refresh token?
- An access token is a short-lived JWT (typically 5-60 minutes) that authorizes API requests — the server validates it on every call. A refresh token is a longer-lived credential (hours to days) used solely to obtain new access tokens when the current one expires. Refresh tokens are usually opaque strings stored server-side rather than JWTs, though some implementations use JWTs for both. This decoder can inspect either type if they are in JWT format.