What the Session Token Decoder Does
The Session Token Decoder is the best-effort reader for credential-shaped strings that may or may not be JWTs. Paste any token — a JWT, a bare Base64 blob, an opaque session ID — and the tool tries its formats in order, printing whatever it can read and an honest account of what it could not. It exists because real systems emit more than one token shape, and pasting a mystery string into a JWT-specific tool produces a parse error rather than an answer.
The cascade is visible in the output. If the token looks like a JWT — dot-separated segments that decode to JSON — you get the full JWT report: header, payload, signature description, algorithm, and expiry status. If not, the tool attempts a plain Base64 decode and, on success, shows the decoded text labelled Decoded as base64. If neither reads, the output falls back to what can be said about the string: its length and its count of distinct characters, with the explicit note that it is not a recognizable JWT or base64 payload.
The tool never verifies signatures and never needs a key — it is a reader for the whole zoo of tokens that cross a developer's screen: session cookies, API keys that turn out to be base64, bearer tokens from unfamiliar providers, and the strings in a Set-Cookie header that might mean something.
How the Format Detection Works
Detection is a cascade of cheapest-first attempts, each tried only if the previous one failed. The first check is shape: does the trimmed input contain dots, in JWT-like fashion? If it splits into at least two dot-separated segments, the tool attempts the JWT path — Base64Url-decoding each segment and parsing it as JSON. Success produces the same report the
JWT Decoder gives: header, payload, signature summary, algorithm, expiry verdict.
If the JWT attempt throws — wrong shape, failed decode, non-JSON — the tool falls through to plain Base64. It maps URL-safe characters back to standard Base64, restores padding, and decodes. Success labels the output honestly: Decoded as base64. This step reads the large middle population of tokens: base64-encoded session payloads, URL-safe identifiers that are "really" base64, and one-part opaque strings that happen to decode.
The final fallback fires when nothing decodes. Rather than a bare error, the output reports two measurable properties — byte length and distinct-character count — with the note that the string is not recognizable as either format. That is deliberately more useful than failure: length and character variety are real evidence for the next diagnostic step (a 43-character alphanumeric string with 60 distinct symbols is a different animal from a 12-character numeric ID).
One consequence deserves respect: the tool never confirms what a token is, only what it can be read as. Base64 is not a format but an encoding, and it wraps many things — including JWTs. What the decoded bytes mean is your read; the label is the tool's honest scope.
Using the Session Token Decoder
- Step 1 — Paste the mystery token. From a cookie's value, an
Authorization header, a query parameter, a log line, or browser storage. The whole string, unmodified — trimming and quote-stripping are handled. - Step 2 — Run the transform. No options, no key. The tool detects the format itself.
- Step 3 — Read the label as carefully as the content. The output always says which interpretation succeeded. A JWT report, a
Decoded as base64 blob, and the length/characters fallback are three different verdicts about three different kinds of string. - Step 4 — Escalate to the right specialist tool. A JWT report earns the JWT tools (validator, verifier, expiry checker). A base64 hit whose contents look structured may deserve the Base64 Encoder/Decoder for round-tripping, or JSON tooling if the decoded bytes parse. An unrecognizable string usually means consulting whoever issued it — the tool has told you what it is not.
- Step 5 — Use the fallback metrics diagnostically. When you get the length-and-characters report, the numbers are leads: a 32-byte string of high character variety suggests an encoded binary; a short numeric string suggests a database ID or OTP. The tool cannot name the format, but it narrows the search.
Common Use Cases
First contact with an unfamiliar token. Integrating a new provider or reverse-engineering a legacy system starts with "what is this string?" This tool answers before you have to guess which specialised tool applies.
Reading session cookies. Many frameworks encode session state as base64 and drop it in a cookie. Pasting the cookie's value here shows whether the state is readable — and by extension whether sensitive data is riding in a client-side cookie in plaintext.
Security review of token hygiene. Sampling the tokens your own system emits and decoding them here shows what an attacker would see: readable session state, personal data in payloads, or structure where there should be opacity.
Worked Example
Three pastes, three paths — the cascade in action.
First, a JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.1VAmegkQOBsQ-iSZU96z6c8NY7QR9OhhYWYHwHTeGT4
The shape check passes, both segments decode to JSON, and the output is the full JWT report: header with alg: HS256, payload with the subject and name claims, signature as a 16-character prefix and its length, plus the algorithm and expiry info line.
Second, a plain base64 string:
c2Vzc2lvbi11c2VyLTEwNDI7cm9sZT1hZG1pbg==
No dot-separated JWT shape (the == padding and single segment see to that), so the tool falls through to the base64 attempt, which succeeds. The output is the decoded text — session-user-1042;role=admin — labelled Decoded as base64. Note what this demonstrates about token hygiene: a session cookie carrying role=admin in decodable plaintext is readable by anyone who captures it, which is exactly the kind of finding this tool exists to surface.
Third, something opaque:
xK9$mQv2
Neither attempt reads it, so the fallback reports its length (8 bytes) and distinct-character count (7), with the honest note that it is not a recognizable JWT or base64 payload. The correct next step is the issuing system, not another decoder.
Tips and Common Mistakes
- "Decoded as base64" is a label, not a verdict. Base64 wraps everything from JSON to JPEGs. What the decoded bytes mean is your read; the tool's contribution is getting the bytes visible.
- The JWT path requires JSON inside. A dot-separated token whose segments decode to binary still falls through to base64. If you expected a JWT report and got base64, the token's segments are probably not JSON — check the issuer.
- Paste the token's value, not its header.
Authorization: Bearer eyJ... — paste from the space onward; Set-Cookie: sid=abc... — the value, not the name. Attribute prefixes are the most common cause of the opaque-string fallback. - Fallback metrics are leads, not answers. Length and distinct characters rule formats out; they do not rule one in. Treat the opaque-string report as the end of what decoding can say, and take the numbers to whoever issued the token.
- Signatures are never verified here. A readable token is not a trustworthy token — decoding shows claims, verification proves them. The JWT HS256 Verifier is the authenticity step when it matters.
- Tokens you paste deserve the usual caution. Everything runs locally with no transmission, but the standing rule applies: prefer expired or test tokens, and know the rotation story for anything real.
Frequently Asked Questions
Which formats does it recognise?
Three tiers, tried in order: compact JWTs (dot-separated segments decoding to JSON), plain Base64 and Base64Url strings, and everything else — reported honestly as unrecognised, with length and distinct-character metrics. It does not parse SAML/XML tokens, encrypted blobs (JWE), or proprietary encodings; those fall to the opaque-string fallback, which is the tool telling you the truth rather than guessing.My token decoded as base64 but the output is gibberish — what now?
The bytes are binary, not text — base64 happily encodes images, encrypted payloads, and compressed data. If the token came from a system you control, check its documentation for the encoding. If it is encrypted (an encrypted session, a JWE), no decoder will help without the key — that is the point of encryption. The gibberish is information: the token is not meant to be read here.Why does the same token sometimes give a JWT report and sometimes a base64 decode?
That should not happen — the cascade is deterministic: JWT shape first, base64 second. If you are seeing different results, you are probably pasting different strings (a truncated token loses its dot-separated shape and falls through to base64), or one of the pastes included an attribute prefix. Identical input always yields the identical path.Is it safe to paste live session tokens?
The decoding is local-only — no transmission, no storage, nothing persists past the tab. The broader habit still applies: a live session token is a live credential, and the safest practice anywhere is to prefer expired or test tokens. If you must paste a real one, do it in a context where you can invalidate it afterwards.Can it decode encrypted tokens if I have the key?
No — the tool performs no decryption and accepts no keys. Encrypted tokens (JWE form, encrypted session payloads) are ciphertext by design, and decryption belongs in your application with proper key management. The tool's fallback report will show the string as unrecognised, which is accurate: there is nothing readable in it without the key.Related Tools