{
  "id": 16886720,
  "title": "Stop Pasting Production JWTs into Random Websites: The Security Guide to JSON Web Tokens",
  "url": "https://urgent.news/2026/10/28/stop-pasting-production-jwts-into-random-websites-the-security-guide",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-28T10:59:59.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/rashid_salimov_ad8baac497/stop-pasting-production-jwts-into-random-websites-the-security-guide-to-json-web-tokens-22cn"
  },
  "original_language": "en",
  "account": "Many developers copy and paste production JSON Web Tokens (JWTs) into random online debuggers and inspect them. This is a dangerous practice as it exposes user IDs, tenant claims, role permissions, and potentially live sessions that don't expire for days. If the third-party server logs the token poorly, it could be stored in a centralized log aggregator or analytics database. This piece explains why JWTs are often misunderstood, how they work under the hood, and how to inspect them safely locally in your browser.\n\nThe first misconception is that JWT is signed, not encrypted. A JWT is a JSON Web Signature (JWS) and its payload is base64url encoded, not encrypted. Anyone can decode the claims with a few lines of JavaScript. If you need confidentiality, use JSON Web Encryption (JWE) instead.\n\nA standard JWT consists of three parts separated by periods: the header, payload, and signature. The header defines the cryptographic algorithm and token type. The payload contains user identity and authorization metadata like user IDs, roles, and custom claims. The signature ensures data integrity by calculating a HMAC-SHA256 hash of the header and payload with a secret key. Altering even a single character in the payload will fail verification.\n\nThere are three critical vulnerabilities to avoid:\n1. The \"alg: none\" attack, where an attacker changes the header to bypass signature verification on poorly written backend libraries. Enforce a whitelist of accepted algorithms on your server.\n2. Confusion between symmetric and asymmetric keys. Never let the token header dictate which key verification function is used. Pin your verification logic to asymmetric verification.\n3. Ignoring expiration. Stateless JWTs cannot be revoked without a centralized denylist. Keep token lifetimes short and use rotating refresh tokens stored in secure cookies.\n\nTo inspect tokens safely, use a client-side JWT Decoder that runs entirely in your browser sandbox. This way, the token never leaves your device, and you can instantly verify expiration, view the header and payload, and format claims without risking your production credentials.",
  "summary": "How many times this week have you opened a random online \"JWT Debugger\", pasted an Authorization: Bearer eyJhbGci... token from your production network tab, and hit enter? Most developers treat online JWT inspectors like formatters. But here is the uncomfortable truth: when you paste a token into a server-rendered online decoder, you are handing a third-party server your user IDs, tenant claims,…",
  "key_points": [
    "Developers often paste production JWTs into random debuggers, exposing sensitive user data",
    "JWTs are signed, not encrypted; use JWE for confidentiality",
    "Three critical vulnerabilities: alg: none attack, asymmetric key confusion, and ignoring expiration"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}