Dekodér JWT

Decode any JSON Web Token in your browser

This JWT decoder turns an opaque eyJ… string into readable JSON in an instant. Paste a JSON Web Token and it splits it at the dots, Base64URL-decodes the header and payload, and pretty-prints both side by side, with the raw signature shown on its own. It's the fast way to debug an auth flow, inspect a token from an API response, or confirm exactly which claims your backend is issuing.

Every part of the token is colour-coded — header, payload and signature — so the three sections of header.payload.signature are easy to tell apart at a glance. There's no account, no server upload, and no daily decode limit.

Read the claims and check expiry at a glance

The decoder highlights the standard registered claims defined in RFC 7519 — iss, sub, aud, exp, nbf, iat and jti — in a clear table with a plain-English meaning for each. The three timestamp claims are Unix epoch seconds, which are easy to misread, so the tool converts them to your local date and time and adds a relative hint like 'issued 5 minutes ago' or 'expires in 59 minutes.'

Most importantly, it answers the question you usually open a JWT debugger to ask: is this token still good? The exp claim is checked against the current time and the token is marked Valid or Expired, with nbf respected too, so you can see at once whether an expired token is the reason a request is being rejected. jwt.io shows the raw timestamp but doesn't flag expiry status automatically — you have to calculate it yourself.

Verify the signature — HS256, RS256 and ES256

Decoding shows what a token says; verifying proves you can trust it. This tool is also a JWT signature verifier: it reads the algorithm from the header and verifies the signature locally with the browser's Web Crypto API. For HS256, HS384 and HS512 you supply the shared HMAC secret; for RS256, PS256 and ES256 (and their 384/512 variants) you paste the issuer's public key in PEM format.

Because the maths runs on your device, you can confirm a token is authentic — that nobody altered the payload — without sending the token, the secret, or the key to any server. A green check means the signature matches; a red cross means the token was changed or you're using the wrong key. jwt.io requires an account upgrade to verify RS256 tokens with a custom public key; this tool does it free, always.

Build and encode a JWT too

Need to go the other way? The built-in JWT encoder lets you craft a token from scratch. Edit the header and payload as JSON, pick an HMAC algorithm, enter a secret, and it produces a correctly signed header.payload.signature token ready to copy into a request or a test. Handy shortcuts drop in fresh iat and exp claims so your test tokens have realistic timestamps.

That makes UtiloKit a combined jwt decoder and encoder — inspect tokens coming back from your API and mint new ones to send, all in the same place. This is the same workflow developers use with jwt.io, but with no server involvement and no account needed.

How this compares to jwt.io, token.dev, and jwtdecode.com

jwt.io is the most recognizable JWT tool on the web — built by Auth0, widely linked in documentation, and trusted by millions of developers. Its main limitation is privacy: jwt.io sends your token to Auth0's servers in some configurations, and it integrates with Auth0's commercial products. If you're debugging a token from a competitor's auth system or a confidential internal API, that's a problem.

token.dev and jwtdecode.com cover basic decoding but don't support RS256/ES256 signature verification with a PEM key, which is the algorithm used by Auth0, Google, Microsoft Azure AD, Okta, and most enterprise OIDC providers. You end up having to copy public keys from the provider's JWKS endpoint and verify them manually in code.

This UtiloKit decoder handles all of that in the browser: decode, expiry check, and full signature verification across HS/RS/PS/ES algorithm families — free, with no account, no daily limit, and nothing leaving your device. It's the right tool for daily auth debugging work.

JWT security: what the token can and can't protect

A JWT is signed for integrity, not encrypted for confidentiality. Anyone who holds the token can read every claim in the payload — the Base64URL encoding is trivially reversible, as this decoder demonstrates. So the payload should contain only non-sensitive identifiers: a user ID, role, or email. Never put passwords, payment details, or API keys in a JWT payload.

The signature protects against tampering: if an attacker modifies even a single character of the payload, the signature will no longer match and any server verifying with the correct key will reject the token. The classic alg: none attack bypasses this by claiming no algorithm is in use — a well-known vulnerability (CVE-2015-9235) that any production JWT library should block. This tool flags none tokens and refuses to call them valid.

Keep token lifetimes short using exp, transmit over HTTPS, store in memory or httpOnly cookies (not localStorage), and verify signatures on every request. Decode and inspect your tokens with this free tool to confirm these properties are set correctly before deploying to production.

The JWT specification: RFC 7519 and how the three parts work

RFC 7519, published in 2015 by the IETF, is the normative specification for JSON Web Tokens. It defines a token as three Base64URL-encoded segments separated by dots — header.payload.signature — where Base64URL is a URL-safe variant of Base64 that replaces + with -, / with _, and strips padding = characters so the token can be embedded in a URL query string without additional encoding. The header is a JSON object declaring the token type (typ: "JWT") and the signing algorithm (alg): symmetric algorithms like HS256 (HMAC-SHA-256) or asymmetric ones like RS256 (RSA-SHA-256) or ES256 (ECDSA-P256).

The payload carries claims — assertions about the subject. RFC 7519 distinguishes three categories. Registered claims are the seven standard fields: iss (issuer — who created the token), sub (subject — typically the user ID), aud (audience — the intended recipient service), exp (expiration — Unix timestamp after which the token must be rejected), nbf (not-before — token is invalid before this time), iat (issued-at — when it was minted), and jti (a unique token ID for replay-prevention). Public claims are names registered in the IANA JSON Web Token Claims Registry to avoid collisions. Private claims are custom application-specific fields — role, tenant ID, plan tier, or any other data your system needs — agreed upon between the issuer and consumer.

