JWT Decoder

API AUTH DEVELOPER JWT TOKEN

About this tool

Decode and inspect any JWT token instantly — header, payload, expiry and signature details, all in your browser.

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.

RT-DEV-011 · Developer Tools

Paste your JWT token

🔒 Decoded entirely in your browser. Your token is never sent to any server.

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.

Check the Payload and expiry status

The Payload panel shows all the claims: user ID (sub), issuer (iss), audience (aud), and any custom claims. The Token Details row shows human-readable issued-at and expiry timestamps in Singapore Time (SGT), with a clear valid/expired status badge.

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.

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 JWT consists of exactly three Base64URL-encoded segments separated by dots: header.payload.signature. 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 major OAuth 2.0 identity providers — Google, Microsoft, Facebook, and Singapore's SingPass — use RS256. The public keys are discoverable via a JWKS (JSON Web Key Set) endpoint at a well-known URL.

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.

"Every SingPass login generates a JWT signed with RS256 — the same standard used by Google and Microsoft for their identity platforms. Singapore was one of the first governments to standardise on JWT for national digital identity."

JWTs in Singapore: SingPass, MyInfo and Why Government APIs Use Them

Singapore's SingPass is one of the world's most advanced national digital identity systems, used by over 4.5 million residents to authenticate with more than 2,000 government and private sector digital services. SingPass implements OpenID Connect (OIDC) on top of OAuth 2.0, using RS256-signed JWTs to assert identity claims across agencies and services.

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. The JWT payload contains the user's consented data fields, signed by GovTech's private key.

GovTech's API Standards (the SGDS API guidelines) require all government-facing APIs to use Bearer JWT tokens for authentication, with RS256 as the mandated signing algorithm. This applies to APIs across CPF, IRAS, HDB, and all agencies on the Whole-of-Government Application Infrastructure (WOGAA). Developers working on CorpPass integrations — used by 550,000 registered business entities — encounter JWTs in every API call.

Across ASEAN, government digital identity programs are rapidly adopting the same JWT/OIDC stack: Thailand's ThaID, Malaysia's MyDigital ID, and Indonesia's INA PASS all implement OIDC with JWT-based assertions. As ASEAN accelerates its digital economy agenda, JWT literacy is becoming an essential skill for any developer working on regional platforms or cross-border digital services.

10 Facts About JWT Tokens

JWT was proposed by Jones et al. in 2010 and 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 RS256-signed JWTs for its national digital identity assertions used by hundreds of government and private sector apps.

The average JWT token is approximately 400–600 characters long — roughly 3× larger than a session cookie, which is why HTTP/2 header compression matters for JWT-heavy apps.

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 allows an attacker to strip the signature from a JWT and claim any identity — proper JWT libraries always reject tokens with "none" algorithm.

LinkedIn's iOS app was once found to transmit full JWT tokens in analytics pings — a security bug that exposed user tokens to LinkedIn's analytics partners.

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. jsonwebtoken in Node.js, firebase/php-jwt in PHP, or PyJWT in Python) with the correct key. For OAuth providers, fetch their public keys from the JWKS endpoint (typically /.well-known/jwks.json).
sub is 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 include iss (issuer), aud (intended audience), iat (issued at timestamp), exp (expiry timestamp), and nbf (not valid before timestamp).
When a JWT's exp timestamp 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 localStorage or sessionStorage as 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.

JWT Decoder