Tokens come in recognizable shapes, and each shape tells you something. This guide covers the access token formats you will meet in real APIs: the prefix conventions, the encodings, the anatomy of a JWT, and the entropy math that determines how hard a token is to guess.
Prefixes: sk-, ak-, tok-
Many providers prefix their keys so humans (and tooling) can identify the key type at a glance:
| Prefix | Meaning | Seen at |
|---|---|---|
sk- | Secret key | OpenAI-style API keys, Stripe |
ak- / AKIA | Access key | AWS access key IDs |
tok_ | Generic token | Various SaaS APIs |
xoxb- / xoxp- | Bot / user token | Slack |
ghp_ | Personal access token | GitHub |
Prefixes are a usability and safety feature, not security: secret scanners (like the ones built into GitHub) recognize these prefixes and can warn you when a key leaks into a public repo. When you design your own API, adopting a recognizable prefix is a genuinely good idea — and it is why the TokenTonic generator offers prefix options.
Encodings: hex vs base64url
The random body of a token is bytes; the encoding decides how those bytes are written as text:
- Hex — each byte becomes two characters (0-9, a-f). Simple, unambiguous, but doubles the length: 32 bytes become 64 characters. AWS secret keys and many signing keys use hex.
- Base64url — a URL-safe variant of base64 using A-Z, a-z, 0-9, hyphen and underscore, with padding stripped. More compact: 32 bytes become 43 characters. JWTs use base64url for all three of their parts.
- Alphanumeric — A-Z, a-z, 0-9. The classic "API key look" (for example
sk-followed by random alphanumerics).
JWT anatomy
A JSON Web Token has three parts separated by dots:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjM0NTY3ODkwIn0 . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
- Header — JSON like
{"alg":"HS256","typ":"JWT"}, base64url-encoded. Says how the token is signed. - Payload — JSON claims: subject (
sub), issued-at (iat), expiry (exp), scopes. Base64url is encoding, not encryption — anyone can decode the payload. Never put secrets in it. - Signature — the header and payload signed with the server's secret key. This is what makes the token trustworthy: tamper with the payload and the signature stops matching.
TokenTonic's mock JWT builds this exact structure with an unsigned HS256 header and 32 random signature bytes, labeled mock in the payload — structurally real, cryptographically meaningless.
The entropy math
Token strength is measured in bits of entropy: each character contributes log2(alphabet size) bits.
| Format | Alphabet size | Bits per char | 32 chars total |
|---|---|---|---|
| Hex | 16 | 4.0 | 128 bits |
| Alphanumeric | 62 | ~6.0 | ~191 bits |
| Base64url | 64 | 6.0 | 192 bits |
128 bits is the standard target for secrets — far beyond brute force. Note the caveat: this math assumes cryptographically secure randomness. A 64-character token from a weak PRNG can be weaker than a 16-character token from crypto.getRandomValues(). Length is not strength; randomness is.
Reading a token in the wild: prefix tells you the provider and key type, encoding tells you the byte length, and a two-dot structure with decodable JSON means JWT. With those three reads you can identify almost any token you encounter in documentation or logs.
Related guides
- What are access tokens — Bearer auth and OAuth flows.
- Token security practices — handling the real ones safely.