The signature is computed over the ASCII string base64url(header) + '.' + base64url(payload). For HS256, the server hashes that string with a shared secret using HMAC-SHA-256. For RS256, the server signs it with a private RSA key, and any party holding the corresponding public key can verify the signature without knowing the private key. This asymmetry is what makes RS256 suitable for federated identity: an identity provider (IdP) signs tokens with its private key, and every API in an organisation can verify them with the published public key — no secret distribution required.

The alg:none vulnerability — why you must never trust the header

In 2015 security researcher Tim McLean disclosed a critical flaw affecting multiple JWT libraries: many implementations read the alg field from the token header to decide how to verify the signature. An attacker could craft a token with "alg": "none" in the header, strip the signature entirely, modify the payload to elevate their role to admin, and re-encode the header and payload. Libraries that honoured the alg: none value would skip signature verification — completing the verification step with a success result despite no signature being present. This is catalogued as CVE-2015-9235 and affects Node.js, Python, PHP, Ruby, and Java JWT libraries from that era.

A related variant of the attack targeted algorithm confusion between RS256 and HS256. If a server expected RS256 (asymmetric, verifying with a public key) but an attacker submitted a token with alg: HS256, some libraries would switch to symmetric verification — using the public key as the HMAC secret. Since the public key is, by definition, publicly known, the attacker could sign the forged token themselves and the server would verify it as authentic. The core lesson is the same: the algorithm to use for verification must be fixed server-side, not read from the untrusted token header.

Modern, well-maintained JWT libraries (python-jose, jsonwebtoken ≥ 9, java-jwt, nimbus-jose-jwt) require callers to specify the expected algorithm explicitly and will throw an error if the token's alg differs. The alg: none option is disabled by default and must be deliberately enabled with a flag — a significant break from early library design. When reviewing JWT implementations, always confirm that the algorithms (or equivalent) parameter is hardcoded and does not derive from the incoming token header. This decoder flags alg: none tokens as unverified to make the risk visible during debugging.

JWTs vs session cookies — stateless tokens and the revocation problem

Traditional web authentication uses session cookies: the server generates a random session ID, stores the session state (user ID, role, preferences) in a database or cache like Redis, and sends only the session ID to the browser as a cookie. Every subsequent request causes the server to look up the session ID in the store to retrieve the user's state. This model is stateful: the server maintains truth. Invalidation is instant — delete the session record and the cookie becomes useless on the next request. The drawback is scalability: every request requires a database round-trip, and horizontally scaled servers need a shared session store so that any node can look up any session.

JWTs are stateless: the token IS the session. The server embeds the user's identity and permissions directly into a cryptographically signed payload and sends it to the client. On subsequent requests the client sends the token back, and any server that knows the signing key (or public key for RS256) can verify and read it without touching a database. This means a fleet of microservices can independently validate tokens without a central auth lookup — ideal for distributed architectures. Horizontal scaling is trivial because there is no shared state to synchronise.

The price of statelessness is the revocation problem. A JWT is valid until its exp timestamp regardless of what happens on the server. If a user logs out, their token remains valid. If an admin account is compromised and the user is disabled in the database, their JWT still authenticates requests until expiry. Common mitigations include keeping access token lifetimes short (15 minutes is a common default) paired with longer-lived refresh tokens that are stored server-side and can be revoked, adding a generation or tokenVersion claim to the JWT and checking it against the database on each request (which reintroduces a database call but only for that one scalar), or maintaining a token blocklist for high-security operations like password resets and privilege revocations. For most consumer applications, short-lived JWTs with refresh token rotation strike the right balance.

OAuth 2.0, OpenID Connect, and the role of JWTs in modern identity

OAuth 2.0 (RFC 6749) is an authorisation framework — it defines how a user grants a third-party application limited access to their data on another service, but it says nothing about token format. OAuth access tokens can be opaque random strings or JWTs; it's up to the authorisation server. OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0 that does mandate a JWT: the id_token. The ID token contains registered OIDC claims (sub, iss, aud, iat, exp, nonce) and is decoded by the client application to learn who authenticated — the user's identity. The access token is sent to resource APIs to authorise actions; the ID token is consumed by the relying party to establish identity. Mixing them up (sending an ID token to an API, or decoding an access token expecting user profile data) is a common source of subtle auth bugs.

All major identity providers use OIDC and issue RS256 or ES256 JWTs: Google Identity, Microsoft Azure AD, Auth0, Okta, Keycloak, AWS Cognito, Firebase Authentication, and Supabase Auth. Each publishes a JWKS (JSON Web Key Set) endpoint — a public URL that returns the current set of public keys in a standard JSON format. The JWT header carries a kid (Key ID) claim that identifies which key in the JWKS was used to sign the token. A verifying service fetches the JWKS, finds the matching key by kid, and verifies the signature. This key rotation mechanism lets providers roll their signing keys without invalidating all outstanding tokens — the old key stays in the JWKS until existing tokens expire, and new tokens are signed with the new key.

OAuth 2.0 defines several grant flows for different use cases. The Authorization Code Flow is used by server-side web applications — the server exchanges a short-lived code for tokens, keeping the access token out of the browser. Authorization Code with PKCE (Proof Key for Code Exchange, RFC 7636) extends this to single-page applications and mobile apps, adding a cryptographic challenge-response to prevent authorization code interception attacks; OAuth 2.1 makes PKCE mandatory for all public clients. The Client Credentials Flow is for machine-to-machine authentication — a service authenticates directly with a client ID and secret and receives an access token scoped to service-level permissions, with no user involved. Understanding which flow issued a token — and therefore which claims to expect — is essential context when decoding and debugging JWTs from different parts of a system.