JWT Encoder/Decoder

    Decode, verify, and generate JSON Web Tokens (JWT) in your browser. Safely inspect JWT headers, payloads, and signatures with our secure developer tool.

    Header will appear here...
    Payload will appear here...

    How to Use

    Follow these simple steps to get the best results.

    1Decode a token. Paste your JWT and we'll instantly split it up and show you the Header and Payload in readable JSON.
    2Inspect the claims. Check the 'exp' to see when the token dies or 'sub' to see the user ID. It's the easiest way to debug your auth flow.
    3Verify the signature. Drop in your secret key to see if the token is legit. We re-run the math locally to prove nothing was tampered with.
    4Generate a new token. Use the Encoder tab to build a signed JWT for testing. Just edit the JSON and set your secret key.
    5Copy everything. Grab the header, payload or the full token with one click and drop it into Postman or your terminal.

    Frequently Asked Questions

    Think of a JWT as a digital ID card. It's a compact, secure way to send information between a server and an app. Every token has three parts: a Header (the type), a Payload (your data, like a user ID) and a Signature (the 'lock' that proves it hasn't been tampered with).

    Decoding is just reading the card. Since it's Base64 encoded, anyone can peek at the data without a key. Verifying, is checking the lock. You need a secret key to re-run the math and prove that the token actually came from a trusted source and wasn't modified in transit.

    100% safe. All the decoding and verification happens right in your browser. We never see your tokens, your payloads or your secret keys. It's much safer than using a site that sends your data to its own server just to show you the result.

    Right now, we support HS256 (the most common one). It uses a single secret key to both sign and verify. If you're using more complex asymmetric signatures like RS256 or ES256, keep an eye out, we're working on adding those soon.

    Yep. The data inside a JWT header and payload is public by design, it's just encoded, not encrypted. You only need the secret key to verify that the signature is legit. This is why you should never put sensitive stuff like passwords inside a JWT payload.

    Those are 'claims', short codes for specific pieces of info. 'sub' is the user ID, 'iat' is when the token was born and 'exp' is when it dies. They're standardized so every app knows exactly how to handle them.

    Usually, it's a tiny mistake. Check if your secret key has an extra space or if you've picked the wrong algorithm. If even one character in the token was changed, the signature will break immediately. That's actually the token doing its job correctly!

    Once you have your token, you just send it in the 'Authorization' header of your requests as a 'Bearer' token. The server reads it, verifies it and knows exactly who you are without having to check a database every single time.

    How It Works

    Untangle Your Tokens: Master JWT Decoding & Verification

    JSON Web Tokens (JWTs) are the "ID cards" of the modern web, but they look like gibberish to the human eye. Our JWT Encoder/Decoder is a free, browser-based tool that lets you peek inside those long strings. Paste a token to instantly read its payload, cryptographically verify its signature or even generate a fresh token for your local development.

    The Three-Part Anatomy of a JWT

    Every JWT is actually three different pieces of data glued together with dots:

    1. Header: Tells the system which algorithm was used to sign the token (usually HS256 or RS256).
    2. Payload: This is where the actual data (claims) lives. It contains the user ID, their name, when the token expires and any other custom data your app needs.
    3. Signature: The "seal" on the envelope. It proves that the token hasn't been tampered with.

    Decoding vs. Verifying: Know the Difference

    This is the most important rule of working with JWTs: Anyone can decode a token, but only the holder of the secret key can verify it.

    • Decoding: This is just unmasking the data. You don't need a secret key to see who the token belongs to or when it expires.
    • Verifying: This is a cryptographic check. It re-calculates the signature to ensure nobody changed the user ID or gave themselves "admin" rights after the token was issued.

    Security Tip: Never trust a JWT in your production app until you have verified its signature.

    Common Claims You'll See

    ClaimWhat it means
    subSubject (Usually the User ID)
    issIssuer (Who created the token)
    expExpiration (When it stops working)
    iatIssued At (When it was created)
    audAudience (Who the token is for)

    Real-World Debugging with JWTs

    Fixing 401 Unauthorized Errors: If your API is rejecting your requests, paste the token here. The most common culprit is the exp claim: your token might have expired five minutes ago without you realizing it.

    Local Development Without a Server: If you're building a protected endpoint and don't want to spin up a whole Auth0 or Firebase instance just to test a "subscriber" role, use our Encoder to craft a custom token and sign it with your local secret.

    Security Audits: Use this tool to ensure you aren't accidentally storing sensitive data like passwords or credit card numbers in the payload. Remember: the payload is encoded, not encrypted. Anyone who sees the token can read it.

    100% Private and Secure

    Privacy is paramount when handling security tokens. Every calculation, decoding and signature check happens right in your browser. We never send your tokens or secrets to a server. We don't store them, we don't log them and we don't even see them. It's the safest way to debug your authentication flows.