🔑

JWT Decoder

Decode and inspect JSON Web Tokens. View header, payload claims, and check expiry - without a secret key.

Header 

              

              

                

                  Payload
                  
                

                

              

              

                

                  Signature
                

                

                  
                  
⚠ Signature is not verified - this tool only decodes. To verify the signature, use your server-side JWT library with the appropriate secret or public key.

                

              

            


            
          

        

      


      

        

          
About JWT Decoder — JWT Decoder Online

          
Paste any JSON Web Token into the JWT Decoder Online and see the decoded header, payload, and expiry instantly. Developers, security engineers, and QA testers use it to read the header algorithm, examine payload claims, and check whether a token has expired — all without writing a single line of code. Paste your full JWT string (the one starting with "eyJ…") and the decoded contents appear in under a second.

          
JWTs are the backbone of modern authentication and authorisation flows — used by OAuth 2.0, OpenID Connect, and virtually every REST API that issues bearer tokens. When a login fails, a session behaves unexpectedly, or an API returns a 401, the fastest first step is to decode the token and read the claims directly. This JWT decoder online does exactly that, presenting the header, payload, and signature in clearly labelled panels and surfacing standard claims like expiry and issuer in a human-readable table.


          
How to Use the JWT Decoder

          
    
            
  1. Copy the full JWT string from your API response, browser cookie, Authorization header, or localStorage — it looks like three Base64URL segments separated by dots.
    2. 
            
  2. Paste the token into the JSON Web Token input field. The decoder triggers automatically once three dot-separated parts are detected.
    3. 
            
  3. Review the Header panel (algorithm and token type) and the Payload panel (all claims as formatted JSON).
    4. 
            
  4. Check the status chips: they show the algorithm, whether the token has expired (exp), and if the not-before (nbf) constraint is active.
    5. 
            
  5. Use the Standard Claims table to see exp, iat, and nbf timestamps converted to human-readable UTC dates with relative time (e.g., "expired 12 min ago").
    6. 
          


          
Standard JWT Claims Explained

          
JWT payloads use short three-letter claim names defined by RFC 7519. Understanding each one helps you interpret tokens quickly.

          
    
            
  • sub (Subject): The entity the token refers to — typically a user ID or account identifier. This is the most common claim and usually the primary key for looking up user data in your system.
    • 
            
  • iss (Issuer): The server or service that created and signed the token, for example https://auth.example.com. Your API should reject tokens from unexpected issuers.
    • 
            
  • aud (Audience): The intended recipient(s) of the token. A token issued for one service should not be accepted by another — validating this claim prevents token confusion attacks.
    • 
            
  • exp (Expiration): A Unix timestamp after which the token is no longer valid. The decoder shows this as a UTC date and tells you if the token is already expired.
    • 
            
  • iat (Issued At): When the token was created, as a Unix timestamp. Useful for calculating token age and diagnosing clock-skew issues between services.
    • 
            
  • nbf (Not Before): The token must not be accepted before this timestamp. Less common but important in delayed-activation scenarios such as scheduled access grants.
    • 
            
  • jti (JWT ID): A unique identifier for this specific token instance, used to prevent replay attacks by allowing servers to maintain a denylist of used token IDs.
    • 
          


          
Tips for Getting the Best Results

          
Use these tips to decode and diagnose JWT issues more efficiently.

          
    
            
  • Copy the full token including all three parts: A JWT is always three Base64URL strings joined by dots. If you accidentally copy only the header or only the payload, the decoder will show an error. Select the entire token string from your first "eyJ" to the final character of the signature segment.
    • 
            
  • Compare exp with the current time: The status chip tells you at a glance if a token is expired, but the Standard Claims table shows the exact UTC time. If your server is rejecting a token with "token expired", compare that timestamp against your server's system clock to detect clock-skew between services.
    • 
            
  • Check the alg claim in the header: The algorithm chip (HS256, RS256, ES256, etc.) tells you what signing method was used. If you expected RS256 but see HS256, your token issuer may be misconfigured — a common security vulnerability called the "algorithm confusion" attack.
    • 
            
  • Read custom claims in the payload: Beyond standard claims, most real-world JWTs include custom claims like roles, permissions, tenantId, or email. These appear in the full payload JSON panel even if they are not listed in the Standard Claims table.
    • 
            
  • Use the Copy buttons for downstream debugging: Copy the decoded header or payload JSON and paste it into our JSON Validator or JSON Visualizer to further inspect or compare complex nested claim structures.
    • 
          


          
