b2KIT

Opaque Token Generator

Generate URL-safe, Base64, or hex-encoded opaque bearer tokens with selectable entropy (128-512 bits).

Tested tool guide Tested browser tools Checked August 16, 2026

What Opaque Token Generator does and how it behaves

The generator creates a random opaque token after you select an entropy size from 128 to 512 bits and a URL-safe, standard Base64, or hexadecimal representation. The result is intended to be carried as a bearer secret, not interpreted as a claims document. Changing the encoding changes the alphabet and displayed length, but does not add entropy. Generation and encoding remain in the browser, so the token is not uploaded. A common mistake is expecting the value to contain identity, scope, or expiration fields like a structured token.

How the result is produced

1

Entropy selection

The entropy control determines how much random token material is requested, while the encoding control selects its textual representation. For byte-aligned selections, dividing the bit count by eight gives the byte count. A 128-bit token contains 16 bytes, so its hexadecimal representation has 32 characters because each byte becomes two hex digits. Regenerating requests another random value.

2

Encoding choices

Hexadecimal, Base64, and Base64url can represent the same underlying bytes without changing their entropy. Standard Base64 uses an alphabet containing '+' and '/', and may include '=' padding. The URL-safe alphabet substitutes '-' and '_' for those characters. Padding conventions can vary, so copy the generated value exactly. Hex is longer, but its length maps directly to the selected byte count.

Good uses

  • Create a candidate bearer credential for an API or internal service whose issuing, storage, comparison, rotation, and revocation behavior you control.
  • Generate URL-safe secret material for a one-time invitation, password-reset record, or email-verification record that your application associates with its own expiration and used status.
  • Compare the lengths and character sets of token encodings before defining database columns, input validation, HTTP header handling, log redaction, or URL parameter formats.

Limits and checks

  • The settings are not deterministic input. Selecting 128-bit hex, for example, fixes the output size but not its characters. Each generation requests new random material, so there is no single output that a worked example could predict.
  • The generated string is only credential material. It is not automatically registered with a server and does not acquire an owner, audience, scope, expiration, rotation policy, or revocation status until an application supplies those behaviors.
  • URL-safe describes an encoding alphabet, not a safe disclosure channel. Bearer credentials can be used by whoever possesses them, and URLs may be retained in history, logs, analytics, or referrer information. Hex and Base64 are encodings, not encryption.

Common questions

Can I decode the token to find its owner or expiration?

No. Hex or Base64 decoding can recover the underlying random bytes, but those bytes contain no standardized subject, scope, audience, or expiration fields. The issuing application must keep a separate record that maps the token to its meaning and lifecycle. If you need self-contained claims that recipients can inspect, this opaque-token generator does not create them.

Does a longer encoded token always provide more security?

No. For this generator, the selected entropy is the meaningful comparison when the underlying randomness is otherwise equivalent. Hex requires more visible characters than Base64 to represent the same bytes, so length alone can be misleading. For example, 128 bits always equals 16 bytes and therefore 32 hexadecimal characters, regardless of what those characters happen to be.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools