Work out whether a token is a JWT, a UUID, hex, or Base64, estimate its entropy, and get the digest to match against your records.
Start here Paste the token exactly as you found it, including any prefix.
SHA-256, to match your stored digest
—
Understand the format
An unidentified token still tells you a great deal: its alphabet reveals the encoding, its length bounds the entropy, and its structure says whether it is a secret or a label.
Format detection is mostly a matter of which characters appear. Only 0-9 and a-f, with an even length, means hexadecimal. Hyphens and underscores alongside letters and digits point to Base64URL; plus and slash with trailing equals signs point to standard Base64. Three dot-separated Base64URL segments is a JSON Web Token. Eight-four-four-four-twelve hexadecimal digits is a UUID.
Those distinctions matter because they tell you what to do next. A JWT should be decoded and its claims read. A UUID is an identifier and probably not a secret at all. A random Base64URL string is opaque: there is nothing inside it, and the only useful questions are how much entropy it has and what the server stored alongside it.
Entropy is estimated as the length of the random part multiplied by the bits each character can carry: six bits for Base64, four for hexadecimal. A 43-character Base64URL body therefore tops out at about 256 bits. Any identifiable prefix such as at_ or ghp_ is excluded from the count, because a fixed label adds no unpredictability.
The figure is an upper bound, and only an upper bound. It assumes every character came from a cryptographic random source. A token built from a timestamp, a counter, an encoded user id, or the output of Math.random can look identical and carry far less real entropy. That is why a value that decodes into readable text is flagged here: if you can read something inside it, it was never random.
A well-built system stores the SHA-256 of each token rather than the token itself, so the digest is shown here for direct comparison against a database column. If it matches a stored row, the token in your hand is that record; if nothing matches, either the token was never issued, or the system is storing plaintext, which is worth fixing.
One caution while investigating: a token found in a log, a bug report, or a screenshot should be treated as compromised regardless of what you learn about it. The right response is revocation and rotation, not analysis alone.
Step by step
The token is analysed and hashed in your browser. Nothing is transmitted, logged, or retained, which is what makes it reasonable to inspect a credential you found during an investigation.
Worked examples
Input
at_5Qm5Xk2rJvN0pB7dYw3TcLzR8sHfKq1uAeGiOnM4Vb0
Result
Base64URL, prefix at_, 43-character body, about 258 bits
The prefix is excluded from the estimate. Comfortably above the 128-bit floor for a bearer credential.
Input
dXNlcl9pZD00Mjtyb2xlPWFkbWlu
Result
Base64URL that decodes to user_id=42;role=admin
Readable output means the value encodes data rather than randomness. Anyone can decode it, and anyone can forge a variant unless a signature protects it.
Reference
| Shape | Format | What it means |
|---|---|---|
| Three parts split by dots | JSON Web Token | Self-describing. Decode it and check the signature server-side. |
| 8-4-4-4-12 hex digits | UUID | An identifier, not a secret. Roughly 122 random bits in version 4. |
| 32 or 64 hex characters | MD5 or SHA-256 digest | Probably a stored fingerprint rather than a credential. |
| 43 Base64URL characters | Opaque token, 256 bits | The output of 32 CSPRNG bytes. A typical access token. |
| Short prefix then random text | Prefixed API key | The prefix aids secret scanning; the entropy is in the rest. |
| Decodes to readable text | Encoded data | Not a random secret. Its contents are public to any holder. |
Practical Guide
Troubleshooting
FAQ
No, because there is nothing inside it. An opaque token is random bytes; the meaning lives in the row the authorisation server stored. Only encoded formats such as Base64 or a JWT carry readable content.
Length multiplied by the bits per character of the detected alphabet, with any identifiable prefix removed. It is an upper bound that assumes a cryptographic random source.
128 bits is the practical floor for a bearer credential and 256 bits is a comfortable default. Below 64 bits, offline guessing becomes realistic.
Because a well-designed system stores that digest instead of the token. It lets you match a token in hand against a database row without ever storing the plaintext.
Open it in the JWT Decoder to read the header and claims and to convert the timestamps. Remember that decoding proves nothing about the signature.
No. Detection and hashing both run in this page using standard browser APIs, and nothing is stored after you leave.
Go deeper