Why Use a JWT Decoder Online

          
Decoding a JWT requires splitting the string on dots, applying Base64URL decoding to each segment, and parsing the result as JSON — simple in code, but tedious when debugging under pressure. A JWT decoder online performs all those steps instantly with no setup. Because the decoding happens in your browser with no server involved, your authentication tokens are never exposed to a third party — an important consideration when dealing with tokens that carry sensitive claims or short expiry windows.

          
The decoder is useful for frontend engineers debugging OAuth redirects, backend engineers verifying what their auth service is issuing, security teams auditing token structure and algorithm choices, and DevOps engineers investigating authentication failures in production logs. It is the fastest way to answer "what does this token actually say?" during an incident.


          
Frequently Asked Questions about JWT Decoder

          

            

              
              
No. This tool decodes the header and payload but does not verify the cryptographic signature. Verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256). These keys exist only on your server and should never be shared. Always verify signatures server-side using a trusted JWT library — never trust the claims in a decoded token without server-side signature verification first.

            

            

              
              
The decoding runs entirely in your browser — your JWT string is never transmitted to any server or logged anywhere. That said, exercise caution with long-lived tokens that grant sensitive administrative access. If a token grants persistent access to critical systems, treat it like a password and prefer decoding it in a local environment. For short-lived access tokens (e.g., 15-minute expiry), pasting here carries negligible risk.

            

            

              
              
Base64URL is a URL-safe variant of standard Base64. It replaces + with - and / with _, so the output can appear in a URL query string or HTTP header without percent-encoding. JWT parts are Base64URL-encoded without the usual = padding characters. The decoder converts these back to readable JSON by reversing the substitutions, padding the string to a multiple of 4 bytes, and calling atob().

            

            

              
              
The expiry check compares the exp claim against your device's current system clock. If your device clock is incorrect — even by a few minutes — a token that is technically valid may appear expired here (or vice versa). Check your system time settings. Also note that server-side validation uses the server's clock, so a clock mismatch between your device and server can cause identical "expired" errors in production that are unrelated to the token itself.

            

            

              
              
HS256 (HMAC-SHA256) is a symmetric algorithm — the same secret key is used to both sign and verify the token, so it must be kept private on the issuing server. RS256 (RSA-SHA256) is an asymmetric algorithm — the issuer signs with a private key but anyone can verify with the corresponding public key. RS256 is generally preferred for public APIs because the verification key can be published at a JWKS endpoint without exposing the signing key.

            

            

              
              
Standard JWTs always have exactly three dot-separated parts: header.payload.signature. If you have a string with only two parts, it may be a JWS with a detached payload, or it could be just the Base64URL-encoded payload copied without the header and signature. The decoder requires all three parts. Unsecured JWTs (algorithm "none") still have three parts — the signature segment is simply an empty string after the final dot.

            

            

              
              
Yes, completely free with no account required, no usage limits, and no rate limiting. The JWT Decoder runs 100% in your browser. There is no premium version, no ads that require sign-in, and no watermark on copied output. Because everything is client-side, it also continues to work offline after the initial page load.

            

            

              
              
Yes. The JWT Decoder is fully responsive and works on smartphones and tablets. The layout adapts to smaller screens — the header, payload, and signature panels stack vertically on mobile. Pasting a token on mobile works the same as on desktop: long-press the input field and select Paste from the context menu. The Standard Claims table is horizontally scrollable on narrow screens to preserve readability.