Ti
TiBox
100% On-Device / SafePure Client-Side
Developer Token Security

Offline JSON Web Token (JWT) Inspector

Decodes and inspects claims entirely inside your browser. Zero tokens sent to remote servers.

Raw Encoded TokenRAM Only
Expires:12/31/2030, 12:00:00 AM
Active / Valid
Header: Algorithm & Token Type
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload: Data Claims
{
  "sub": "1234567890",
  "name": "Alex Morgan",
  "iat": 1516239022,
  "exp": 1924905600,
  "role": "ultra-admin"
}
Technical Documentation & ArchitectureReference Manual
Quick Jump:OverviewMath FormulationsMethodologyCase StudiesComparisonDeep DiveSecurity AuditGlossaryFAQs (10)
Executive Summary & Context

About Offline JWT Inspector & Verifier

JSON Web Tokens (JWT), formally standardized by the Internet Engineering Task Force (IETF) in May 2015 under RFC 7519, represent the foundational open industry standard for securely representing claims between two parties in modern distributed web architectures, microservices, and OAuth 2.0 / OpenID Connect authorization flows. Compact, URL-safe, and digitally signed, JWTs have fundamentally replaced traditional stateful server sessions across cloud ecosystems, enterprise SaaS backends, and mobile APIs.

However, modern software developers and security engineers face a persistent operational hazard when debugging authentication workflows. When an authentication token fails, expires unexpectedly, or returns HTTP 401/403 Forbidden errors, developers routinely copy the raw bearer token and paste it into public web-based JWT decoders. This common habit represents a severe security compromise. Public web decoders frequently log query bodies, transmit tokens to external analytical endpoints, or cache sensitive user credentials on remote servers.

Pasting a production JSON Web Token into an untrusted third-party website leaks the bearer credential, compromising the user's active session, administrative role assignments, email address, internal UUIDs, and tenant permissions. If the secret signing key is also tested on the public website, attackers can forge arbitrary authentication tokens with root privileges. The TiBox Offline JWT Inspector & Verifier eliminates this vulnerability. Executing 100% inside your workstation's local browser memory, TiBox decodes headers and payloads, audits claim expiration timelines, and calculates cryptographic verification without dispatching a single byte across the internet.

Mathematical & Algorithmic Foundations

Base64URL Encoding, JWS Digital Signature Architecture, and HMAC-SHA256 Derivation

JWT = Base64Url(Header) || "." || Base64Url(Payload) || "." || Base64Url(Signature)

A JSON Web Token adhering to RFC 7519 and RFC 7515 (JSON Web Signature, JWS) consists of three discrete base64url-encoded components separated by ASCII period (0x2E) characters:

1. Base64URL Encoding Mechanics (RFC 4648 §5): Standard Base64 encoding utilizes '+', '/', and '=' padding characters, which are problematic inside URL query strings and HTTP headers. Base64URL substitutes '+' with '-', '/' with '_', and strips trailing '=' padding characters: Decode: str.replace(/-/g, '+').replace(/_/g, '/') + (padding)

2. JOSE Header (JSON Object Signing and Encryption): Encodes cryptographic metadata in JSON: { "alg": "HS256", "typ": "JWT" } where 'alg' designates the cryptographic signature algorithm (HS256, RS256, ES256, EdDSA).

3. Claims Payload: Encodes verified statements regarding an entity (the subject) and additional context: - 'iss' (Issuer, RFC 7519 §4.1.1): String or URI identifying identity provider. - 'sub' (Subject, RFC 7519 §4.1.2): Unique identifier for the authenticated principal. - 'aud' (Audience, RFC 7519 §4.1.3): Array of recipients the token is intended for. - 'exp' (Expiration Time, RFC 7519 §4.1.4): Unix epoch timestamp; token must be rejected if current_time >= exp. - 'nbf' (Not Before, RFC 7519 §4.1.5): Unix epoch timestamp before which token must not be accepted. - 'iat' (Issued At, RFC 7519 §4.1.6): Unix epoch timestamp of token generation.

4. Cryptographic Digital Signature Verification: For HMAC-SHA256 (HS256): Signature = HMAC-SHA256( Key, Base64Url(Header) + "." + Base64Url(Payload) ) where HMAC (RFC 2104) is defined as: HMAC(K, m) = H( (K' ⊕ opad) || H( (K' ⊕ ipad) || m ) ) where H is the SHA-256 cryptographic hash function (FIPS PUB 180-4), K' is the key padded to the 64-byte block size, and opad (0x5c) and ipad (0x36) are constant byte pads.

Variables & Mathematical Notation
algCryptographic signing algorithm identifier (e.g. HS256, RS256)
expExpiration Unix epoch timestamp in seconds since Jan 01 1970
iatIssued-at Unix epoch timestamp in seconds
subSubject unique identifier representing the authenticated user
HMACHash-based Message Authentication Code combining key and token text
Base64URLURL-safe base64 encoding replacing + and / with - and _
Execution Methodology & Data Flow

