JWT Debugger, Decoder & Encoder

JWT Debugger, Decoder & Encoder — Everything You Need

Our JWT debugger is a complete developer toolkit for working with JSON Web Tokens. Unlike single-purpose tools, it combines a JWT decoder, JWT encoder, signature verifier, expiry checker, and interactive learning guide — all in one clean, privacy-first interface.

Whether you're debugging an authentication bug at 2 AM, testing an API endpoint, or learning how JWTs work, this tool gives you everything you need without installing anything or uploading tokens to a server.

Avoid pasting live production tokens or signing secrets into this page.

What is a JWT? (Simple Explanation)

Imagine you visit a hotel. At the reception, you show your ID, and the staff gives you a key card. That key card proves who you are and lets you open your room, the gym, and the pool — without showing your ID again.

A JSON Web Token (JWT) works exactly like that key card. When you log in to a website, the server gives your browser a JWT. Your browser then shows this token to the server on every request, and the server knows: "Ah, this is John, he's allowed in."

The best part? The server doesn't need to look up your session in a database. The token itself is the proof. This is why JWTs are so popular in modern apps.

What Does a JWT Look Like?

A JWT is a long string with three parts separated by dots. It looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The three parts are:

1. HEADER — tells us what algorithm was used to sign the token
2. PAYLOAD — contains the actual information (name, ID, expiry, etc.)
3. SIGNATURE — proves the token hasn't been tampered with

Decoding vs Verifying — What's the Difference?

This is where most people get confused. Let's clear it up:

👉 Important: A JWT is NOT encrypted. Anyone who gets your token can read its contents. So never put passwords, credit card numbers, or sensitive personal data inside a JWT payload.

Real-World Example: Login Flow

Let's walk through what actually happens when you log in to an app like Instagram:

1. Step 1: You enter your username and password.
2. Step 2: The server checks your credentials against the database.
3. Step 3: If correct, the server creates a JWT with your user ID and expiry time.
4. Step 4: The server signs the JWT with its secret key and sends it back to your browser.
5. Step 5: Your browser stores the JWT (usually in memory or localStorage).
6. Step 6: On every subsequent request (loading posts, liking photos), your browser sends the JWT in the Authorization header.
7. Step 7: The server verifies the signature and reads your user ID — no database lookup needed!

Decoded Example — Step by Step

Let's take the sample token above and decode it:

Part 1 — Header (after decoding):

{
  "alg": "HS256",
  "typ": "JWT"
}

This tells us: "This token was signed with HMAC SHA-256, and it's a JWT."

Part 2 — Payload (after decoding):

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

This tells us: user ID is 1234567890, name is John Doe, issued at 1516239022 (Unix timestamp).

Part 3 — Signature: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

This is the cryptographic proof. If someone changes even one character in the header or payload, the signature will no longer match.

Common JWT Claims (With Examples)

Claims are just fields inside the payload. Here are the most common ones:

JWT Algorithms — Which Should You Use?

HS256 is the simplest. You use one secret key to sign and verify. Best for: internal APIs, single-server apps, testing.

RS256 uses a private key to sign and a public key to verify. Best for: microservices (one service signs, others verify without needing the secret), public APIs.

ES256 uses elliptic curve cryptography — smaller keys, same security level as RSA. Best for: mobile apps, modern systems with limited bandwidth.

⚠️ Never use none in production. That's the "no signature" algorithm, and it's how attackers forge tokens.

Common Mistakes Developers Make

• Storing sensitive data in the payload: JWT payloads are just base64url encoded — anyone can decode them. Never put passwords, credit card data, or private info.
• Not checking expiry: Always verify the exp claim on the server. Otherwise, expired tokens still work.
• Using none algorithm: Attackers can forge tokens if you don't strictly enforce the algorithm on the server.
• Storing JWT in localStorage: It's vulnerable to XSS attacks. Prefer httpOnly cookies for access tokens.
• Very long expiry times: A token that lasts a year is a security risk. Use short-lived access tokens (15 min) + refresh tokens.
• Weak secrets for HS256: "secret123" can be brute-forced. Use at least 256 bits (32 random bytes) of entropy.

Debugging JWT Issues — Practical Tips

Problem: "My token is rejected on the server."

Fix: Use the Decode tab above to inspect the header and payload. Check: (1) is it expired? (2) does the issuer match? (3) is the audience correct?

Problem: "Signature verification fails."

Fix: Check that your secret key is exactly the same. Whitespace matters. Also, confirm the algorithm in the header matches your server's expectation.

Problem: "I don't know why my token isn't working."

Fix: Paste it into the Decode tab. It will show: expiry status, iat/exp timestamps, and any malformation.

JWT Security Best Practices

• Always verify the signature on the server
• Always check the exp claim
• Use short expiry times (5–60 minutes for access tokens)
• Use refresh tokens for long-lived sessions
• Store tokens securely (httpOnly cookies preferred)
• Use strong random secrets (32+ bytes)
• Prefer asymmetric algorithms (RS256/ES256) in distributed systems
• Never trust a token without verifying the signature first

Frequently Asked Questions About JWT Debugger

What is a JWT debugger?

A JWT debugger is a tool that decodes and verifies JSON Web Tokens. It shows the header, payload, and signature in a readable format, and can verify whether the token was signed with the correct key.

Is this JWT decoder and encoder free?

Yes — our free JWT debugger is 100% free. No sign-up, no limits, no hidden charges.

Is it safe to paste my JWT here?

Token operations run in the browser. The page also loads shared third-party scripts in production, so avoid live production tokens and signing secrets.

Can I create JWTs with this tool?

Yes — the Encoder tab lets you create and sign JWTs with all standard algorithms (HS256, RS256, ES256, etc.).

How do I know if my JWT is expired?

The tool automatically reads the exp claim and shows whether the token is expired or valid, along with a live countdown.

What does "signature invalid" mean?

If signature verification fails, the token was either signed with a different key, modified after signing, or the algorithm/key is incorrect. Never trust an invalid token.

What algorithms are supported?

HS256/384/512 (HMAC), RS256/384/512 (RSA), ES256/384/512 (ECDSA), and none (for testing only).

Can I decode JWTs from OAuth or OpenID Connect?

Yes — the tool works with any standard JWT, including OAuth 2.0 access tokens and OpenID Connect ID tokens.

What is the difference between base64 and base64url?

JWTs use base64url, which replaces + with -, / with _, and removes padding. Our tool handles this automatically.

Does the tool log my tokens?

Token decoding and inspection run in your browser; the token is not submitted to a tool API. Avoid pasting a live access token into any website.

Can I use this JWT debugger on mobile?

Yes — the tool is fully responsive and works on desktop, tablet, and mobile devices.

What's the difference between decoding and verifying?

Decoding just reads the base64url-encoded data (anyone can do it). Verifying checks that the signature matches the secret/public key — proving the token hasn't been tampered with.