Are JSON Web Tokens encrypted by default?

No. Standard JSON Web Tokens (JWS, RFC 7515) are Base64URL-encoded, not encrypted. Anyone who intercepts the token string can decode the header and payload claims immediately. Encryption requires JSON Web Encryption (JWE, RFC 7516). Never store unencrypted passwords, credit card numbers, or private keys in standard JWT payloads.

Why does signature verification fail when my secret looks correct?

The most frequent cause is binary secret encoding. Identity providers such as Supabase, Auth0, and Firebase often export HMAC secrets as Base64 strings. If your backend decodes the Base64 string to raw bytes before signing, you must enable the 'Secret is Base64 encoded' toggle in PrivaUtils so the verification key matches. Verification also fails if the token algorithm is asymmetric (requiring a public key) or if any character in the header or payload changed.

Does PrivaUtils transmit my token or secret key to any server?

No. PrivaUtils runs 100% locally in browser memory. Decoding uses standard ECMAScript TextDecoder and Base64 algorithms, while cryptographic verification runs on your local CPU via the W3C WebCrypto SubtleCrypto API. You can disconnect your network connection or inspect the browser Network tab to verify that zero HTTP packets are sent.

What is the 'alg: none' vulnerability?

The JWT specification allows unsigned tokens when the header specifies alg: 'none'. Vulnerable server libraries that fail to enforce strict algorithm whitelists accept tokens where an attacker modifies claims (such as setting admin: true) and removes the signature. PrivaUtils flags any token with alg: 'none' as a critical security hazard.

How does PrivaUtils save tool settings?

Preferences such as default workbench mode, default algorithm, Base64 secret handling, and JSON indentation are saved explicitly to your browser's private IndexedDB database under the 'jwt-inspector-settings' key. When you return, a non-intrusive prompt lets you apply your profile with smooth visual feedback.

Can I verify RS256 or ES256 tokens in PrivaUtils?

Yes. Switch the signature verification panel to the 'Public Key' tab and paste your RSA or ECDSA public key in standard PEM format (-----BEGIN PUBLIC KEY-----) or JWK JSON format. PrivaUtils imports the public key and verifies the digital signature directly in browser memory.

JWT Inspector & Decoder (100% Private, Free)

Capability / Feature	PrivaUtils	jwt.io	10015.io	token.dev	gorest.co.in
Execution Architecture	Local Browser Memory	Local Browser	Local Browser	Local Browser	Local Browser
Hardware HMAC Verification (HS256, HS384, HS512)	Yes (SubtleCrypto)	Yes	No (Decoder only)	Yes	No (Decoder only)
Public Key Verification (RS256, ES256)	Yes (PEM & JWK)	Yes (PEM only)	No	Yes	No
Base64 Secret Toggle Switch	Yes (Binary safe)	Yes	No	No	No
Live Token Encoder & Builder Mode	Yes (Real-time auto-signing)	Yes	Basic encoder	Yes	No
Security Vulnerability & Secret Leak Linting	Yes (alg none, leaks, exp audit)	No	No	Basic flags	Basic exp flag
Live Expiration Countdown & Relative Time	Yes (Live relative strings)	No	No	Yes	Yes
Persistent Settings Vault & Export/Import	Yes (IndexedDB Vault)	No	No	No	No
Distraction-Free Fullscreen & Pane Maximizer	Yes (Global + per-pane)	No	No	No	No
Responsive Mobile & Foldable Density	Yes (Down to 280px)	Clipped/Broken	Standard	Clipped/Broken	Standard

RFC 7519 Specification & JWS Architecture

The Comprehensive Engineering Guide to JSON Web Tokens, JWS Signatures, and Zero-Trust Verification

Standardized by the Internet Engineering Task Force (IETF) in RFC 7519 and formally aligned with JSON Web Signature (RFC 7515), JSON Web Tokens (JWT) provide a compact, URL-safe container for transferring identity claims between parties. Modern authorization flows rely on JWTs for OAuth 2.0 bearer tokens, OpenID Connect (OIDC) identity profiles, and microservice service-to-service calls.

1. JOSE Header (Red)

Algorithm & Key Parameters

The JOSE header specifies the cryptographic signature algorithm applied to the token (such as HS256 or RS256), token format (typ: "JWT"), and optional key references (kid) corresponding to JSON Web Key Sets (JWKS).

2. Claims Payload (Purple)

Standard & Custom Claims

The payload contains statements regarding identity and permissions. RFC 7519 specifies registered claims including iss (Issuer), sub (Subject), aud (Audience), and temporal claims like exp, nbf, and iat.

3. Digital Signature (Cyan)