How TiBox Computes This In-Browser

STEP 01

Syntactic Dot-Separation & Token Validation

The tool receives the raw token string and verifies that it contains exactly two delimiter periods dividing Header, Payload, and Signature components.

STEP 02

Zero-Transmission Base64URL Deserialization

The browser native atob() decoding pipeline converts base64url sequences into UTF-8 text strings, which are parsed into typed JSON objects in memory without network transport.

STEP 03

Real-Time Epoch Expiration Chronology

Claims "exp", "iat", and "nbf" are evaluated against current client system time (Math.floor(Date.now() / 1000)), rendering visual status indicators for active vs. expired tokens.

STEP 04

Local In-Browser HMAC Signature Verification

When a signing secret is provided, the browser Web Crypto API (SubtleCrypto.sign / SubtleCrypto.verify) evaluates the HMAC-SHA256 digest in native C++ machine code.

STEP 05

Ephemeral Sandbox Teardown

All parsed claims and cryptographic keys are bound solely to the local React memory state and vanish entirely upon tab refresh or navigation.

Empirical Case Studies & Scenarios

Real-World Quantitative Case Studies

The "alg: none" Critical Authentication Bypass (CVE-2015-9235)

Scenario: An enterprise cloud API utilized JSON Web Tokens for authentication. An attacker intercepted their regular user token, set the JOSE header algorithm to "alg": "none", removed the signature part entirely (leaving the trailing period), and forged the payload claim to "role": "admin".

Analysis: Many early server-side JWT parsing libraries implemented the RFC 7519 specification literally: if "alg": "none" was supplied, the library verified the signature as valid without checking keys. Attackers gained root administrative control across thousands of applications.

Outcome: Modern security best practices strictly enforce algorithm whitelisting on backend verifiers. TiBox highlights insecure headers (including "alg": "none") and validates strict cryptographic integrity locally.

Production Bearer Token Leak via Public Web Debugger Logs

Scenario: A DevOps engineer troubleshooting a failed production deployment pasted a high-privilege service-account bearer token into a commercial online web JWT parser. Unknown to the engineer, the website analytics script was logging the full URL and request body.

Analysis: The token gave unrestricted read/write access to internal Kubernetes clusters and customer databases. The third-party analytics company suffered a database breach three weeks later, exposing the cached customer bearer tokens.

Outcome: Enforcing offline-only JWT inspection via TiBox ensures that production bearer tokens and secret keys never leave the developer workstation, preventing third-party supply-chain credential leaks.
Architectural & Privacy Comparison

Comparative Security Matrix: In-Browser WebCrypto vs. Public Online JWT Portals

Pasting authorization tokens into public web portals introduces an immediate session takeover hazard. Many public JWT debugging websites are monetized via third-party advertising scripts, telemetry SDKs (Google Analytics, Hotjar, Sentry), and cloud server proxies.

The comparison matrix below highlights the security and privacy differences:

Evaluation CriteriaTiBox Cupertino SuiteTraditional Cloud Tools
Token Transmission over Internet0 Bytes (True Air-Gap)Transmitted via HTTP POST or logged
Cryptographic EngineW3C SubtleCrypto API (Native OS)Server-side Node.js crypto
Secret Key Leakage RiskZero (Evaluated in browser RAM)High (Pasted into remote inputs)
Audit Logging & PersistenceNone (Destroyed on tab close)Frequently cached on remote proxies
Offline Functionality100% Operational without Wi-FiFails without internet connection
Technical Deep Dive & System Internals

Algorithmic Details & Browser Specifications

Symmetric (HS256) vs. Asymmetric (RS256 / ES256) Cryptography and JWKS

In JSON Web Signatures, developers must choose between symmetric and asymmetric signing algorithms:

- HS256 (HMAC with SHA-256): A symmetric algorithm where the same shared secret key is used both by the authentication server to issue tokens and by every microservice to verify tokens. While fast and simple, HS256 requires sharing the secret key across all services; if any downstream service is compromised, attackers can forge valid tokens for the entire system.

- RS256 / ES256 (RSA / ECDSA): Asymmetric algorithms utilizing a public/private key pair. The identity provider signs tokens using a private key kept strictly confidential. Downstream APIs verify token signatures using the identity provider public key, published via a standard JSON Web Key Set (JWKS) endpoint at '/.well-known/jwks.json'. Even if an API service is compromised, attackers cannot forge new tokens because they lack the private signing key.

Token Revocation Architecture: Refresh Rotation vs. Blocklists

Because JSON Web Tokens are stateless and self-contained, a fundamental engineering challenge is revoking a token before its natural 'exp' expiration timestamp (for example, when a user logs out, resets their password, or is terminated from an organization).

Three primary revocation patterns are employed in production:

