Generate high-entropy access and refresh tokens, with expiry times, storage hashes, and a sample OAuth 2.0 response.
Start here Choose the entropy. 256 bits is a good default; 128 bits is the practical minimum for a bearer credential.
Entropy is 256 bits per token, drawn from crypto.getRandomValues in this page.
Press Generate token pair.
Expires n/a (exp 0)
Store this digest, not the token
—
Press Generate token pair.
Expires n/a (exp 0)
Store this digest, not the token
—
{
"access_token": "<generate a pair first>",
"token_type": "Bearer",
"expires_in": 900,
"refresh_token": "<generate a pair first>",
"scope": "read write"
}The shape defined by RFC 6749 section 5.1. expires_in is a lifetime in seconds, not a timestamp.
Understand the format
An opaque token is nothing but random bytes: its security comes entirely from being unguessable and from what the server stores next to it.
OAuth 2.0 does not say what an access token looks like. The specification calls it opaque to the client, and two designs dominate. An opaque token is a random string that means nothing on its own; the authorisation server keeps a record and looks it up on every request. A JWT is self-describing: the claims travel inside the token and any service holding the key can validate it without a database round trip.
The trade-off is revocation against lookup cost. An opaque token can be revoked instantly by deleting the row. A JWT stays valid until it expires, because nothing consults a database, which is why JWT access tokens are usually given short lifetimes and paired with a revocable refresh token. This page generates opaque tokens, which is the right default whenever you control the resource server and want revocation to be immediate.
A random token is safe only while guessing one is infeasible. 128 bits of entropy is the common floor and 256 bits is a comfortable default; the encoding you choose changes the length of the string but never its strength. 32 random bytes are 43 characters in Base64URL and 64 characters in hexadecimal, and both carry exactly 256 bits.
What matters far more than length is the source. The bytes here come from crypto.getRandomValues, the browser cryptographically secure generator. A token built from Math.random, a timestamp, a counter, or a hash of a user id is predictable, and predictable tokens have been the root cause of a long line of account-takeover bugs.
Treat tokens the way you treat passwords: the server should keep only a SHA-256 of the token, compare digests on each request, and show the plaintext exactly once at issue time. If the token table then leaks, the attacker has digests rather than working credentials. This page shows the digest next to each token for that reason.
Unlike passwords, a fast hash is appropriate here. Password hashing must be slow because people choose guessable passwords; a 256-bit random token has no dictionary to attack, so SHA-256 is both sufficient and quick enough to run on every request. Compare digests in constant time so response timing does not leak how many leading characters matched.
The pair exists to limit exposure. Access tokens are sent on every request and so are the most likely to leak, which is why they are short-lived, typically five to sixty minutes. The refresh token is sent only to the token endpoint, lives for days or months, and is the credential worth stealing, so it should be stored more carefully than the access token.
The OAuth 2.0 security best current practice recommends refresh token rotation: each refresh issues a new refresh token and invalidates the old one. If an old token is presented again, that is evidence of theft and the whole family should be revoked. Sender-constrained tokens, using DPoP or mutual TLS, go further by binding a token to a specific client key.
Step by step
Tokens are generated with crypto.getRandomValues and hashed with the Web Crypto API, entirely in your browser. Nothing is sent to a server, logged, or kept after you leave the page. For the same reason, no token is generated during server rendering: every visitor gets values created on their own machine.
Worked examples
Input
entropy 256 bits, encoding Base64URL, prefix at_
Result
at_5Qm5Xk2rJvN0pB7dYw3TcLzR8sHfKq1uAeGiOnM4Vb0
32 random bytes become 43 characters. The at_ prefix is not part of the entropy; it exists so the string is recognisable in a log or a leaked file.
Input
entropy 256 bits, encoding hexadecimal
Result
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
64 characters instead of 43, with identical strength. Hex is worth choosing only when the consumer cannot handle the Base64URL alphabet.
Reference
| Property | Access token | Refresh token |
|---|---|---|
| Purpose | Authorises each API call | Obtains a new access token |
| Typical lifetime | 5 to 60 minutes | Days to months |
| Sent to | Every resource server | Only the token endpoint |
| Exposure | High: travels on every request | Low, but far more valuable if stolen |
| Storage on the client | Memory, or a short-lived cookie | Secure httpOnly cookie or platform keystore |
| Storage on the server | SHA-256 digest | SHA-256 digest, with a rotation family id |
| On compromise | Expires quickly on its own | Revoke immediately and rotate the family |
Practical Guide
Troubleshooting
FAQ
The randomness is production grade, since it comes from the browser cryptographically secure generator. What makes a token real is the server: it has to be issued, stored as a digest, scoped, and given an expiry by your authorisation server. Use these for development, seeding, and testing, and let your identity provider mint the ones that guard real data.
Opaque tokens when you own the resource server and want instant revocation. JWTs when many services must validate a token without a shared database, accepting that a valid token cannot be withdrawn before it expires. Many systems use both: a short JWT access token with an opaque, revocable refresh token.
Long enough to avoid constant refreshes, short enough that a leaked token expires before it is useful. Fifteen minutes is a common middle ground; public clients and high-value APIs often go shorter.
Hashing protects against a database leak rather than against guessing. If the token table is dumped, digests cannot be replayed. Since the token is high-entropy, a fast hash such as SHA-256 is enough; no salt or slow KDF is needed.
Recognition. A prefix such as at_ or ghp_ lets secret scanners spot a leaked credential in a commit, and lets you tell at a glance which kind of token turned up in a log. It adds no entropy, so keep it short.
No, deliberately. Signing needs your key, and pasting a signing key into any web page is exactly the mistake the JWT Decoder page warns about. Mint signed tokens in your backend with a maintained library.
No. The bytes are generated, encoded, and hashed in this page. Nothing is transmitted or stored, and leaving the page discards the values permanently.
Go deeper