DevTools Logo

JWT Token Decoder

JWT Token Decoder

Decode and analyze JSON Web Tokens (JWT) safely in your browser.

Encoded Token

Client-side fetch; CORS must allow the request.

JWT Scenarios & Examples

Standard Access Token

A typical authenticating token with subject, issuer, and expiration.

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622,
  "iss": "https://auth.example.com"
}

    Examples

    Decode a standard HS256 sample JWT

    Input
    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
    Output
    Header:
    {
      "alg": "HS256",
      "typ": "JWT"
    }
    
    Payload:
    {
      "sub": "1234567890",
      "name": "John Doe",
      "iat": 1516239022
    }

    The decoder Base64URL-decodes and parses the first two segments; this readable output does not prove that the signature is valid.

    Decode payload claims containing issued-at and expiration times

    Input
    eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9
    Output
    {
      "sub": "1234567890",
      "name": "John Doe",
      "iat": 1516239022,
      "exp": 1516242622
    }

    JWT NumericDate claims such as iat and exp are seconds since the Unix epoch, not JavaScript milliseconds.

    About this tool

    A JSON Web Token (JWT) is a compact, URL-safe token made of three Base64URL-encoded parts separated by dots — a header, a payload of claims, and a signature. They are the backbone of stateless authentication and authorization: an API issues a signed token at login and the client sends it on every request, so the server can trust the claims without a database lookup. Because the header and payload are only encoded (not encrypted), anyone holding a token can read what's inside — which is exactly why inspecting them safely matters.

    This decoder splits a token into its header and payload, pretty-prints the JSON claims, and surfaces the standard registered claims (iss, sub, aud, exp, iat, nbf) in a readable form — including whether the token is expired and how long until it expires. All decoding happens locally in your browser using the Web platform's own Base64URL handling; your token is never transmitted, logged, or stored, so it's safe to paste production tokens.

    How to use

    1. Paste the token

      Paste a JWT (the long xxxxx.yyyyy.zzzzz string) into the input, or load a sample token.

    2. Read the header and payload

      The tool decodes both segments and pretty-prints the JSON so you can inspect the algorithm, token type, and every claim.

    3. Check expiration and timing

      Registered time claims (exp, iat, nbf) are converted to human-readable dates, and the tool flags whether the token is currently valid or expired.

    4. Copy what you need

      Copy the decoded header or payload JSON to reuse in tests, bug reports, or documentation.

    Use cases

    Debugging rejected API requests

    Inspect alg, kid, iss, aud, scope, and exp when a bearer token is structurally accepted by a client but rejected by an API gateway or resource server.

    Reviewing identity and authorization claims

    Read subject, tenant, role, and scope claims to confirm that an identity provider issued the shape your application expects before separately verifying the token.

    Checking token timing during development

    Inspect exp, iat, and nbf values to diagnose clock-skew, premature-use, and expiration issues while remembering that decoded values remain untrusted until verification.

    Building sanitized fixtures and bug reports

    Copy the decoded structure into a test fixture or issue after replacing user data and credentials; avoid sharing live production tokens because they are bearer credentials.

    Standard JWT claims

    ClaimMeaning
    issIssuer — who created and signed the token
    subSubject — the user or entity the token is about
    audAudience — the intended recipient(s) of the token
    expExpiration time — after this the token must be rejected
    iatIssued-at time — when the token was created
    nbfNot-before time — the token is invalid until this moment

    Decoding does not verify the signature — never trust an unverified token's claims on the server.

    Common mistakes

    Mistake:Trusting claims merely because the token decoded successfully.

    Fix:Anyone can construct a Base64URL payload. Verify the signature with an approved algorithm and trusted key, then validate issuer, audience, time claims, and application-specific requirements before using any claim.

    Mistake:Reading exp, iat, or nbf as milliseconds.

    Fix:JWT NumericDate values are seconds since 1970-01-01T00:00:00Z. Multiply by 1000 only when constructing a JavaScript Date.

    Mistake:Assuming an alg value of none is automatically rejected.

    Fix:A decoder can still parse an unsecured JWT. Configure the production verifier with an explicit algorithm allowlist and reject none unless an exceptional protocol explicitly requires unsecured tokens.

    Mistake:Confusing decoding with signature verification.

    Fix:Decoding needs no key and only reveals JSON. Verification cryptographically checks the signed input and must happen in a trusted server-side JWT library before authorization decisions.

    Frequently asked questions

    References & standards