Skip to main content
Prabhava Groups

JWT Decoder

Decode JSON Web Tokens (JWT) client-side. Inspect headers, payload claims, expiration timestamps, and verify HMAC signatures locally in your browser.

Tokens consist of three Base64URL segments separated by dots.

Token Status

Decoded Payload Claims

Claim Description Value

Header: Algorithm & Token Type 


        


        
        

          

            

              Payload: Data & Claims
            

            
          

          

        

      


      
      

        

          Cryptographic Signature & Local HMAC Verification
        


        

          

          

            Hex Digest:
            
          

        


        

          

            
            
          

          

            
            
          

        


        

          
          
        

      

    

  

    


    

    

      

        

          
  

  

  

  
Understanding JSON Web Tokens

  

    JSON Web Tokens (JWT), defined in RFC 7519, provide a compact, URL-safe standard for
    transmitting claims between parties in web applications and microservices. They are commonly
    used as bearer tokens in OAuth 2.0 and OpenID Connect authentication architectures.
  

  

    A standard token consists of three distinct segments separated by periods: the
    header, the payload, and the signature. Each
    segment is encoded using Base64URL, allowing safe transmission in HTTP request headers, query
    parameters, and cookies.
  


  
How JWT validation works

  
Decoding and verification are two separate security operations:

  
    
    
  • 
      Decoding: Translates Base64URL strings back into readable JSON. Anyone
      holding the token can read payload claims, which is why sensitive data like plaintext
      passwords or API keys must never be placed inside a JWT.
    
    • 
    
  • 
      Verification: Reconstructs the cryptographic hash of the combined header and
      payload using the signing secret or public key. If the computed signature matches the token's
      signature, the data has not been altered in transit.
    
    • 
  


  
Worked examples

  
    
    
  • 
      Standard API authorization: An API gateway receives a bearer token, decodes
      the sub claim to identify the calling user, and checks roles to
      enforce RBAC endpoints.
    
    • 
    
  • 
      Expiration monitoring: Checking the exp epoch timestamp against
      the current server time to prompt users for token refresh before an active session terminates.
    
    • 
    
  • 
      Local microservice trust: Internal services verify symmetric HS256 signatures
      using shared environment variables without querying central identity providers for every
      request.
    
    • 
  


  

  
Common mistakes

  
    
    
  • 
      Storing unencrypted secrets in claims: Claims are visible to anyone who
      intercepts the token; Base64URL is an encoding scheme, not encryption.
    
    • 
    
  • 
      Allowing the "alg: none" vulnerability: Older libraries accepted unsigned
      tokens if the header declared alg: none, completely bypassing validation.
    
    • 
    
  • 
      Ignoring timestamp claims: Failing to validate exp, 
      nbf (not before), and iat (issued at) allows expired or replayed
      tokens to authenticate.
    
    • 
  


  

          

  
Frequently asked questions

  
      
Is it safe to decode private JWTs in this browser tool?

      
Yes. Processing is 100% client-side JavaScript. Your tokens, claims, and HMAC secrets are parsed entirely in your browser and are never transmitted to any remote server.

    
      
What is the difference between decoding and verifying a JWT?

      
Decoding merely inspects the Base64URL-encoded JSON contents of the header and payload. Verifying recalculates cryptographic signatures to prove the token has not been tampered with and originated from the legitimate issuer.

    
      
What are standard claims like iss, sub, and exp?

      
RFC 7519 defines registered claim names: "iss" identifies the token issuer, "sub" denotes the principal subject (user ID), and "exp" records expiration as Unix epoch seconds.

    
      
Why does HMAC verification require a shared secret?

      
HS256, HS384, and HS512 use symmetric cryptography where both the token issuer and verifier share an identical secret string to generate and validate signatures.

    
      
Can this tool verify RS256 or ES256 tokens?

      
No. RS256 and ES256 rely on asymmetric public-key cryptography. This tool decodes their headers and payloads, but signature verification is supported for symmetric HMAC algorithms (HS256, HS384, HS512).

    
  


        


        

        

    

      Related tools