Decode and inspect OAuth 2.0 access tokens, refresh tokens, and ID tokens to view claims and metadata.
OAuth Token Inspector lets you paste an OAuth or OpenID Connect token value and examine any readable token structure without sending the credential away from the browser. For a JWS-form JWT, it separates the compact header, payload, and signature segment, then decodes the base64url-encoded JSON so claims such as issuer, subject, audience, expiry, issued-at time, and scope can be reviewed. Access tokens and refresh tokens may instead be opaque identifiers, so the tool cannot recover server-side claims absent from the pasted text. Readable output proves only that content was decoded, not that the token is authentic or currently valid.
A concrete input and expected output from the current implementation.
Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Expected output
Header: {"alg":"HS256","typ":"JWT"}; payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}; signature segment present. The first two period-delimited segments are base64url encodings of those JSON objects. The final segment is signature material, so it adds no claims and does not by itself establish trust.
When the input is a JWS-form JWT in compact serialization, two period separators delimit three segments. The inspector decodes the base64url header and payload as JSON, exposing members such as alg, typ, iss, sub, aud, exp, nbf, iat, and scope when present. The final segment carries signature bytes rather than a third JSON object. A compact JWE has five segments, and its encrypted claims are not directly decodable without decryption.
A JWT NumericDate value in exp, nbf, or iat represents seconds from 1970-01-01T00:00:00Z. Reading it alongside issuer and audience can help explain a rejection. An opaque token has no standard client-readable claim layout. Since inspection is local and does not contact the issuer, opaque-token expiry, scopes, revocation state, and ownership cannot be derived from its string.
Not conclusively. A readable payload can expose expiry, audience, and other likely causes of rejection, but acceptance is decided by the resource server's validation rules and current authorization state. Signature verification also requires trusted key material and an algorithm policy, not merely bytes contained in the token. An opaque token may require authenticated server-side introspection.
Refresh tokens are frequently opaque values whose meaning exists only at the authorization server. OAuth does not require them to use JWT serialization, so a random-looking string can be valid while yielding no header or payload. The inspector cannot reconstruct hidden issuer records from it. Keep the value secret because it may be exchangeable for new access tokens.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.