Cryptographic Authenticity

The signature is computed over the Base64URL-encoded header and payload concatenated with a period. It guarantees that neither claims nor headers have been tampered with since issuance by the keyholder.

Compact Serialization and Base64URL Encoding Mechanics

A standard serialized JWT consists of three ASCII strings concatenated by period delimiters:

// RFC 7519 Compact Serialization Format

Base64URL(Header) . Base64URL(Payload) . Base64URL(Signature)

Base64URL encoding (RFC 4648 §5) differs from standard Base64:

Plus signs (+) are replaced with hyphens (-).
Forward slashes (/) are replaced with underscores (_).
Trailing padding equal signs (=) are omitted.

This character set allows tokens to be safely transmitted in HTTP query parameters, path variables, and Authorization: Bearer <token> headers without escaping.

Cryptographic Signature Verification via WebCrypto SubtleCrypto

Signature computation for HMAC-SHA256 (HS256) processes the binary ASCII bytes of the first two segments:

signingInput = ASCII(Base64URL(Header) + "." + Base64URL(Payload))

computedSignature = HMAC-SHA256(secretKey, signingInput)

isValid = (Base64URL(computedSignature) === tokenSignature)

PrivaUtils runs this validation directly on your device via the W3C crypto.subtle.importKey and crypto.subtle.sign APIs. The secret key remains in transient component memory and is never dispatched across network interfaces.

Temporal Claim Boundaries: exp, nbf, and iat

Proper token consumption requires checking temporal boundaries represented as integer seconds since the UNIX epoch (1970-01-01T00:00:00Z):

exp (Expiration Time)

The exact second after which the token must be rejected. Gateways must discard requests arriving after this time.

nbf (Not Before)

Identifies the earliest instant at which the token is valid. Requests arriving prior to this time must be rejected.

iat (Issued At)

Records when the authentication provider issued the token. Used to invalidate tokens issued before a password change.

Common JWT Security Pitfalls & Mitigation Strategies

Unsigned Tokens (alg: none): Certain libraries accept unsigned tokens if the algorithm header is set to none. Production services must whitelist supported algorithms explicitly and reject none.
Weak HMAC Shared Secrets: If an HS256 secret is short or based on dictionary words, attackers can capture a token and brute-force the secret offline. RFC 7518 specifies that HS256 secrets must contain at least 256 bits (32 bytes) of random entropy.
Audience & Issuer Validation: Cryptographic validity alone only proves key possession. Systems must also verify that iss matches the trusted authority and aud matches the receiving service.
Sensitive Information in Claims: Because payloads are unencrypted, credentials, private API keys, or personal health and financial data must never be stored in claims.

Frequently Asked Questions (FAQ)

What is the difference between JWS, JWE, and JWT?

A JSON Web Token (JWT) is the high-level specification for representing claims. JSON Web Signature (JWS) signs the payload for authenticity while leaving it readable. JSON Web Encryption (JWE) encrypts the payload so only the private keyholder can read it.

Why does my Base64-encoded secret fail verification?

Identity systems like Supabase and Auth0 often supply secrets as Base64 strings. If your server decodes this string to raw binary bytes before signing, enable the "Secret is Base64 encoded" checkbox so PrivaUtils decodes the secret before running HMAC SHA-256.

Can I use PrivaUtils offline?

Yes. All token parsing, Base64URL decoding, WebCrypto signature validation, and token generation algorithms execute locally inside your browser. You can inspect and build tokens in Airplane Mode without an active network connection.

How does the live Token Builder work?

In Encoder & Builder mode, any modification to the Header JSON, Payload claims, or Secret Key automatically recomputes the Base64URL serialization and cryptographic HMAC signature in real time, producing a production-ready token string.

JWT Token Inspector & Decoder

Encoded Token

Signature Verification

Decoded Header

Decoded Claims Payload

Cryptographic Signature

How PrivaUtils Compares to jwt.io, 10015.io, Token.dev & SuperTokens

The Comprehensive Engineering Guide to JSON Web Tokens, JWS Signatures, and Zero-Trust Verification

Algorithm & Key Parameters

Standard & Custom Claims

Cryptographic Authenticity

Compact Serialization and Base64URL Encoding Mechanics

Cryptographic Signature Verification via WebCrypto SubtleCrypto

Temporal Claim Boundaries: exp, nbf, and iat

Common JWT Security Pitfalls & Mitigation Strategies

Frequently Asked Questions (FAQ)

What is the difference between JWS, JWE, and JWT?

Why does my Base64-encoded secret fail verification?

Can I use PrivaUtils offline?

How does the live Token Builder work?

Related Privacy Utilities