JWT Decoder Developer Tool

Decode a JWT's header and payload, and optionally verify an HMAC signature.

Debugging an auth issue often starts with just looking at what's actually inside a JWT — which claims it carries, when it expires, which algorithm signed it. This free JWT decoder is a developer tool that decodes a token's header and payload entirely in your browser, and can optionally verify an HMAC (HS256/384/512) signature locally if you provide the secret.

Token

Header


                        

                    

                

                

                    

                        

                            
 Payload

                            

                        

                    

                

            


            

                

                    

                        

                            


                            
 Signature verification

                            
Only supported here for HMAC algorithms (HS256, HS384, HS512), since those are the only kind that can be checked with a single shared secret rather than a public/private keypair.

                            

                                Secret
                                
                                
                            

                            

                        

                    

                

            

        


        

            Runs entirely in your browser — no data is sent anywhere.
        


        

            

                
What's actually inside a JWT

                
A JSON Web Token is three Base64URL-encoded segments joined by dots: a header describing the signing algorithm and token type, a payload of claims (arbitrary JSON data about the subject), and a signature that lets a party holding the right key verify the first two segments haven't been tampered with. Critically, the header and payload are only encoded, not encrypted — anyone who intercepts a JWT can decode and read its full contents without any key at all, which is exactly what this tool does. Never put a password, credit card number, or anything genuinely secret directly into a JWT's payload; it should only ever carry information that's fine to be readable by whoever holds the token.


                
Why decoding isn't verifying

                
Decoding a JWT tells you what it claims to say — it tells you nothing about whether those claims are genuine. A signature check is what actually confirms the token was issued by whoever holds the signing key and hasn't been altered since; skip that check and an attacker could hand-craft a token with role: admin and have it decode "successfully" with no error. Server-side code should always verify the signature (and typically the expiry, issuer, and audience claims) before trusting anything in the payload — this tool decodes for inspection and debugging, and only verifies the signature if you explicitly provide the secret, which is a deliberate, opt-in step rather than something implied by a token merely being well-formed.


                
Common claims

                
A handful of claim names are standardized (registered in RFC 7519) though none are strictly required: iss (issuer), sub (subject — typically the user ID), aud (audience — who the token is intended for), exp (expiry, as a Unix timestamp), iat (issued-at), and nbf (not valid before). Everything else in the payload is application-specific — roles, permissions, session metadata — and exists purely by convention between whoever issues the token and whoever consumes it.


                
JWTs vs Laravel Sanctum tokens

                
It's worth being clear that Laravel's own Sanctum API tokens are not JWTs. A Sanctum token is an opaque, random string with no embedded data at all — the server looks it up in the personal_access_tokens database table on every request to find out who it belongs to, rather than decoding anything from the token itself. That trade-off gives Sanctum instant, server-side revocation (delete the database row and the token stops working immediately) at the cost of a database lookup per request, whereas a JWT can be verified without hitting a database at all but can't be revoked before it naturally expires without extra infrastructure like a blocklist. If you're integrating with a third-party service or building your own token-based auth from scratch using JWTs, this decoder is for inspecting those tokens specifically — not what Sanctum issues.