1. Ephemeral Access Tokens (5 to 15 minutes) paired with stateful Refresh Tokens: Access tokens are short-lived. To extend sessions, clients submit a refresh token to the authorization server, which checks a database revocation flag. 2. Distributed Redis Blocklists: When a token is revoked, its unique identifier ('jti') is stored in an in-memory Redis cluster with a Time-To-Live (TTL) matching the token remaining lifespan. API gateways check Redis before authorizing requests. 3. User Version Vectors (Token Versioning): A sequential integer 'token_version' is stored on the user database record and embedded in the JWT payload. Incrementing the database version invalidates all previously issued tokens instantaneously.

Security & Air-Gap Audit Protocol

Zero-Knowledge Privacy Verification

The TiBox JWT Debugger enforces absolute cryptographic confidentiality. The tool uses standard browser APIs (atob, TextDecoder, and window.crypto.subtle) without third-party external dependencies. No data entered into token or secret key fields is ever written to storage or dispatched to network sockets.

✓ 0 Network Requests✓ 0 Tracking Beacons✓ W3C WebCrypto Compliant✓ RAM-Only Execution
Domain Technical Glossary

Terminology & Standard Definitions

RFC 7519The official IETF specification defining the architecture and claims format of JSON Web Tokens.
Base64URLA URL-safe variant of Base64 encoding that substitutes "-" and "_" for "+" and "/", omitting padding characters.
JOSE HeaderJavascript Object Signing and Encryption header specifying the token algorithm and token type.
SubtleCryptoThe W3C standard Web Cryptography API providing low-level, high-performance cryptographic primitives in the browser.
JWKS (JSON Web Key Set)A standard JSON format for publishing public cryptographic keys used to verify asymmetric JWT signatures.
jti (JWT ID)A unique token identifier claim commonly used to prevent replay attacks and facilitate token revocation.
Replay AttackA cyberattack where an intercepted valid authentication token is maliciously re-sent to an API to gain unauthorized access.
Bearer TokenA security token where possession of the token grants access to whoever "bears" it, without requiring proof of key possession.
Frequently Asked Questions (10)

Frequently Asked Questions about Offline JWT Inspector & Verifier

Is it dangerous to paste production JWTs into third-party web debuggers?▼

Yes, extremely dangerous. A JSON Web Token is a bearer token: whoever possesses it can impersonate the user and access your API. Public online JWT websites often log token payloads, track user email addresses, or cache tokens in server monitoring systems. Pasting sensitive production tokens into public websites can lead to account takeovers and session hijacking.

How does TiBox verify JWT signatures without sending them to a server?▼

TiBox uses the W3C Web Cryptography API (window.crypto.subtle) built directly into modern web browsers (Chrome, Safari, Firefox, Edge). Cryptographic hashing, base64url decoding, and HMAC-SHA256 signature verification run locally on your computer CPU via native browser machine code.

Is a JWT encrypted or just encoded?▼

Standard JWTs (JSON Web Signature, JWS) are signed and base64url encoded, NOT encrypted! Anyone who intercepts a JWT can easily decode the payload and read the claims (user ID, email, roles). For confidentiality, sensitive data must never be placed in a standard JWT unless using JSON Web Encryption (JWE).

What does the "exp" claim mean and how is it formatted?▼

The "exp" (expiration time) claim identifies the expiration timestamp on or after which the JWT must not be accepted for processing. It is represented as a Unix epoch timestamp—the number of seconds elapsed since January 1, 1970 (UTC). TiBox automatically converts this number into human-readable local time and flags expired tokens.

What is the "alg: none" attack vulnerability?▼

The "alg: none" vulnerability occurs when an insecure JWT verification library accepts tokens where the algorithm header is set to "none" without verifying any signature. Attackers can forge arbitrary administrative payloads and bypass authentication completely. Modern libraries and TiBox flag "none" as a critical security issue.

What is the difference between HS256 and RS256 signing algorithms?▼

HS256 is a symmetric algorithm using a single shared secret key for both signing and verifying the token. RS256 is an asymmetric algorithm using a private key to sign the token and a public key to verify it. In microservice architectures, RS256 is preferred because verifying services only need the public key, eliminating the risk of leaking the signing secret.

Can I debug expired tokens with TiBox?▼

Yes. TiBox decodes and displays the full header, payload, and claim attributes of any syntactically valid JWT, regardless of whether it has expired. The tool clearly displays the expiration status in real time so you can diagnose why your API rejected the token.

Does TiBox store my secret signing keys?▼

No. Any signing secret or key you enter is stored exclusively in temporary React component memory. As soon as you refresh the page or close the tab, the secret is permanently erased from memory.

What are standard reserved claims in a JWT?▼

RFC 7519 defines 7 registered claim names: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). These claims provide standard interoperability across identity providers and API gateways.

Can I verify tokens signed with RS256 or ES256?▼

Yes. TiBox supports client-side verification for HS256 symmetric keys directly, and provides payload and claim inspection for all asymmetric tokens (RS256, ES256, EdDSA).