JWT Decoder
Decode and inspect any JWT token instantly — header, payload, expiry and signature details, all in your browser. Never sent to any server. Free developer tool.
JWT Decoder Tool
🔒 Decoded entirely in your browser. Your token is never sent to any server.
alg: none — it is unsigned. Nothing binds the header or payload to an issuer, so anyone can rewrite any claim in it. RFC 7518 §3.6 defines none as the "Unsecured JWS"; RFC 8725 §3.2 says libraries should not accept such tokens unless the application explicitly requires them.
Token Details
This status reflects the exp and nbf time claims only.
No signature was checked. A token can be unexpired and still be
forged, unsigned, or issued by someone you do not trust.
Signature not verified — verification requires the secret or public key, which is not transmitted here.
How to Use the JWT Decoder
Paste your JWT token
Paste your JWT token into the text area — decoding happens automatically as you type or paste. Never paste a production token containing real user credentials; use a test token for inspection instead.
Review the Header
The Header panel shows the algorithm (RS256, HS256, ES256, etc.) and the token type. This tells you how the token was signed and what key type is needed to verify it. If the algorithm is none, the token is unsigned and the panel says so.
Check the Payload and expiry status
The Payload panel shows all the claims: user ID (sub), issuer (iss), audience (aud), and any custom claims. Token Details shows the issued-at, not-before and expiry timestamps in Singapore Time (SGT). The status badge reports those time claims only — expired, not yet usable, or not expired. It is not a verdict on whether the token is genuine.
Note: this tool only decodes, it does not validate
The signature section shows the raw signature string but does not verify it against a key. Verification requires the signing secret (HS256) or public key (RS256/ES256). This tool is for inspection only — use your JWT library to verify in production code. As RFC 7519 §11.1 puts it: "The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision."
JWT Tokens — The Authentication Standard Behind Modern APIs
What Is a JWT and How Does the Three-Part Structure Actually Work?
A JSON Web Token (JWT), defined by RFC 7519 in May 2015, is a compact, URL-safe means of representing claims to be transferred between two parties. The specification is now the most widely implemented token format for web API authentication, used by hundreds of millions of applications worldwide.
A signed JWT — the JWS Compact Serialization form that almost everyone means by "JWT" —
consists of three Base64URL-encoded segments separated by dots:
header.payload.signature. (An encrypted JWT, JWE Compact Serialization,
has five segments instead.) The header is a JSON object
declaring the signing algorithm (alg) and token type (typ). The payload
is a JSON object containing the claims — statements about the entity (typically the user)
and additional data. Standard registered claims include: sub (subject/user
ID), iat (issued at), exp (expiration time), aud
(audience), and iss (issuer). The signature is computed
by signing the encoded header and payload with a secret or private key.
A crucial point: Base64URL encoding is not encryption. Anyone who holds a JWT can decode the header and payload — they are publicly readable. Only the signature is secret, and only the key-holder can create or verify it. This means you should never put sensitive information (passwords, PINs, credit card numbers) inside a JWT payload.
The key advantage of JWTs is their statelessness: the server does not need to look up a session in a database to verify a JWT — it simply checks the signature. This makes JWTs highly scalable and well-suited to distributed, microservices architectures where multiple servers need to authenticate requests without sharing session state.
RS256 vs HS256: Signing Algorithms Explained for ASEAN API Developers
The two most common JWT signing algorithms are HS256 and RS256, and choosing between them has significant security implications.
HS256 (HMAC-SHA256) uses a single shared secret for both signing and verification. It is simpler to implement and faster to compute, making it appropriate for internal services where both the issuer and consumer are controlled by the same organisation. The weakness: any system that can verify a HS256 JWT can also forge one, because they share the same secret key.
RS256 (RSA-SHA256) uses asymmetric keys: a private key for signing and a corresponding public key for verification. Only the issuer holds the private key; any consumer can download the public key and verify tokens without being able to forge them. This is why asymmetric algorithms are the norm for public-facing OAuth 2.0 and OpenID Connect providers: the public keys are discoverable via a JWKS (JSON Web Key Set) endpoint at a well-known URL, so any relying party can verify without ever holding a signing key. Check the provider's own developer documentation for the algorithm it actually issues — do not assume.
ES256 (ECDSA with P-256 and SHA-256) is an asymmetric algorithm like RS256 but produces much shorter signatures — a 64-byte ES256 signature compared to a 256-byte RSA signature. ES256 is increasingly preferred in mobile and IoT contexts where bandwidth and token size matter.
JWTs in Singapore: SingPass, MyInfo and Government APIs
Singapore's SingPass is the national digital identity system used to authenticate with government and private sector digital services. SingPass implements OpenID Connect (OIDC) on top of OAuth 2.0, using signed JWTs to assert identity claims across agencies and services, with the issuer's public keys published at a JWKS endpoint.
The MyInfo API, operated by GovTech Singapore, returns personal data (name, NRIC, residential address, employment details) as verified claims inside JWT payloads. Developers building fintech, insurtech, and e-commerce applications in Singapore use the MyInfo API to retrieve KYC-verified user data, eliminating the need to re-verify documents manually.
If you are integrating with any of these, take the signing algorithm, key rotation policy and claim set from the provider's current developer documentation rather than from a decoded sample token — the header of a token you were handed tells you what that token claims, not what the issuer actually signs with.
10 Facts About JWT Tokens
JWT was formalised as RFC 7519 in May 2015 — it is now the most widely used format for web API authentication tokens.
Base64URL encoding (used in JWT) differs from standard Base64 — it replaces + with - and / with _ to make tokens safe for use in URLs and HTTP headers.
The payload of a JWT is only encoded, not encrypted — anyone who intercepts a JWT can read its claims without knowing the secret key.
Singapore's SingPass uses OpenID Connect (OIDC) with JWT-based assertions for its national digital identity.
A JWT without an "exp" (expiration) claim never expires — a common security oversight that has led to long-term token leakage in several reported API vulnerabilities.
JWTs are stateless — once issued, the server has no way to invalidate a token before its expiry without implementing a token revocation list (blocklist).
Firebase, Amazon Cognito, and Auth0 all use JWTs as their primary token format — making JWT familiarity essential for ASEAN developers building on cloud platforms.
The "alg: none" attack strips the signature from a JWT so an attacker can claim any identity. RFC 8725 §3.2 says libraries should not accept these unsecured tokens unless the application explicitly requires them.
Expiry is not the only time claim. RFC 7519 §4.1.5 defines nbf ("not before") — a token must not be accepted for processing before that time, even though it has not expired.
Not every JWT has three parts. A signed token (JWS Compact) has three; an encrypted token (JWE Compact) has five, per RFC 7516 §3.1.
Frequently Asked Questions
-
A JWT (JSON Web Token) is a compact, URL-safe string used to securely transmit information between two parties as a JSON object. It consists of three Base64URL-encoded parts — header, payload, and signature — separated by dots. JWTs are most commonly used for API authentication and authorisation.
-
The decoding happens entirely in your browser — your token is never sent to any server. However, we strongly advise against pasting production tokens containing real user credentials (even into this tool). Use a non-sensitive test token instead. If you accidentally paste a live token, revoke it in your authentication provider immediately.
-
Standard JWTs (JWS — JSON Web Signature) are encoded, not encrypted. The header and payload are Base64URL-encoded, which any party can reverse without a key. Only the signature requires the secret or key to create or verify. Encrypted JWTs (JWE — JSON Web Encryption) do encrypt the payload, but are much less common. Never put sensitive data in a standard JWT payload.
-
RECATOOLS is based in Singapore and our primary user base is in the ASEAN region. We display timestamps in SGT (Singapore Time, UTC+8) for clarity. JWT timestamps are always stored as Unix epoch seconds (UTC) regardless of timezone — the SGT display is purely a formatting choice for readability.
-
RS256 means the token was signed using RSA with SHA-256 hashing — an asymmetric algorithm. The issuer signs with a private key; consumers verify with the corresponding public key (usually found at a JWKS endpoint). Common alternatives are HS256 (symmetric HMAC) and ES256 (ECDSA). Always prefer RS256 or ES256 for public-facing APIs as they allow verification without exposing the signing key.
-
This tool decodes but does not verify JWT signatures — verification requires the signing secret (for HS256) or the public key (for RS256/ES256). Use your JWT library (e.g.
jsonwebtokenin Node.js,firebase/php-jwtin PHP, orPyJWTin Python) with the correct key. For OAuth providers, fetch their public keys from the JWKS endpoint (typically/.well-known/jwks.json). -
subis the "subject" — typically the unique identifier for the user or entity the token was issued for (e.g. a user ID or UUID). Other standard registered claims includeiss(issuer),aud(intended audience),iat(issued at timestamp),exp(expiry timestamp), andnbf(not valid before timestamp). -
When a JWT's
exptimestamp is in the past, any properly implemented API server will reject it with a 401 Unauthorised response. The client must obtain a new access token — typically using a refresh token if the authentication system supports them. Short-lived access tokens (15–60 minutes) are best practice; long-lived tokens increase the blast radius of a leak. -
For browser-based apps: HttpOnly, SameSite=Strict cookies are the recommended storage — JavaScript cannot read them, so XSS attacks cannot steal the token. Avoid
localStorageorsessionStorageas they are accessible to any JavaScript running on the page. For mobile apps, use the platform secure storage (iOS Keychain, Android Keystore). -
A traditional session token is an opaque random string — the server looks up the corresponding session data in a database on every request. A JWT is self-contained: all the claims are encoded in the token itself, so the server verifies the signature without a database lookup. JWTs are stateless and scale better across multiple servers; session tokens are easier to revoke (just delete from the database). Modern systems often use both: JWTs for short-lived API access tokens, and session tokens for web authentication.
Related News
You may be interested in these recent stories from our newsroom.
-
One Generated Prompt Beat Up to 63 Per Cent of a Top Conference's LLM Techniques
A University of Virginia team reproduced 35 ICSE 2026 techniques and outperformed 37 to 63 per cent of them with a single prompt to a newer...
-
The Sixth Exploited Langflow Flaw This Year Is Not a Vulnerability Story
VulnCheck has recorded 360 attacks on a Langflow flaw fixed in January. It is the sixth separately identified Langflow vulnerability exploit...
-
Broadcom Already Maintains Spring and RabbitMQ. Now It Will Sell You Clean Builds.
A reproducible build proves the binary matches the source. It says nothing about whether the source is safe, which is where the damaging inc...
Pick up where you left off
Stored only in this browser — never sent to our servers.