Stop pasting your JWTs into random websites to decode them

Faizan Shakeel — Thu, 03 Sep 2026 16:14:06 +0000

You've got a JWT and you need to see what's inside it — which user it's for, what scopes it carries, when it expires. The quick move is to search "jwt decoder," grab the first result, and paste your token in. Don't. A JWT is often a live credential, and decoding one is so simple you never need to hand it to a stranger's server. Here's how it actually works.

A JWT is just three Base64 strings

A JSON Web Token is three Base64-encoded parts joined by dots:

header.payload.signature

Header — how the token is signed (e.g. HS256).
Payload — the claims: the actual data (user id, scopes, expiry).
Signature — a cryptographic seal proving the token wasn't tampered with.

The first two parts aren't encrypted. They're just Base64URL — encoding, not secrecy.

Decode it yourself in the console

Because the header and payload are plain Base64, you can read them with nothing but the browser:

function decodeJwt(token) {
  const part = (seg) =>
    JSON.parse(
      decodeURIComponent(
        atob(seg.replace(/-/g, "+").replace(/_/g, "/"))
          .split("")
          .map((c) => "%" + c.charCodeAt(0).toString(16).padStart(2, "0"))
          .join("")
      )
    );

  const [header, payload] = token.split(".");
  return { header: part(header), payload: part(payload) };
}

decodeJwt(myToken);
// { header: { alg: "HS256", typ: "JWT" },
//   payload: { sub: "1234567890", name: "Jane Doe", exp: 1716242622 } }

No library, no network request. The token never leaves the page.

Decoding is not verifying

This is the part people miss. Anyone can decode a JWT — but that doesn't prove it's real. The signature is what proves authenticity, and checking it requires the secret or public key that signed it. HS256, for example, is HMAC with SHA-256.

So: decoding shows you the contents; verifying proves you can trust them. Never trust an unverified token server-side just because the payload looks right.

The payload is not secret

Since the payload is only Base64, whoever holds the token can read every claim in it. Don't put anything sensitive — passwords, internal flags you don't want the user to see — inside a JWT payload.

Reading the expiry

The exp, iat, and nbf claims are Unix timestamps. 1716242622 means nothing at a glance — convert it to a real date to see whether the token is still valid.

So why not just use a random decoder site?

Because a live JWT is a bearer token — practically a password until it expires. Many online decoders send what you paste to their backend, where it can be logged. If that token is still valid, you've just handed someone a working session. Decode it locally instead.

That's exactly why I built ToolNimbus JWT Decoder — it decodes the header, payload, and claims entirely in your browser, converts the expiry to a readable date, and flags whether the token is still valid. Open your network tab while you use it: nothing gets sent.

JWT Decoder — decode header, payload & claims client-side
Base64 Encoder / Decoder — the encoding each JWT part uses
Hash Generator — the SHA family behind HS256

How do you inspect tokens while debugging — console, an extension, or a decoder? Curious what people reach for.

The browser has a crypto library built in — you probably don't need a package

Faizan Shakeel — Mon, 27 Jul 2026 08:26:15 +0000

Reach for "generate a secure password" or "hash this string" in JavaScript and the instinct is to npm install something. Most of the time you don't have to. Every modern browser ships the Web Crypto API on window.crypto — a fast, audited, native cryptography toolkit. Here are three things it does with zero dependencies.

1. Cryptographically secure random values

Math.random() is not safe for anything security-sensitive — it's predictable. For passwords, tokens, or salts you want crypto.getRandomValues(), which pulls from the OS entropy source:

function securePassword(length = 20) {
  const charset =
    "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*";
  const values = crypto.getRandomValues(new Uint32Array(length));
  return Array.from(values, (v) => charset[v % charset.length]).join("");
}

securePassword(); // e.g. "kR7$mQ2xL9!pW4nZ8vT#"

No library, no server round-trip — the randomness comes straight from the platform.

2. UUIDs in one line

Need a unique ID? There's now a native call for that:

crypto.randomUUID(); // "36b8f84d-df4e-4d49-b662-bbfa2d9f4c15"

That's a spec-compliant v4 UUID, no uuid package required.

3. Hashing with SubtleCrypto

crypto.subtle handles real hashing. Here's SHA-256 of a string:

async function sha256(text) {
  const data = new TextEncoder().encode(text);
  const buffer = await crypto.subtle.digest("SHA-256", data);
  return Array.from(new Uint8Array(buffer))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
}

await sha256("hello world");
// "b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9"

subtle.digest supports SHA-1, SHA-256, SHA-384 and SHA-512. (MD5 isn't included — it's cryptographically broken — so for legacy MD5 checksums you do still need a small library.)

Why this matters beyond saving a dependency

Because it's native, the data never leaves the page. There's no request to a server, nothing logged, nothing to trust but the browser you already trust. That's the right model for anything sensitive.

It's also the model I built ToolNimbus on — a set of free tools that run entirely client-side. If you'd rather not paste the snippets, the same primitives are wired up here:

Password Generator — getRandomValues
UUID Generator — randomUUID
Hash Generator — subtle.digest

Open the network tab while you use them — you'll see nothing gets sent. That's the whole point of the native API.

What else have you built on Web Crypto instead of reaching for a package? I'd love to hear about it in the comments.

DEV Community: Faizan Shakeel